Orchestrator–Worker

Picture an engineering lead who has just read that a multi-agent system beat a single agent by 90.2% on a hard task. The obvious move is to try the same shape on the next big ticket — a cross-cutting refactor touching six files — by spinning up five subagents in parallel, one per file, and letting them work simultaneously. An hour later the branch is a mess: two agents renamed the same interface differently, a third built against the pre-rename signature, and the lead spends the rest of the afternoon doing by hand the reconciliation the fan-out was supposed to save.

Nothing about that outcome contradicts the 90.2% figure. It contradicts the assumption that the figure travels. The number comes from a real, carefully documented Anthropic engineering system, and it is genuine evidence for exactly one shape of problem, measured on exactly one kind of task. Reading past the headline into how that system was actually built — and into where Anthropic itself says it stops working — is the only way to know whether the pattern belongs on your ticket or in your postmortem.

What the 90.2% actually measured

The claim, verbatim from Anthropic’s account of the system: “a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval.” Two qualifiers do most of the work in that sentence. The comparison is single agent versus multi-agent, not multi-agent versus a human team or an off-the-shelf tool. And the eval is internal and research-shaped: the target task type, described elsewhere in the same account, is breadth-first, open-ended queries such as identifying every board member of every Information Technology company in the S&P 500 — the kind of problem that decomposes cleanly into independent lookups nobody needs to coordinate in real time.

Anthropic is explicit about where that decomposition stops applying. From the same piece: “most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time.” That sentence is this chapter’s scoping obligation, not a caveat buried in a footnote — it is the authors of the strongest evidence for this pattern telling you, in their own published account, that the domain you are most likely to want to apply it to is the domain they flag as the worst fit.

Most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time.

Anthropic engineering, on the boundary of its own results

The record is not perfectly clean, which is worth saying outright. Six months before that research-system account, Anthropic’s earlier general survey of agent workflows had described the orchestrator-workers pattern in the abstract and listed “coding products that make complex changes to multiple files each time” as one of exactly two example use cases, alongside search. Read alone, that earlier framing suggests coding was always a fit. Read against the later, far more specific engineering account — the one built to interrogate this exact pattern, complete with the failure modes below — the picture narrows: the abstract pattern can describe a coding workflow, but the only large, quantified performance gain Anthropic has published for it belongs to research.

A third, independent voice sharpens the disagreement rather than resolving it. One day before Anthropic published its research-system account, Cognition — the team behind the coding agent Devin — published a piece arguing against parallel subagents for coding specifically, on the grounds that actions carry implicit decisions and “conflicting decisions carry bad results” when subagents cannot see each other’s work; its example is two parallel agents building visually mismatched halves of a simple game because neither could see what the other had already decided. That is close to the failure in this chapter’s opening scene. Treat the coding-task version of orchestrator-worker as contested until someone publishes a coding-specific evaluation with the rigor of the research one.

Why the shape works when it works

The reason the pattern earns its 90.2% on research and struggles on code is the same reason in both directions: it depends on where the coordinating judgment has to live. An orchestrator-worker system puts every piece of cross-cutting judgment — what to investigate, how the pieces relate, what the final answer should say — in one place, the lead agent, and gives each worker a narrow, self-contained slice it can finish without checking in. Breadth-first research is unusually generous about this: the board members of one S&P 500 company genuinely do not depend on the board members of another, so five subagents can work five companies with zero coordination and the lead can merge the results afterward without conflict.

A multi-file refactor is the opposite case. The rename in file A and the call site in file B are coupled by definition — that is what a refactor is — so two subagents editing them in parallel are, structurally, trying to coordinate in real time whether or not the task was framed that way. Chapter 2 of this volume names this gap directly: coding tasks have fewer truly parallelizable parts. This chapter’s job is to show what the pattern looks like when that gap does not apply, so a reader can recognize the shape of a coding task that does — and, more often, the shape of one that does not.

The mechanics: lead, workers, distilled reports

Mechanically, the lead agent does three things a plain single-agent loop does not. It uses extended thinking to plan an approach and estimate how many subagents a given query actually needs. It writes each subagent a task description that specifies an objective, an output format, and guidance on which tools and sources to use — a delegation message, not a forwarded question. And once results come back, it decides whether the picture is complete or another round of subagents is warranted. None of that is automatic scaffolding; it is a job the lead agent has to do well, and the failure modes documented later in this chapter are mostly what happens when it does not.

The worker side of the mechanism is what makes this pattern as much about context management as about parallelism. Anthropic describes subagents as acting like “intelligent filters”: each one iteratively searches, reads, and reasons inside its own context window, then condenses what it found into a short report before handing it back. The lead agent never sees a subagent’s search history, its false starts, or the pages it opened and discarded — it sees the distillation. That is a deliberate context-budget decision, not an accident of the architecture. It is the same debt-avoidance logic behind what Volume I calls Context Debt, applied at the level of a whole subordinate agent instead of a single session: five workers can each carry their own accumulated search noise at no cost to the lead, because none of that noise ever crosses back.

