18 Jun 2025 AI Engineering 5 min read

The Multi-Agent Debate: Why Both Sides Are Right

On June 12 and 13, 2025, Cognition and Anthropic published apparently opposite advice on multi-agent LLM systems. We compare "Don't Build Multi-Agents" with Anthropic's research-system post — a 90.2 percent lift at roughly 15x token cost — and derive a decision rule: parallelize decomposable breadth, keep shared-context work single-threaded.

Two Posts in 24 Hours

On June 12, 2025, Cognition — the company behind the coding agent Devin — published an essay titled "Don't Build Multi-Agents." One day later, Anthropic published "How we built our multi-agent research system," reporting that a multi-agent setup beat a single agent by 90.2 percent on an internal research evaluation. Two experienced engineering teams, two production systems, and within 24 hours two apparently opposite recommendations. The posts were immediately read as a debate about the right way to build agentic systems.

The underlying question is narrow and technical: when does splitting a task across multiple LLM agents with separate context windows improve results, and when does it make them worse? Both posts argue from measured production experience, not intuition. Read side by side, they contradict each other far less than the headlines suggest. They describe different classes of tasks.

A task arrives — the agent plans its next step. 1/4

The Case Against Multi-Agents

Walden Yan's essay is an argument about reliability. It states two principles. First: share context — full agent traces, not just individual messages. Second: actions carry implicit decisions, and conflicting decisions produce bad results. Parallel subagents that cannot see each other's work make incompatible implicit choices. Yan's example is a Flappy Bird clone: one subagent builds the bird, another the background, and the results arrive in two different visual styles that do not compose.

His recommendation is a single-threaded, linear agent. When traces outgrow the context window, Cognition uses a dedicated model that compresses history into key details — not a second autonomous agent. Yan also notes what restraint looks like in practice: as of June 2025, Claude Code spawns subagents only to answer well-defined questions, never to write code in parallel. His verdict for 2025: agent-to-agent collaboration produces fragile systems, because cross-agent context passing is unsolved.

The Orchestrator-Worker Answer

Anthropic's post describes the architecture behind the Research feature in Claude: an orchestrator-worker pattern, a term the company had already defined in "Building effective agents" in December 2024. A lead agent running Claude Opus 4 analyzes the query, saves a plan to memory, and spawns three to five Claude Sonnet 4 subagents that search the web in parallel, each with its own context window. Subagents return condensed findings; the lead synthesizes; a citation agent attributes every claim to a source.

The measured result: the multi-agent system outperformed single-agent Claude Opus 4 by 90.2 percent on Anthropic's internal research eval. The canonical example is a breadth query — identify all board members of the S&P 500 information-technology companies — which decomposes cleanly and exceeds a single 200,000-token context window. Parallel subagents and parallel tool calls cut research time for complex queries by up to 90 percent. Anthropic is equally open about failure modes: early versions spawned dozens of subagents for simple queries and searched endlessly for nonexistent sources.

What the Numbers Actually Say

Anthropic names the mechanism explicitly, and it is not emergent intelligence. It is token budget. In their analysis of the BrowseComp benchmark, three factors explained 95 percent of performance variance; token usage alone explained 80 percent, with tool-call count and model choice covering the rest. A multi-agent architecture is primarily a way to spend more tokens on a problem than a single context window permits.

The cost side is quantified with the same precision. Agents use roughly 4 times the tokens of a chat interaction; multi-agent systems roughly 15 times. A 90.2 percent lift at 15x token cost is a trade, not a free win. Anthropic draws the consequence itself: the economics only work for tasks whose value justifies the spend.

Decomposable Breadth vs Shared Context

Both teams draw the same boundary — from opposite sides. Anthropic's post concedes the Cognition case almost verbatim: domains that require all agents to share the same context, or that involve many dependencies between agents, are a poor fit today, most coding tasks among them. Cognition's essay concedes the inverse: read-only subagents that answer bounded questions are useful, precisely because their findings carry no conflicting write decisions.

The dividing line is the dependency structure of the task. Breadth-first work that decomposes into independent read-only subtasks — research, source triage, evaluation across many documents — parallelizes well, and separate context windows become an asset. Write-heavy work in which every step embeds implicit decisions — code edits, refactorings, a document with one voice — needs a single thread of shared context. Architecture should follow the task, not the trend.

A Decision Rule Before You Build

In our agent projects at Blue IT Systems we reduce the two posts to three questions, asked before any second agent is added. Are the subtasks genuinely independent? Are the subagent outputs reads — reports, lists, citations — rather than writes? Does the value of the task cover roughly an order of magnitude more tokens? Three times yes justifies an orchestrator-worker design. A single no means: one thread, better context engineering.

The checklist does not capture everything. It ignores latency, which parallelism improves even at equal quality, and it ignores operational complexity: multi-agent systems are harder to evaluate and debug because non-determinism compounds across agents. Anthropic's post is candid about both. Treat the three questions as a filter, not a proof.

Criterion	Orchestrator-worker	Single thread
Task shape	Breadth-first, decomposable	Sequential, interdependent
Subagent output	Read-only findings	Writes and edits
Context requirement	Fits per-agent windows	Must be shared end to end
Token cost vs chat	~15x	~4x
Typical failure	Gaps or duplicated coverage	Context overflow

What Comes After the Debate

Seen from June 2025, we expect the split to harden before it dissolves. Research-style products will adopt orchestrator-worker patterns, because the economics of breadth queries support them. Coding agents will stay single-threaded and invest in context compression. Notably, both posts name the same open problem: reliable context passing between agents. Yan expects the solution to fall out of better single-agent communication; Anthropic expects models to get better at delegating and coordinating.

Numbers like 90.2 percent and 15x will do more for the field than any framework release, because they turn architecture into a decision with a cost model. What neither post solves is parallel writing: until agents can negotiate implicit decisions with each other, the safe default remains one writer and many readers. Predictions in this field age in months. These two posts, we think, will stay readable longer than most.