Part 1 covered the first ten: symptom fixes, hidden sharing, lost messages, "done" without proof, blurry approvals, shared workspaces, fading context, overlapping ownership, plausible inventions and environments that drift. Both posts come from running a small team of agents on one product, which I described in How I build a product alone with a team of seven Claude Code agents.
These ten are quieter. They do not break the build; they waste a day, put the wrong decision on record, or turn up as a bill. Same format: what it looks like, why it happens, what helps.
11. Agents compete for the same machine
What it looks like: a server one agent is using gets restarted by another. Two heavy jobs run at once and both time out. A test fails because another agent's test changed the same account.
Why it happens: every agent assumes the machine is its own. Commands like "stop the server" or "reset the test data" are written for one person at one desk.
What helps: give each agent its own ports, its own test accounts and its own data where it can. Schedule the heavy work: builds, full test runs, recordings. Agents stop only processes they started, never by a broad pattern. And announce shared work: "the test server is busy for the next 40 minutes".
12. Agents put words in your mouth
What it looks like: "As you said, we will …" about something you never said. A decision appears in a document with your name on it, but it came from another agent's suggestion.
Why it happens: in a chain of messages, the origin of an idea gets lost. An agent that hears "this was decided" from another agent fills in the most likely decider: you.
What helps: log every decision with who actually made it, and when. When an agent cites you, ask for the message it comes from. Agents should write "I suggest" and "the product owner decided" in their own words, not "the human wants".
13. Time is harder than it looks
What it looks like: a test fails every night around midnight. A message says "tomorrow" and two agents read different days. A deadline in a document is an hour off.
Why it happens: servers run on UTC, people do not. Agents know neither the human's time zone nor which "today" a sentence meant, and many tests quietly use the current date.
What helps: write absolute dates, with the time zone, in everything that matters. Report times in the human's local time. Give tests fixed dates instead of "now", and run them once near midnight on purpose.
In our case, the rule became simple: the server runs on UTC, every time reported to a human is local time.
14. Agents stall silently
What it looks like: an agent has been "working" for hours. In fact it asked a question at the end of a long output and is waiting for an answer nobody saw.
Why it happens: asking and stopping is the safe default. But a question buried in the middle of a long report is easy to miss, and the agent cannot tell that nobody read it.
What helps: ask and keep going: let the agent do everything that does not depend on the answer, and make the question the first line, not the last. Collect open questions in one place the human checks. A short status line ("waiting for: X, since: 14:20") makes a stall visible.
15. The human becomes the bottleneck
What it looks like: twenty small questions a day: which word, which colour, retry or not. Each takes a minute; together they take the day, and every agent waits for you.
Why it happens: agents are told to ask when unsure, and they are unsure about many small things. Without a rule for what is small, everything goes to the top.
What helps: let one coordinating agent take the small, reversible decisions and log them, so you can read them later and overrule one if needed. Write down what counts as small. Big or irreversible questions still come to you: anything public, money, deleting production data, secrets.
16. The written rules contradict each other
What it looks like: two documents give two answers to the same question. The rules file still describes how things worked last month. An agent follows an outdated rule perfectly.
Why it happens: rules get added, rarely removed. Each new rule is written with the current task in mind, not with all the older rules next to it. Agents read rules literally and cannot tell which one is stale.
What helps: one role that checks every new rule against the existing ones before anything is built on it. Update the rules in the same change that alters the behaviour they describe, not later. When two rules disagree, the agent asks instead of picking one.
17. Agents propose more than you need
What it looks like: every finished task comes back with five ideas for what to do next. Each one is reasonable. Together they turn a two-day feature into a two-week one.
Why it happens: agents are good at seeing what could be better and eager to be useful. They do not know which of their ideas serve the goal of this month.
What helps: a proposal is not a task. Keep a "not now" list and tie it to the current strategy: if an idea does not serve the goal, it goes on the list, with no guilt. Review the list now and then; most of it can stay there.
18. Secrets end up in the chat
What it looks like: an agent needs a key to continue, and the fastest way is to paste it into the conversation. Now it lives in the transcript, maybe in logs, maybe in a summary.
Why it happens: the work is blocked, the key is at hand, and the chat is right there. Nobody plans it; it happens in a hurry.
What helps: prepare a safe path before it is needed: the human writes the key into a local, ignored file, and the agent reads it from there without ever printing it. Agents should refuse to echo keys and ask for that path instead. A key that went through a chat counts as exposed: rotate it.
19. Quotas and costs surprise you
What it looks like: in the middle of the month a limit hits: build minutes, an API quota, storage, a plan limit. Work stops, or a bill arrives that nobody expected.
Why it happens: agents work much faster than people and repeat things without hesitation: one more build, one more full test run. Nobody adds it up until the limit does.
What helps: know your limits before you scale up. Measure what one run costs, set budgets and alerts, and put expensive actions behind a check. Spending money stays a human decision.
20. One change ripples through everything connected
What it looks like: a repository moves, a key is rotated or a domain changes, and three other things break: a pipeline, an integration, a link in a document, a rule an agent still follows.
Why it happens: connections pile up quietly. Each one was set up once, by someone, for a reason nobody wrote down. The agent making the change sees only the change.
What helps: before any infrastructure change, list what is connected to it, make a backup, change one thing at a time, and check each item afterwards. Keep that list in a document, so the next change starts from it.
The checklist
- Does every agent have its own ports, accounts and test data?
- Is every decision logged with who actually made it?
- Are dates absolute, with a time zone?
- Does a waiting agent say so, first line, and keep working on the rest?
- Is it written down which decisions agents may take themselves?
- Are new rules checked against old ones, and updated with each change?
- Do proposals go to a "not now" list unless they serve the current goal?
- Is there a safe path for secrets, and are leaked ones rotated?
- Do we measure what a run costs, with a budget?
- Does every infrastructure change come with a map, a backup and a checklist?
Taken together with part 1, the pattern is the same: agents are fast, capable and literal. Most problems come from what they cannot see, such as other agents, the clock, the human's attention and the connections around a change. Most fixes make that visible and write it down.
The agent team behind these posts builds DuctTape.io, a diagram editor for AI architectures.
Top comments (1)
tr.ee/dev-to