One agent is a conversation. A dozen agents running in parallel against the same codebase, the same database, and the same API budget is an operations problem. The failures arrive in a predictable order, and most of them have nothing to do with how clever the model is.
This article lists those failures in roughly the order I would expect them, based on how such systems are built. It is a checklist of what to prepare for, not a measured report.
1. Shared state collides
Two agents edit the same file, or the same row, or the same branch. The second write overwrites the first, and neither agent knows. The fix is isolation: each agent works in its own branch or worktree, and touches only the files it owns. Assign ownership of directories and tables before you start, not after the first collision.
2. Cost grows faster than output
Each agent consumes tokens, and retries multiply the cost. An agent that loops on a failing step can spend more than a day's useful work in an hour. Set a budget per agent and per run, and stop when it is reached. Track cost per completed task, not per agent, because an agent that is cheap and fails often is expensive.
3. Rate limits and quotas stop the fleet
Model APIs and tools have rate limits. Dozens of agents hit them together, and the failures look random. Queue the calls, back off on errors, and spread the work across time. A fleet that retries in lockstep makes the limit worse.
4. Failures are invisible
When one agent fails quietly, nobody notices until the output is missing. Give each agent a status it must report: started, working, blocked, or done, with evidence. A silent agent is treated as failed after a timeout.
5. Results drift from the goal
Agents drift when they interpret a goal in slightly different ways. Ten agents with ten slightly different readings produce ten outputs that do not fit together. Write the goal and its constraints once, in a shared document each agent reads at the start, and check outputs against that document, not against each other.
6. Nobody owns the output
When many agents produce work, it is easy for no person to feel responsible for any of it. Assign a human owner to each stream of output, and make that owner the one who approves a merge or a release.
7. The review queue becomes the bottleneck
Agents produce output faster than people can review it. The queue grows, reviewers skim, and quality falls. The fix is smaller changes, automated checks that run before review, and a limit on how much work can wait for a person at once.
How to prepare
Start small, with two agents on separate files and a shared budget. Add the logging, the status reports, and the owner for each stream before you add a third agent. Scale only when the two-agent version runs without manual rescue for a week.
Keep the people in the loop for anything that changes production, spends money, or speaks to customers. Those decisions do not scale, and they should not.
Summary
The first things to break in a many-agent setup are shared state, cost, rate limits, silent failures, and drift from the goal. Isolation, budgets, queued calls, required status reports, and a single written goal fix most of them. Keep a human owner for each stream and for every decision with real cost, and grow the fleet only after the small one is boring.
Top comments (0)