# Multi-agent systems: when splitting an agent helps and when it just costs more

Splitting one agent into several is one of the most popular moves in agent design, and often the most expensive one. It helps in a specific situation. Outside it, you pay more for a system that's harder to debug.

## What multiple agents actually buy

The real benefit is separate context windows. A subagent researching one question works in a clean context that holds only that question, its tools and its findings. It hands back a short summary, and the lead agent never sees the hundred search results behind it. For broad tasks that would otherwise overflow one context, that's a genuine gain.

The second benefit is parallelism. If a task breaks into independent pieces, like checking five sources or reviewing five files, subagents can run at the same time.

## What it costs

- Tokens. Every agent reads its own instructions, tools and context. Anthropic reported that its multi-agent research system used roughly 15 times the tokens of a plain chat interaction. That can be worth it for high-value work. It isn't for routine tasks.
- Compounding errors. If each handoff is right 95% of the time, a chain of five is right about 77% of the time (0.95 to the power of 5).
- Lost context. The lead agent knows why a task matters. A subagent knows only what the handoff told it.
- Debugging. A wrong answer now has several transcripts behind it, and the mistake might be in any of them or in a handoff between them.

## Patterns that hold up

- **Orchestrator and workers:** A lead agent plans, sends independent subtasks to workers that run in parallel, then combines their results. Good for research and wide searches.
- **Pipeline:** Fixed stages in a fixed order, like extract, then check, then write. Often this doesn't need agents at all, just a sequence of model calls.
- **Router:** One step decides which specialist handles a request, then gets out of the way. Good when requests fall into clearly different types.

The pattern to avoid is several agents talking freely to each other until they agree. It's hard to predict, hard to bound and hard to test.

## Write handoffs like task specs

"Research competitor pricing" sent to three workers produces three overlapping reports. A handoff needs the objective, the boundaries, the expected output and when to stop:

```
{
  "objective": "Find current list prices for the 3 cheapest plans of vendor X",
  "scope": "Vendor's own pricing page and docs only. Not reviews or forums.",
  "output": "JSON: [{plan, monthly_price, currency, source_url}]",
  "stop_when": "All 3 plans found, or 5 tool calls used"
}
```

## Start with one agent

Build one agent with good tools first and measure it. Split it only when you can point to the problem splitting solves: the context keeps overflowing, or the work has clearly independent parts that would finish faster in parallel. Then run the same evals on both versions. If the multi-agent version isn't measurably better, keep the simpler one.

---

Last updated 2026-10-16. Canonical: https://anukumar.site/writing/multi-agent-systems