I ran five agents at once and regretted it

I once pointed five agents at the same feature, convinced I was about to go five times faster. I went backwards. This is the field note on what actually broke — and on the lesson I drew from it that turned out to be wrong.

The idea: five agents, five times faster

The feature was big — a multi-part settings overhaul — and I was impatient. So I had a clever idea: why run one agent serially when I could run five in parallel? One on the UI, one on the API, one on validation, one on tests, one on docs. Five workers, one feature, five times the speed. Obviously.

I spun them all up against the same branch and let them go.

What actually happened (contradiction and conflict)

Within twenty minutes it was chaos. Two agents edited the same file and clobbered each other's changes. The validation agent assumed one shape for the settings object — the API agent assumed another, so they built two halves that didn't fit. The test agent wrote tests against an interface the UI agent had already changed. Each agent was individually reasonable. Together they were a committee that never met.

The worst part wasn't even the broken code. It was that I couldn't reconstruct what had happened. Five overlapping streams of edits, no single thread to follow. I couldn't write a session brief because there was no coherent story to tell.

Stuart Leo

Five agents on one feature didn't give me five workers. It gave me five people redecorating the same room at once, in the dark.

Why a swarm on one problem fails

I'd misunderstood what parallelism needs. Agents don't coordinate the way people do — no quick word at the desk, no shared sense of who's touching what. Point several at the same surface and they overwrite, contradict, and conflict. The hard part of multi-agent work was never spawning the agents — it's the coordination, and a crowd on one problem maximises the coordination cost while delivering almost none of the parallel benefit.

The fix

I threw it out and started over with one lead agent, working through the feature in sequence, writing a session brief as it went. Slower per my fantasy, far faster in reality — because nothing had to be untangled. When I wanted a second opinion on the validation logic, I brought in a bench agent to review, after the lead had done its pass. Clean, recordable, and it worked.

What I got wrong about why it failed

For a long time I told that story as a lesson about the number. Five was too many. One was right. I repeated it confidently enough that other people repeated it back to me.

That was the wrong lesson, and it took me a while to see it. The number was never the problem. All five agents were working on one surface — one branch, one working tree, one settings object they each held a different opinion about. Two agents would have failed the same way. So would twelve. What made it collapse was that everything was shared and nothing in any brief said so.

When I do use more than one

I still use multiple agents, and now I can say exactly when. Two conditions, both of which my five violated inside the first minute:

• No edge. An edge means one agent's output is another's input. My validation agent and my API agent had an edge the size of a house — they were building two halves of the same object — and I started them at the same instant anyway.
• No shared surface. A surface is everything an agent mutates or contends for: files, data, a rate-limited API, a deploy target. Mine shared every one of those.

Two unrelated features, each in its own git worktree, never touching the same anything — that parallelises fine, and I do it regularly now. The rule I actually learned the hard way wasn't fewer agents. It was draw the edges before you spin anything up. And if you can't find two jobs with no edge between them, you don't have two jobs.

If you want those two checks as a procedure rather than a war story, I wrote it up properly: when can agents actually run in parallel.

Five agents on one surface isn't five times faster — it's five times the conflict. The bug was the shared surface, not the number.

Start here: see multi-agent vs single agent, how agent teams work, or read the method.