Orchestrator-Worker Subagent Architectures

Anthropic reports that a multi-agent system using Claude Opus 4 as lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on their internal research evaluation (Anthropic, How we built our multi-agent research system, 13 June 2025). Cognition published a post three weeks earlier titled Don't Build Multi-Agents (Yan, 12 June 2025). Both are right, and the condition that separates them is the whole design question.

The mechanism

An orchestrator receives the task, decides how to split it, and spawns workers. Each worker starts with a fresh context window containing only its own instruction, runs its own tool-calling loop, and returns a result. In Anthropic's research system a LeadResearcher plans and delegates, subagents search independently with interleaved thinking, and a separate CitationAgent attributes claims to sources at the end.

The token asymmetry is the point. A subagent "might explore extensively, using tens of thousands of tokens or more, but returns only a condensed, distilled summary of its work (often 1,000-2,000 tokens)" (Anthropic, Effective context engineering for AI agents, 29 September 2025). The orchestrator's window grows by kilobytes while the system does megabytes of work. That is a compression ratio no summarisation prompt achieves, because the discarded material was never in the orchestrator's window to begin with.

Parallelism is the second gain and the more obvious one: four subagents searching four sources concurrently finish in roughly the time of the slowest, not the sum.

Why it costs so much

Anthropic's measurement is that agents use roughly 4x the tokens of chat interactions, and multi-agent systems roughly 15x. On BrowseComp, "token usage by itself explains 80% of the variance" in performance, with three factors together explaining 95%.

Read that carefully, because it cuts both ways. It is the strongest available argument that multi-agent architectures work, since spending more tokens is most of what they do and spending more tokens is most of what predicts success. It is also the strongest argument that the architecture is a delivery mechanism for token spend rather than a source of intelligence, and that any other way of spending the same budget might do as well.

When it fails

Cognition's objection is not about cost. It is that parallel subagents make implicit decisions that conflict. Their two principles: "Share context, and share full agent traces, not just individual messages", and "Actions carry implicit decisions, and conflicting decisions carry bad results." Their example is building a Flappy Bird clone where one subagent renders a Super Mario-style background while another builds a bird with mismatched physics, and no downstream agent can reconcile the two because neither one's reasoning was ever visible to the other.

Anthropic's own guidance agrees on the boundary. Domains "that require all agents to share the same context or involve many dependencies between agents are not a good fit", explicitly including most coding tasks.

The rule that falls out is clean. Subagents work when the subtasks are read-only, independent, and verifiable in isolation: search a source, read a file, run a check. They fail when subtasks write to a shared artefact, because writes encode decisions and isolated context means unshared decisions.

The other failure modes

Error compounding. Agents are stateful and errors compound; a subagent that starts down a wrong interpretation burns its whole budget there and returns a confident, wrong summary. The orchestrator has no trace with which to catch it.

The summary is lossy in the direction that matters. What a subagent discards is exactly what the orchestrator did not know to ask for.

Debugging is non-deterministic across two levels. Reproducing a failure needs the orchestrator's decomposition and each worker's trajectory, and neither is stable across runs.

Coordination cost is real. Anthropic notes their subagent execution was synchronous, so the orchestrator waits for the slowest worker, and deployment of a running fleet needs staged rollouts rather than a restart.