Multi-agent vs single agent: when more agents help

"Use more agents" is the most over-applied idea in agentic development. It sounds obviously right — if one agent helps, a team of them should help more. So people spin up a swarm on a single feature and are surprised when it goes worse, not better.

The truth is more interesting: multi-agent is sometimes a big win and often a trap, and the line between the two is sharp. Here's when more agents help, when a single agent wins, and how to tell which situation you're in.

The appeal of more agents

A single agent is serial — it does one thing at a time. The dream of multi-agent is parallelism: split the work, run agents at once, finish faster. And there's a real version of that dream. Different models also have different strengths, so the fantasy extends to "the right model on each part."

The appeal isn't wrong in principle. The problem is where people apply it — almost always to a single, shared problem, which is exactly where it backfires.

The anti-pattern: many agents, one problem

Here's the trap, plainly: multiple agents working the same surface at the same time is an anti-pattern. They edit the same files and overwrite each other. They reason about the same problem and reach contradictory conclusions. And because there's no single coherent story of what happened, you can't even write a session brief to record it.

The research on running multi-agent coding workspaces keeps landing here: the hard part isn't spawning agents, it's coordinating them — and a crowd on one problem maximises the coordination cost while delivering little of the parallel benefit.

Stuart Leo

A swarm on one problem isn't parallelism. It's several confident agents disagreeing in the same files.

When multi-agent actually helps

So when does it pay? Two clear cases:

1. Genuinely independent work. Tasks that don't touch each other — separate features, separate services — can run in parallel, each agent isolated in its own git worktree. The key word is independent, and independence has a test: no edge between the briefs, and no shared surface.
2. Independent review. One agent builds, a separate bench agent reviews. Here the second agent's whole value is being separate — fresh eyes the builder doesn't have.

Notice both cases avoid the trap: the agents either own different surfaces, or do different jobs at different times. They're never mutating one surface at once.

Sequence what's connected

Even when I use more than one agent, the connected work runs in order. Lead executes, then a bench agent reviews, then the lead acts. That isn't a stylistic preference — there's an edge between those steps, because the bench reads what the lead produced. You can't review an artefact that doesn't exist yet.

What can run at once is the work with no edge and no shared surface. And a surface is wider than a file list: it's everything an agent mutates or contends for — files, data, a rate-limited API, a deploy target. The trap I keep watching people fall into is false independence, two agents whose briefs never mention each other both hammering one database. Anything shared is a hidden edge, and hidden edges bite hardest because nothing in the brief says they exist.

How to decide

A quick decision rule:

Default to one agent. Add agents when you can name the surface each one owns and show that no two share one — and when you can't find two briefs with no edge between them, that's the answer: there's nothing to spread, so don't. If you want the decision procedure rather than the table, here it is in full.

Agents run at once when no edge connects them and no surface is shared — the test is the surface, not the headcount.

Start here: see how agent teams work, parallel agents with git worktrees, or read the method.