Lessons from Anthropic's Research System

Why one agent wasn't enough

Anthropic's Research feature answers open-ended questions like "find all the board members of companies X, Y, and Z." A single agent doing that sequentially has two problems: it is slow, and every page it reads piles into one context window until the window fills up and quality degrades.

The fix was a multi-agent system: one lead agent (the orchestrator) that plans the work, plus several subagents — separate Claude instances, each with its own fresh context window — that research different pieces in parallel. Because each subagent carries its own context, the system's total effective "memory" is much larger than any single window, and because they run at the same time, breadth-first questions finish far faster.

The architecture in one pass

1. Plan. The lead agent analyzes the query and writes a research plan. It saves that plan to persistent memory — storage outside the context window — so the plan survives even if the lead's 200k-token context gets truncated mid-task.
2. Spawn. The lead creates 3–5 subagents in parallel, each with an explicit task.
3. Search. Each subagent runs its own search-read-evaluate loop, also making 3+ tool calls in parallel.
4. Synthesize. Subagents return condensed findings (not their raw transcripts). The lead merges them into one answer.
5. Cite. A dedicated CitationAgent goes back through the answer and attributes each claim to a source.

Parallelizing at both levels — parallel subagents and parallel tool calls inside each subagent — cut research time by up to 90% on complex queries.

Lesson 1: delegation must be painfully explicit

Early versions gave subagents vague tasks like "research semiconductors." Two subagents would then do nearly identical searches — wasted tokens, duplicated findings, gaps where nobody looked.

The fix: every subagent task states four things —

• a clear objective (what question this subagent answers),
• an output format (what its summary must contain),
• tool guidance (which tools to use and how),
• task boundaries (what it should NOT research, so lanes don't overlap).

Treat a subagent like a contractor you'll never talk to again after handing over the brief. If the brief is ambiguous, the work will be too.

Lesson 2: scale effort to the question

Left alone, agents either overkill a trivial question or under-resource a hard one. The lead agent's prompt embeds explicit effort rules:

Encoding this in the prompt matters because the model has no innate sense of what a query "deserves" — you have to give it a budget policy.

Lesson 3: search broad, then narrow

Agents default to long, hyper-specific search queries that return nothing. Humans do the opposite: start broad ("EV battery manufacturers"), skim what exists, then narrow ("CATL cathode suppliers 2025"). Prompting subagents to start with short broad queries and progressively narrow made searches land far more often.

Lesson 4: let the agent fix its own tools

Anthropic built a tool-testing agent: it used each tool repeatedly, noticed where it failed or got confused, and rewrote the tool's description. Future agents using the rewritten descriptions completed tasks 40% faster, because the descriptions now warned about exactly the mistakes agents actually make. Your agents' transcripts are a free usability study — mine them.

Lesson 5: tokens are the real bill

Measured on research evals, token usage alone explains about 80% of performance variance — the systems that read more, score better. But that spend compounds:

• a chat interaction ≈ 1x tokens
• a single agent ≈ 4x (tool calls, retries, long trajectories)
• a multi-agent system ≈ 15x

So multi-agent is only economical for high-value tasks that parallelize cleanly. Most coding tasks are a bad fit: the subtasks share tight context (the same files, the same types), so parallel agents step on each other or duplicate understanding. Breadth-first research — many independent strands, merged at the end — is the sweet spot.

Lesson 6: production is where it gets hard

Three practices kept the system shippable:

• Resume, don't restart. Agents run for minutes and fail mid-flight. Resuming from the error point (the saved plan and partial findings) beats throwing everything away.
• Trace everything. Agent failures are non-deterministic — you cannot reproduce them by re-running. Full tracing of decisions and tool calls is the only way to debug.
• Rainbow deployments. Roll out prompt/model updates gradually so in-flight agents finish on the version they started with, instead of breaking mid-task.

What to carry into interviews and your own systems

If you're asked "when would you use multiple agents?", the honest answer from this system is: when the task is parallelizable, breadth-first, and worth roughly 15x chat-level token spend — and when you're prepared to write delegation briefs, effort budgets, and tracing, because those, not the architecture diagram, are where the engineering lives.