When I reach for a team of agents, and when one is enough

The demos are seductive. A lead agent spins up a team of specialists, hands each a slice of the problem, and they work in parallel while you watch a dashboard fill in. It feels like hiring a team on demand. And sometimes it genuinely is the right move. But most of the time when I see someone reach for a swarm of agents, they have taken a problem that one focused agent would have solved cleanly and turned it into a distributed-systems problem they now have to coordinate.

So I have a fairly strict rule about when parallel agents earn their cost, and it starts with being honest about what that cost is.

The economics are not subtle

Anthropic published real numbers on this from their own research system, and they are worth internalizing before you fan anything out. Their multi-agent setup, a lead orchestrating several subagents, outperformed a single strong agent by about 90 percent on their research evaluation. That is a huge uplift. It also burned roughly fifteen times the tokens of a normal chat interaction. You can read the full writeup in how they built it.

That ratio is the whole decision. A fifteen-times cost multiplier is trivial when the task is worth thousands of dollars of someone’s time and the answer needs to be thorough. It is absurd when you are fixing a null check. The question is never “would parallel agents be more powerful here.” Almost anything is more powerful with more compute thrown at it. The question is whether the value of the task clears the cost of the fan-out, and for the median coding task it does not come close.

What actually parallelizes

Beyond cost, there is a structural test. Parallel agents help when the work genuinely decomposes into independent paths that do not need to talk to each other while they run. Anthropic’s system works because research is naturally breadth-first: go find everything about X, and Y, and Z, and each search is independent until you gather the results.

Most of my real wins with parallel agents fit that shape:

• A feature that spans clean module boundaries. One agent owns the backend endpoints, another owns the frontend, another owns the tests. They touch different files, so they cannot step on each other, and they only need to agree on the contract between them.
• Review from several angles at once. One pass for correctness, one for security, one for performance. Each is a different lens on the same diff, and they do not interfere.
• Exploring competing approaches. When I am not sure whether to solve something with a queue or a cron or a webhook, spinning up an agent per approach and comparing the results is faster than doing them in sequence.

What does not parallelize is a single tangled bug, a change where every step depends on the last, or anything where the agents would need to constantly coordinate on the same files. Splitting that across agents does not divide the work. It multiplies the merge conflicts.

Coordination is the hidden tax

The part the demos skip is that a team of agents is a team, with all the coordination overhead that word implies. The lesson I keep relearning is that the bottleneck moves from execution to instruction quality. Five agents will confidently produce five subtly incompatible interpretations of a vague task far faster than one agent could.

So when I do fan out, the discipline is non-negotiable. Every agent gets an explicit, self-contained brief: the exact task, the files it owns, the acceptance criteria, and the constraints, with no assumption that it can see the conversation that led here. File ownership is drawn so no two agents write the same file. The interface between the pieces is agreed before anyone starts, not discovered in the merge. Skip any of that and the parallelism you bought is spent on reconciling the mess it produced.

The default is still one agent

Here is where I land. A single agent with a clean, well-scoped task and the right context is the correct tool for the overwhelming majority of work. It is cheaper, it is easier to steer, and there is no coordination surface to get wrong. I reach for a team only when the task is both genuinely decomposable and valuable enough to justify the multiplier, and even then I start with two agents on something low-stakes before trusting five on something that matters.

Multi-agent systems are not the next stage that makes single agents obsolete. They are a specialized tool with a specific and expensive profile, powerful exactly when the work is wide, independent, and worth it. Reaching for them by default is not ambition. It is paying fifteen times over for a coordination problem you created yourself.