Multi-agent systems
Several LLM agents with separate contexts, instructions and tools cooperating on one task: strong for parallel breadth, ~15× chat tokens.
A multi-agent system uses several agents instead of one. Each has its own job, instructions and tools: one searches, another reads, another checks. They hand work to each other or report to a coordinator.
It helps when a task splits into independent parts that can run at the same time, or when one agent would have to juggle too much information. It also multiplies cost and adds new failure modes, like two agents making conflicting assumptions.
A newsroom: reporters chase separate leads at once and an editor assembles the story — great for an election night, overkill for the weather.
Designing agents like an org chart ("manager", "coder", "tester") for a sequential, tightly coupled task. Role-play adds handoffs and tokens without adding capability.
Topologies: Orchestrator–worker pattern (lead agent delegates and synthesises), sequential handoffs (control passes between specialists), and peer/debate setups. The real benefit is context isolation: each sub-agent explores in a clean Context window and returns a compressed result. Anthropic's research system (June 2025) beat a single Opus 4 agent by 90.2% on its internal research eval, found token usage alone explained 80% of BrowseComp variance, and cost about 15× the tokens of chat.
The costs are structural. Cemri et al. (2025) catalogued 14 failure modes in 3 groups — system design, inter-agent misalignment, task verification. Cognition's "Don't Build Multi-Agents" (2025) argues that sub-agents acting on partial context make conflicting decisions on tightly coupled work like editing one codebase. The rule that falls out: split by independent context (breadth-first research, per-document analysis), keep tightly coupled writes in one agent, and evaluate end to end with Trajectory evaluation.
Single agent first. Add sub-agents only for read-only, separable breadth (one per document, company or source), with self-contained briefs, structured outputs ≤500 tokens, a fan-out cap of ~10, one trace ID across all agents, and writes kept in the lead agent.
Due diligence on 8 acquisition targets' financial filings: a lead agent spawns 8 sub-agents, each reading one company's 10-K with a fresh context and returning a 300-word brief with cited page numbers. Wall time drops from ≈ 9 min sequential to ≈ 2 min; total tokens rise from ≈ 400k to ≈ 1.2M, ≈ $3.70 vs $1.25 at $3 / M input. Worth it for an analyst waiting; not worth it for a nightly batch.
Push back first: "why more than one agent?" Recommend multi-agent only for breadth-first, separable work where latency or context size is the binding constraint; keep coupled writes in one agent.
Expect the follow-up "how do you debug it?" — a single trace ID across agents, structured sub-agent outputs, and end-state evals rather than per-agent vibes.
Numbers worth knowing
- Quality gain on breadth-first research
- +90.2%multi-agent vs single Opus 4, Anthropic internal eval, June 2025
- Token cost vs chat
- ≈15×same source; single agent ≈4×
- Catalogued failure modes
- 14 in 3 categoriesCemri et al. 2025, across multiple frameworks
How to decide
| When | Do this |
|---|---|
| Sub-tasks are independent reads (N documents, N sources) | Fan out to sub-agents with clean contexts. |
| Sub-tasks write to the same artefact (one codebase, one contract) | One agent; use sub-agents only for read-only exploration. |
| Latency doesn't matter (batch jobs) | Prefer sequential single-agent runs; save the 3× tokens. |
Cost maths
Cost ≈ lead tokens + Σ sub-agent tokens; each sub-agent re-reads its own instructions and history. Diligence example at $3 / $15 per M (illustrative, Oct 2026): single agent ≈ 400k in / 8k out = $1.32; 8 sub-agents × 140k in + lead 80k ≈ 1.2M in, 20k out = $3.90. You pay ≈ 3× to cut wall time ≈ 4.5×.
Operating it
- A single agent's context passes ~60% of the window on breadth tasks
- Analyst-facing latency SLO missed because work is sequential
- Sub-agents' results overlap by >20% (briefs need tightening, not more agents)
- Sub-agents spawned per run (alert when p95 > the fan-out cap)
- Tokens per successful task, multi vs single baseline (alert if ratio > 4×)
- Duplicate-work rate across sub-agent outputs (alert > 20%)
When it goes wrong
Anthropic reported that early versions of its research system spawned 50 sub-agents for simple queries and searched endlessly for sources that didn't exist.
Internal evals and trace review during development (June 2025 write-up).
The lead agent had no guidance on effort; it could not judge how much fan-out a query deserved.
Scaling rules embedded in the prompt: simple fact-finding = 1 agent with 3–10 tool calls; comparisons = 2–4 sub-agents with 10–15 calls each; complex research = 10+ sub-agents with divided responsibilities.
Related terms
Sources
- How we built our multi-agent research system — Anthropic, 2025blog
- Why Do Multi-Agent LLM Systems Fail? — Cemri et al., 2025paper
- Don't Build Multi-Agents — Cognition, 2025blog
Check yourself
Three questions. Every option is explained once you answer.