# When many agents are worse than one

Parallel agents win on broad, read-heavy research and often lose on coding, where the pieces share assumptions. The cost is real: about 15 times the tokens of a chat.

## Two honest accounts that look like they disagree

In June 2025, within a day of each other, two teams published opposite-sounding advice. Anthropic described a multi-agent research system that beat a single agent. Cognition published "Don't Build Multi-Agents".

Both are right, about different work. Reading them side by side is the fastest way to learn when to split a task and when not to.

## The case for many: research

Anthropic's system had a lead agent running Opus 4 and parallel subagents running Sonnet 4. On their internal research eval it beat a single Opus 4 agent by 90.2%.

Research suits this shape. It is broad, mostly reading, and the branches do not depend on each other. One subagent can read one set of sources while another reads a different set, and neither needs to know what the other found until the end. The team reports that starting three to five subagents in parallel cut research time by up to 90%.

A finding worth remembering: on the BrowseComp benchmark, token use alone explained about 80% of the variance in performance. Part of what multi-agent systems buy is simply more tokens spent in parallel.

## The case against: coding

Cognition's argument is about assumptions. Every action an agent takes carries an implicit decision. Give two subagents pieces of one job without the full context, and they make decisions the other cannot see. Their example is a Flappy Bird clone: one subagent builds the background while another builds the bird, and the two do not fit together. Each piece was reasonable alone.

Their advice is to share the full context, not just the last message, and to start with a single linear agent. Anthropic says nearly the same about its own system: tasks that must share one context or have many dependencies are a poor fit, and that includes most coding. Real-time coordination between agents is still weak.

**Question:** In the Flappy Bird example, why do two subagents produce parts that clash?

- One of them is a weaker model
- Each makes decisions the other cannot see, because they do not share context
- They use different programming languages
- The lead gave them too many tools

**Answer:** Each makes decisions the other cannot see, because they do not share context. Every action carries an implicit decision. Without shared context, parallel subagents decide differently and the pieces do not fit.


## The bill

Anthropic puts numbers on this. An agent uses about 4 times the tokens of a chat. A multi-agent system uses about 15 times. Value has to justify that, and for broad, valuable research it can.

The harness post gives a second, sharper example. A retro game maker run by a single agent took 20 minutes and cost 9 dollars, and the result was broken. The full harness, with separate planner, generator and evaluator, took 6 hours and cost 200 dollars, and the game was playable. That is over 20 times the cost, which is worth it only if the cheaper result was not good enough.

> **Starting small is the advice**
Anthropic's guide to building agents says the same from another angle: start with the simplest thing, often one model call with retrieval. Agents add latency and cost and can compound errors, and frameworks can hide the prompts you need to read.


## A way to decide

Three questions, in order.

- **Can one agent do this?** If yes, stop there. It is cheaper and easier to debug.
- **Do the pieces share state or assumptions?** If yes, splitting makes disagreements that someone has to reconcile. Most coding falls here.
- **Is the work broad, read-heavy and worth the multiple?** Then parallel agents are likely to pay for themselves.

Even then, scale the effort to the question. Anthropic's rule of thumb: one agent making 3 to 10 calls for a simple lookup, and ten or more subagents only for hard research.

> **The harness ages**
Every part of a harness encodes an assumption about what the model cannot do. When Opus 4.6 arrived, the team removed the sprint structure and moved the evaluator to a single final pass, keeping only the planner. Retest each part with each new model.


> **Price a split**
Take a task you gave one agent. Write down what a three-agent version would cost at 15 times the tokens, and what would have to be true for the answer to be better. If you cannot name it, keep one agent.


**Question:** Which task is the best candidate for many parallel agents?

- Refactoring one tightly connected module
- Gathering information on twelve independent companies
- Fixing a single failing test
- Renaming a variable across a file

**Answer:** Gathering information on twelve independent companies. Wide, read-heavy work with independent branches is where parallel agents pay off. Tightly coupled coding work is where they clash.