Multi-agent architectures get pitched as the natural next step once a single agent's prompt gets crowded: a planner here, a researcher there, a critic to review before anything ships. Sometimes that's the right call. Often it's a more expensive way to get the same result, with a new class of bugs layered on top. The best public evidence on when it pays off comes from Anthropic's engineering write-up of its own multi-agent research system, which this article draws on.
What a multi-agent system looks like in practice
Anthropic describes an orchestrator-worker pattern: a lead agent analyzes the query, develops a strategy, and spawns specialized subagents that explore different aspects in parallel. The lead then combines what they return.
The headline result is striking. In Anthropic's internal research evaluation, the multi-agent setup outperformed a single agent by 90.2%. It's a result on the company's own task and its own evaluation, so treat it as a demonstration that the approach can win, not as a general rate.
The cost that comes with it
The same write-up is candid about the price. Agents typically use about 4× more tokens than a chat interaction, and multi-agent systems about 15× more. Anthropic also reports that token usage alone explains about 80% of the variance in performance on the browsing benchmark it analyzed. In other words, a good part of the gain comes from simply spending more compute on the problem across several context windows.
That makes the economics the first question. The write-up says multi-agent systems need tasks where the value is high enough to pay for the increased performance.
When splitting earns its cost
According to the write-up, the good fits are:
- Breadth-first work with several independent directions, where subtasks can run at the same time.
- Tasks that exceed a single context window, so the information has to be spread across agents.
- Problems with complex tool interfaces, where different agents can specialize.
It's explicit about the poor fits: most coding tasks, which involve fewer truly parallelizable pieces; domains where every agent needs the same shared context; tasks with many interdependencies; and anything needing real-time coordination.
My addition, not Anthropic's: a review relationship is a legitimate third reason. A critic agent that sees only the output, not the chain of reasoning behind it, is less likely to rubber-stamp a mistake the first agent made.
Reasons that don't hold up
"The prompt got long" is usually a sign to restructure the prompt. A well-organized single prompt often beats two agents passing a lossy summary between them. "It feels like how a team works" ignores that agents don't share the informal context a human team gets for free, so every handoff has to be built explicitly, and every handoff is a place where information gets dropped or repeated at extra token cost.
A useful test before you split: describe the handoff between two agents in one sentence, in terms of what data crosses the boundary. If you can't, you don't have an interface yet. You have a bigger single prompt with extra steps and a bigger bill.
What goes wrong, per the people who built one
The lessons from Anthropic's build are worth reading as a list of failure modes:
- Coordination. Early versions spawned too many subagents, ran endless searches and duplicated work. The fix was detailed task descriptions for each subagent and explicit rules for how much effort a query deserves.
- Evaluation. Checking each step doesn't work, because agents can reach a good result by different paths. They moved to outcome-focused assessment, used LLM judges against a rubric, and relied on human testing to catch edge cases.
- Errors compound. Agents are stateful, so a small failure early can derail everything after it. Mitigations included resumable checkpoints, graceful degradation and production tracing.
- Operations. Minor changes can cascade into large behavioural changes, and updating a system while agents are mid-run needs care. They describe using rainbow deployments to avoid disrupting running agents.
A practical rule
Start with one agent and a well-structured prompt. Add a second only when you can name the specific reason (parallel work, a real context or skill boundary, an independent review), state the handoff in one sentence, and show that it beats the single-agent version on your own evaluation, including the cost. For a closely related design question, see Designing the Handoff Contract Between Agents, and for how agents earn trust in practice, Agentic Coding Assistants.
Comments (0)
No comments yet — be the first.
Sign in to leave a comment.