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 why a swarm on one problem fails, and the rhythm I use now instead.

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 sequential 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. Sequential, clean, recordable.

When I do use more than one

I still use multiple agents — but only when the work is genuinely independent. Two unrelated features, each in its own git worktree, never touching the same files: that parallelises fine. The rule I learned the hard way: agents parallelise across independent work, never across one shared problem.

Five agents on one problem isn't five times faster — it's five times the conflict.

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