How many subagents

This scaling is not a suggestion so much as an instruction Anthropic gives the lead agent directly, because letting the model guess its own fan-out from the query alone was one of the failure modes that follows.

What broke when they built it

• Over-spawning: the lead agent sometimes decomposed a query that needed one clean answer into as many as fifty parallel subagents, burning tokens and time for no accuracy gain.
• Duplicated work: without clear task boundaries, subagents converged on the same angle instead of dividing the space — in Anthropic’s own example, investigating semiconductor supply chains, one subagent covered the 2021 automotive chip crisis while two others independently re-investigated current 2025 supply chains.
• Search miscalibration: subagents kept issuing overly long, overly specific queries that returned almost nothing, or kept searching after they already had enough to answer.
• Source-quality bias: left to their own judgment, subagents consistently favored SEO-optimized content farms over authoritative but lower-ranked sources such as academic PDFs.
• Tool mismatch: a subagent sent to search the public web for context that only existed in an internal Slack workspace failed by design, not by execution — the task description, not the agent, was the bug.

None of these were hypothetical risks flagged in advance; they are what Anthropic reports actually went wrong while building and running the system in production, and every fix the team describes operates at the level of the delegation message — clearer task boundaries, explicit source guidance, explicit effort calibration — not at the level of adding more orchestration infrastructure. That is a useful diagnostic for anyone building this pattern on their own agents: if subagents are duplicating work or over-searching, the bug is very likely in what the lead agent tells them to do, not in the machinery around them.

The productized version

Claude Code’s subagents are the shrunk, single-session descendant of the same idea. Each one starts with a fresh, isolated context window — it does not see the parent conversation’s history, the files already read, or the skills already invoked — and returns only a summary rather than its full transcript to the main thread. Anthropic’s own guidance names two uses that map directly onto this chapter: isolating high-volume operations, where “the verbose output stays in the subagent’s context while only the relevant summary returns,” and running parallel research, spawning several subagents to investigate independent areas simultaneously before synthesizing. The built-in Explore, Plan, and general-purpose subagents are the productized default instances of exactly this shape.

The productized version also inherits the shape’s ceiling, not just its benefit. The same documentation warns that “running many subagents that each return detailed results can consume significant context” — the intelligent-filter promise only holds if the filtering actually happens, and a lead agent that asks for a full report instead of a distilled one has quietly turned several cheap context windows into one expensive one. Worktree isolation, covered later in this volume, solves an adjacent but different problem — keeping parallel agents from editing each other’s files — and is not a substitute for the context isolation this chapter is about. A session can have either, both, or neither.

If you tried this on a coding task

So what does an honest version of this pattern look like inside a codebase, given everything above? The genuinely research-shaped subset of engineering work — read-only investigation across an unfamiliar monorepo, tracing how five different services each handle a shared auth flow, auditing a dependency for every place it is imported — decomposes the same way board-member lookups do: each subagent investigates one area, nobody needs to see anyone else’s half-finished edit, and a distilled report is exactly what the lead needs to synthesize a real answer. Simultaneous edits to a shared interface are the opposite case, and an independent taxonomy of multi-agent failures, built from more than 1,600 annotated traces across seven agent frameworks, catalogs fourteen recurring failure modes clustered around exactly this: inter-agent misalignment and unverified handoffs, the same shape of failure Anthropic and Cognition each describe from a different angle.

No one has published a coding-specific evaluation with the rigor of Anthropic’s research eval — the 90.2% figure has no coding-task sibling to point to. Until one exists, the responsible reading is Chapter 2’s: default to a single agent for coding work, and reach for orchestrator-worker only for the read-only, genuinely independent slice of the job, never the part where two agents might touch the same file.

What to build Monday

1. Before spawning anything, ask whether the subtasks are truly independent — could two of them touch the same file, the same interface, the same shared state? If yes, this is not an orchestrator-worker job yet.
2. Give every subagent a delegation message, not a forwarded question: an explicit objective, an output format, and which tools or sources it should use — Anthropic’s failure list is mostly what happens when this step is skipped.
3. Size the fan-out to the task using Anthropic’s own bands as a starting point: one agent for a single fact, two to four for a direct comparison, ten or more only for genuinely open-ended research with clearly divided responsibilities.
4. Treat “returns a distilled report, not a raw transcript” as the test for whether a worker is actually filtering. If the lead agent’s context keeps filling up with subagent detail, the compression step is not happening.
5. Reserve the pattern for research-shaped slices of engineering work — investigation, auditing, cross-cutting search — and keep simultaneous file edits on a single agent until coding-specific evidence catches up.