How We Built Our Multi-Agent Research System

How the system is built

The design is an orchestrator and worker pattern. A lead agent analyses the query, plans a research strategy and saves the plan to memory so it survives if the context fills up. It then spawns subagents that search different angles in parallel, each with its own clean context. A final citation step attributes claims to sources.

What the numbers say

The article reports that a multi-agent setup (Claude Opus 4 leading, Claude Sonnet 4 subagents) outperformed a single Opus 4 agent by 90.2% on its internal research evaluation. It also reports that token usage alone explained 80% of the variance in performance, and that multi-agent systems used about 15 times more tokens than ordinary chat.

The honest reading is that much of the gain comes from spending more compute on a problem that splits naturally into parallel parts. That is worth it for broad research questions and wasteful for most other tasks.

Lessons on prompting and evaluation

The team lists principles it learned the hard way, including:

• Teach the lead agent to delegate with a clear objective, output format, tools and boundaries for each subagent, or subagents duplicate work.
• Scale effort to query complexity so simple questions do not spawn a crowd of agents.
• Give tools distinct purposes and clear descriptions.
• Search broadly first, then narrow.
• Let the model help improve its own prompts and tool descriptions by diagnosing failures.

For evaluation, it recommends starting with a small set of around 20 realistic queries rather than waiting for a large benchmark, using a language model as a judge against a rubric, and keeping human testing to catch problems automation misses.

The production problems nobody mentions in demos

• Agents are stateful and long-running, so an error part way through needs resumable execution, not a restart.
• Runs are non-deterministic, which makes full tracing essential for debugging.
• Deploying new code must not break agents that are mid-task.
• Subagents running synchronously create bottlenecks, but asynchronous coordination adds its own complexity.

When not to use multiple agents

The article is clear that multi-agent designs fit poorly when all agents need the same context, when there are many dependencies between steps, or when the task does not parallelise. It names most coding tasks as an example. Read it alongside Building Effective Agents before deciding one agent is not enough.

Common questions

Is the 90.2% figure a public benchmark? No. It comes from Anthropic's internal research evaluation, so treat it as evidence for the approach rather than a number to compare across vendors.

Can I build something similar myself? Yes. The orchestrator and worker pattern needs nothing proprietary. The hard parts are the prompts, evaluation and reliability work the article describes.

Should a student project use multiple agents? Rarely. A single agent with good tools is simpler to build, debug and pay for. Use this article to understand when the extra cost is justified.

Best for: engineers designing research or search-heavy AI systems, and anyone tempted to add more agents to fix a quality problem.