Public case (sourced). Based on Anthropic Engineering's published post "How we built our multi-agent research system" (13 June 2025); every fact below is attributed to it.
This case belongs to Multi-agent and event-driven AI architecture. Where the post is silent, this page says so.
Context
Anthropic's post says Claude now has Research capabilities that let it search across the web, Google Workspace and any integrations to accomplish complex tasks. The post is an engineering account of how that feature's multi-agent system was built. It defines a multi-agent system as multiple agents (LLMs autonomously using tools in a loop) working together.
The post does not publish usage volumes, response times in seconds or dollar costs.
Problem statement
The post says research work involves open-ended problems where it is very difficult to predict the required steps in advance, and that a fixed path for exploring complex topics cannot be hard-coded. It frames search as compression: distilling insights from a vast corpus. It measures the answer on its internal research evaluation: a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2%. The post does not say how large that evaluation was or how the percentage is computed.
Constraints
As the post states them:
- If the context window exceeds 200,000 tokens it is truncated, so the lead agent's plan must be kept outside it.
- Agents typically use about 4 times more tokens than chat interactions, and multi-agent systems about 15 times more.
- For economic viability the task's value must be high enough to pay for the increased performance.
- Domains that need all agents to share the same context, or that have many dependencies between agents, are not a good fit today.
- Agents are stateful and errors compound; running agents must not be disrupted by deployments.
Why the traditional approach fell short
The post says traditional approaches using retrieval-augmented generation (RAG) use static retrieval: they fetch the chunks most similar to the query and generate from them. Its architecture instead uses a multi-step search that finds information dynamically, adapts to new findings and analyses the results. The post does not compare against rules engines or manual research.
Options considered
| Option | What the post says | Verdict in the post |
|---|---|---|
| A. Static retrieval (RAG) | Fetches the chunks most similar to the query and generates from them | The post contrasts it with the multi-step search it built |
| B. Single agent | The baseline in the 90.2% comparison (single-agent Claude Opus 4) | Outperformed by the multi-agent system on the post's internal evaluation |
| C. Orchestrator-worker multi-agent | A lead agent coordinates and delegates to subagents running in parallel, each with its own context window | The post's choice |
A reader's simpler alternative, not from the post: if the question shape is known in advance, a fixed search-then-summarise pipeline avoids the multi-agent cost. The post says this system is for open-ended research.
Solution architecture
The names in the figures are the post's: LeadResearcher, Subagents, Memory, CitationAgent.
Figure 1. The research system's components as the post describes them
How to read this: the arrow from Subagents back to the LeadResearcher is the loop; the post says the lead decides whether more research is needed, and the box labels use the post's component names.
Figure 2. One research request in the order the post describes
How to read this: the opt block is the lead's decision to continue, and the post does not say which component hands the final answer to the user, so the last arrow follows its sentence that the cited results are returned to the user.
How AI solved it, step by step
The post's sequence, in its own order:
- A user query reaches the LeadResearcher, which analyses it and develops a strategy.
- It thinks through the approach and saves its plan to Memory, because of the 200,000-token truncation.
- It spawns subagents to explore different aspects at the same time. The post says each subagent needs an objective, an output format, guidance on tools and sources, and clear task boundaries.
- Each subagent searches independently, evaluates the results with interleaved thinking and returns findings.
- The LeadResearcher synthesises the findings and decides whether more research is needed; if so it can create additional subagents or refine its strategy.
- The findings go to a CitationAgent, which processes the documents and report to identify where citations belong.
- The cited results go back to the user.
Why step 3 needs detail, per the post: without detailed task descriptions, agents duplicate work, leave gaps or fail to find the information.
Under the hood
The key claim in the post is about tokens, not agents. For BrowseComp, an evaluation that tests the ability of browsing agents to locate hard-to-find information, the post says three factors explained 95% of the performance variance, and token usage by itself explained 80%. The other two factors it names are the number of tool calls and the model choice. From this it concludes that multi-agent systems work mainly because they help spend enough tokens to solve the problem: subagents with their own context windows spend tokens in parallel, and the post says each also provides separation of concerns and reduces path dependency. It adds that upgrading to Claude Sonnet 4 is a larger gain than doubling the token budget on Claude Sonnet 3.7. The post does not publish the BrowseComp scores or the statistical method behind the 95% and 80%. In its appendix it says subagents can store their work in external systems and pass lightweight references back to the coordinator, rather than routing everything through the lead. The general mechanism is covered in the Multi-agent and event-driven lesson.
What went wrong / failure modes
All from the post:
- Effort mis-scaling. Early agents made errors such as spawning 50 subagents for simple queries, searching the web endlessly for sources that did not exist, and distracting each other with excessive updates. The post's mitigation: scaling rules embedded in the prompts, for example one agent with 3 to 10 tool calls for simple fact-finding.
- Duplicated or missing work from vague delegation, mitigated by detailed task descriptions.
- Bad tool choices and descriptions. The post says a tool-testing agent rewrote flawed tool descriptions and a 40% decrease in task completion time for future agents followed.
- Source quality. Human testers noticed early agents consistently chose SEO-optimised content farms over authoritative sources; the fix was source-quality heuristics in the prompts.
- Compounding errors. The post says restarts were too costly, so it built systems that can resume from where the agent was, with retry logic and regular checkpoints, plus full production tracing.
- Deployments. Rainbow deployments avoid disrupting running agents.
- Synchronous execution. Lead agents wait for each set of subagents to finish, which the post says creates bottlenecks; it expects asynchronous execution to add parallelism and also to add challenges in result coordination, state consistency and error propagation.
Results
Only numbers the post publishes, each with its caveat:
- Multi-agent (Opus 4 lead, Sonnet 4 subagents) outperformed single-agent Opus 4 by 90.2% on Anthropic's internal research evaluation.
- Agents use about 4 times more tokens than chat, and multi-agent systems about 15 times more.
- On BrowseComp, token usage alone explained 80% of performance variance; three factors together explained 95%.
- The post says parallel tool calling cut research time by up to 90% for complex queries.
- The post says tool-description rewriting led to a 40% decrease in task completion time.
- Its first evaluation set was about 20 queries; an LLM judge scored outputs on factual accuracy, citation accuracy, completeness, source quality and tool efficiency, and a single LLM call outputting scores from 0.0 to 1.0 and a pass-fail grade was most consistent with human judgement.
The post does not give costs in money, latency in seconds, or the size of the evaluation behind the 90.2%.
Tradeoffs and when NOT to use this approach
From the post: it needs high-value tasks that parallelise well; it is a poor fit where agents must share context or depend heavily on each other; most coding tasks have fewer truly parallelisable tasks than research; and the authors say agents are not yet great at coordinating and delegating to other agents in real time. The post also says small changes to the lead agent can change subagent behaviour in large ways. A reader can check the cost of a 15-times token multiplier with the LLM cost estimator.
Design rules extracted
Each rule restates something the post reports:
- Tell the orchestrator how to delegate: objective, output format, tool guidance and boundaries per subagent.
- Put effort rules in the prompt, because agents misjudge how much work a query needs.
- Keep the plan outside the context window so truncation cannot erase it.
- Make long-running agents resumable and traceable, and deploy without cutting off running agents.
- Start evaluation with a small set, keep human testers, and judge end states instead of exact steps.
Sources
- Anthropic Engineering, "How we built our multi-agent research system", 13 June 2025: https://www.anthropic.com/engineering/multi-agent-research-system (read 2026-10-21)
Last verified: 2026-10-22