When does a multi-agent setup beat a single agent, and when does it make things worse?

Several agents beat one when the work splits into independent parts that can run in parallel and each part needs a lot of reading, as in broad research. They make things worse when the parts depend on each other or share state, as in most coding, because agents lose context in hand-offs and cost several times more tokens.

Where it helps

Anthropic's research feature uses a lead agent that plans and starts subagents, each searching one angle in its own context window and returning a short summary. On their internal research evaluation, this setup (a large lead model with smaller subagents) beat a single agent using the large model by 90.2%. The reasons:

• Parallel work. 5 subagents searching at once finish sooner than 1 agent searching 5 times.
• Clean contexts. Each subagent reads thousands of tokens and hands back hundreds. The lead's context stays small and focused.
• More total thinking. Spreading the work over several context windows lets the system use far more tokens on a problem than one window holds.

What it costs

The same write-up reports multi-agent runs using about 15 times the tokens of a chat, against about 4 times for a single agent. It pays only when the task is valuable enough.

Where it hurts

• Tightly linked work. In coding, one change depends on another. Agents working in parallel make conflicting edits or miss each other's decisions. The write-up names coding as a poor fit for this pattern.
• Hand-off losses. Each hand-off is a summary, and summaries drop details. A vague task description makes subagents duplicate work or search the wrong thing.
• Debugging. A wrong answer may come from any agent or any hand-off. Tracing it needs full logs of every agent.
• Coordination overhead. For a small task, planning and merging cost more than the work.

How to decide in practice

1. Start with a single agent and good tools.
2. If its context fills with search results, or the work is clearly parallel, add subagents for those parts only (orchestrator-workers).
3. Give each subagent a precise brief: the objective, the output format, the tools to use and where its job ends.
4. Measure on the same test tasks: success rate, cost and time. Keep the extra agents only if success rises enough to pay for them.

A good one-line answer: "Multi-agent is a way to spend more tokens in parallel on breadth. It is not a better architecture by default."