DEV Community

Cover image for Multi-agent is usually overkill: start with one agent and earn the second
M.T.Ramkrushna
M.T.Ramkrushna

Posted on

Multi-agent is usually overkill: start with one agent and earn the second

Wednesday AI Opinion. Here's my hot take: most teams reaching for a multi-agent architecture should build one well-tooled agent first, and only split it when they can measure why.

"Planner agent, researcher agent, coder agent, reviewer agent" looks great on a diagram. In practice, every split is a handoff, every handoff loses context, and you pay for it in tokens. Multi-agent is a real tool for a specific shape of problem. It is not the default.

The cost is real, and Anthropic published it

Anthropic's write-up on how they built Claude's Research feature is the best public case for multi-agent systems, and it is honest about the bill:

  • Agents typically use about 4x more tokens than chat interactions.
  • Multi-agent systems use about 15x more tokens than chats.
  • Their words: multi-agent systems "require tasks where the value of the task is high enough to pay for the increased performance."

They also say token usage by itself explained 80% of the performance variance on the BrowseComp evaluation. In other words, a big part of why multi-agent works is that it lets you spend more tokens in parallel. That is useful, but it means you should ask whether you actually need to spend them.

Context is the thing that breaks

Cognition's "Don't Build Multi-Agents" post (Walden Yan, June 2025) explains the failure mode with a simple example: split "build a Flappy Bird clone" into a background subagent and a bird subagent, and you can get a Super Mario style background and a bird that doesn't match, because neither subagent saw what the other decided.

Their two principles are worth putting on the wall:

  1. Share context, and share full agent traces, not just individual messages.
  2. Actions carry implicit decisions, and conflicting decisions carry bad results.

Their recommendation: the simplest way to follow both is a single-threaded linear agent, which "will get you very far."

Anthropic lands in the same place for some domains: work where all agents need the same context, or with many dependencies between agents, is "not a good fit for multi-agent systems today." They call out coding specifically, since most coding tasks involve fewer truly parallelizable pieces than research.

Where multi-agent does earn its keep

This isn't "never." Anthropic reports a multi-agent setup (Claude Opus 4 lead, Claude Sonnet 4 subagents) outperformed single-agent Claude Opus 4 by 90.2% on their internal research eval. Their example: finding all board members of the companies in the IT sector of the S&P 500, where the single agent failed with slow, sequential searches.

They describe where it shines:

  • Heavy parallelization (breadth-first questions with many independent directions)
  • Information that exceeds a single context window
  • Interfacing with numerous complex tools

Notice the pattern: independent subtasks that return compressed findings to one lead agent. That is very different from agents that need to co-edit the same artifact.

How I'd decide

Anthropic's older "Building effective agents" guide says it plainly: find the "simplest solution possible, and only increasing complexity when needed." My checklist:

  1. Start with one agent and good tools. Most "we need more agents" problems are really tool or prompt problems.
  2. Split only when the subtasks are truly independent. If subagents have to agree on style, schema or design, keep it in one thread.
  3. Pass full context, or pass nothing. A one-line task description to a subagent is how you get duplicate or conflicting work. Anthropic found vague instructions led subagents to repeat each other's searches.
  4. Prefer read-only subagents. Let them research and report back; keep the writes in one place.
  5. Measure cost per successful task. If the multi-agent version doesn't beat the single agent on your eval by enough to cover ~15x tokens, don't ship it.

One agent that sees everything beats four agents that each see a quarter.

References

What's the most useful multi-agent split you've actually shipped? I'd like to hear where it paid off.

Top comments (0)