1Context and scope
A research question is too broad for one agent to answer in one pass, so a lead agent plans, hands sub-questions to several subagents that run in parallel with their own context, searching and reading pages, and then synthesises their findings. Token use grows with the number of subagents and the pages they read, and any subagent failure can cost the whole answer. This design covers one such system at browser scale, based on Anthropic’s write-up of its multi-agent research system.
2Goals and non-goals
Goals
- 1 question a second. The lead agent takes 2 turns; each turn fans out to 4 parallel subagents that each call the model, search, and browse on half their steps.
- Success at least 95%, p99 at most 180 s.
- The lead compacts on 30% of turns and writes memory and a checkpoint every turn.
Non-goals
- Citation verification and the final report format.
- Paid data sources.
- A user interface for steering the research.
3Capacity estimate
| Quantity | Value | How |
|---|---|---|
| Subagent runs | ≈ 8/s | 1 question × 2 turns × 4 subagents |
| Model calls | ≈ 10/s | 8 subagent calls plus 2 lead calls |
| Streams held | ≈ 10 × 6 s ≈ 60 | 0.5 s to first token plus 500 tokens at 90 a second; 2,000 available |
| Searches | ≈ 8/s at 0.3 s | 2.4 of 400 slots busy |
| Browser sessions | ≈ 4/s at 2.5 s | half the subagent steps; 10 of 200 browsers busy |
| Compounding | 8 subagent runs × (0.1% + 0.5 × 0.2%) | about 1.6% of questions lose a subagent |
The rest of the doc
The design · Key concepts · Alternatives considered · Failure modes and fixes · Try it in the lab · Check yourself · Further reading
Unlock the Deep research (multi-agent) design doc
Every component and why it is there, the capacity numbers behind it, what breaks when you push it and how to fix it, and the same system open in the lab to break and fix yourself. Paid once, on your account.