Lessons from Anthropic's multi-agent research system
TL;DR
Anthropic's multi-agent system beat a single agent by 90.2% on an internal research eval but uses about 15× the tokens of chat. It's only worth it for high-value, parallelisable work; delegate clearly and evaluate early.
Researching a complex topic is unpredictable: you don't know how many sources you'll need or which direction to take. Anthropic shared how it built Claude's Research feature as a multi-agent system, with numbers, prompting principles and real operational lessons. It's one of the most practical reads on agents, especially the part on when not to use multiple agents.
Orchestrator–worker architecture
- A lead agent analyses the question, plans, and saves the plan to memory in case the context gets truncated.
- The lead spawns several subagents that search in parallel, each with its own context and line of investigation.
- The lead synthesises the results and can spawn more subagents if gaps remain.
- A CitationAgent attaches sources to each claim in the final report.
Notable numbers
| Finding | Number |
|---|---|
| Multi-agent (Opus 4 lead, Sonnet 4 subagents) vs single-agent Opus 4 on an internal research eval | 90.2% better |
| Share of performance variance on BrowseComp explained by token usage | About 80% |
| Token usage compared with chat | Agents ~4×, multi-agent ~15× |
| Parallelising subagents and tool calls | Up to 90% less research time on complex queries |
The core message: multi-agent works largely because it lets you spend more tokens in parallel. That's both its strength and its cost.
Prompting principles for multi-agent systems
- Simulate the agent step by step yourself to see where it fails.
- Delegation to subagents must include: an objective, an output format, tool guidance and task boundaries. Without them, subagents duplicate work or leave gaps.
- Set explicit rules for scaling effort to query complexity (simple questions need one agent and few calls).
- Design tools with distinct purposes and clear descriptions; use Claude itself to diagnose and rewrite tool descriptions (in one case cutting completion time by 40%).
- Search broad first, then narrow.
Evaluating agents
- Start small: about 20 representative queries were enough to see large effects.
- LLM-as-judge with a rubric: factual accuracy, citation accuracy, completeness, source quality, tool efficiency.
- Human testers still caught what automation missed, such as agents favouring SEO content farms over authoritative sources.
When not to use multiple agents
- When agents need shared context or have many interdependencies.
- Problems with little parallelisable work, such as most coding.
- Low-value tasks that can't justify many times the token cost.
Operational risks
- Compounding errors in stateful agents: resume from checkpoints rather than restarting from scratch.
- Hard to debug because non-deterministic: production tracing is needed to see decision patterns.
- Deploying while agents are mid-run: Anthropic uses rainbow deployments, gradually shifting traffic from old to new versions.
How to apply it
- Dev: When delegating to a subagent, write it as you would for a new colleague: objective, scope, output format.
- Tech Lead: Choose multi-agent only for broad, parallelisable search; for code, one strong agent is usually better.
- PM: Budget with a ~15× token multiplier versus chat before promising a "deep research" feature.
Sources & references
- How we built our multi-agent research system — Anthropic Engineering