When to Fan Out Subagents: Orchestration Patterns That Work

What Is the Orchestrator/Worker Pattern?

In the orchestrator/worker pattern, one agent holds the overall goal and splits it into independent pieces, and separate worker agents each take one piece with their own context window and a narrow job. The orchestrator collects the results and either finishes or dispatches another round of work.

One agent acts as the lead. It holds the task, breaks it into pieces that do not depend on each other, and hands each piece to a worker agent with a fresh context of its own. A worker explores and calls tools until it can return a result, usually a short summary rather than its full working trace. The orchestrator reads those results to check whether the goal is met, then either finishes or sends out the next round of work.

The pattern is useful because it keeps the work separated. A worker's dead ends, false starts and irrelevant tool output never enter the orchestrator's context, so the orchestrator's window grows by one clean answer per worker instead of by everything it took to produce that answer. Our report on token efficiency covers the same kind of saving: delegation keeps the thread that matters small, even when the system as a whole spends more.

When Should You Fan Out Instead of Running One Long Agent?

Fan out when the subtasks are independent, when the information needed exceeds one context window, and when the task is valuable enough to justify the real token cost of a multi-agent system. Sequential, tightly coupled work does not qualify, and most coding work parallelizes less than open research does.

Not every task benefits from fanning out. Most coding work, for instance, has fewer parallelizable subtasks than open research does, and today's agents are not yet great at coordinating with each other in real time when steps depend on one another. Fan-out pays for itself on tasks like research across many independent sources, parallel audits of separate modules, or adversarial review where you specifically want a second, independent pass rather than a continuation of the first agent's reasoning.

The 15x figure, from Anthropic's writeup of the multi-agent system behind Claude's Research feature, is the real cost of the pattern. It is a number to weigh against the value of the task before you reach for fan-out, and on its own it does not argue against using the pattern. The same report notes that in their internal evaluation of a hard browsing task, three factors explained 95 percent of the performance variance, and token usage by itself was the largest of the three. Multi-agent systems mostly work because they spend enough tokens on the problem to solve it, not because more agents are inherently smarter.

Why Is Subagent Context Cheap, Even Though the System Spends More Tokens?

Subagent context is cheap for the orchestrator's context budget, even while the total bill goes up, because a worker's exploration is disposable. It gets thrown away once the task ends, so the parent thread never pays to hold search history it doesn't need and grows by one clean result instead.

The distinction that often gets lost is that subagent context is cheap for the thread that matters while the system as a whole still pays for it. When we delegate a research task, a codebase exploration, or an adversarial review to a subagent, the parent agent's context grows by one result. Everything that produced that result, including the wrong turns, the tool calls that came back empty and the reasoning about which direction to try next, stayed in a window that never has to be carried forward. That is why an agent is still tractable after ten rounds of delegation: its own context stayed small the whole time, even though the total work done across its subagents was large.

How Do You Fan Verification Back In?

You fan verification back in with a separate checker, never the agent that did the work. The checker, with its own context and incentive to find problems, reviews the results before anything is marked done. A better prompt does not substitute for this structure.

Fanning out creates a second problem that mirrors the first: if delegation scatters the work, something has to gather it back up and confirm that what came back is correct. Self-grading fails here for the same reason it fails elsewhere. Guo et al.'s well-known finding that modern neural networks are systematically overconfident applies to agents evaluating their own output. The same model that generated the work tends to rate it too highly, most of all on subjective calls like design quality. A better prompt does not fix that, so the worker and the checker should be separate every time.

Anthropic's own experiment on this is a useful data point. Building the same application with the same underlying model, a bare single agent finished in 20 minutes for about $9, but core features did not work. A three-agent harness, adding a planner and a dedicated evaluator that clicked through the actual interface rather than trusting its own report, took 6 hours and cost about $200, over 20 times more, and delivered a fully working result.

The 20x cost gap is the price of a real verification fan-in, and it bought a working product instead of one that only looked finished. Our report on AI agent evaluation covers the definition-of-done side of this in full. The checker has to run the thing it is checking as well as read the code.

What Failure Modes Show Up in Multi-Agent Systems?

Three failures dominate in practice: workers overwriting each other's changes, no shared done-gate (so several agents each decide they are finished), and unbounded fan-out where nobody enforces one task per worker at a time. Each has a structural fix: scope, gate or limit the work.

The first failure is collision. Two workers that touch overlapping files or state without coordination will silently overwrite each other's changes, and neither agent has a way to know it happened. To prevent it, scope subtasks so they do not overlap, and give each worker an explicit, narrow surface it is allowed to touch.

The second is a missing done-gate. Without a single, externally checked definition of "finished," the workers and the orchestrator can each decide a task is complete based on their own read of it, and those reads disagree. Our report on harness engineering covers the remedy: done is defined by a passing, executable command, and no agent's impression counts, whether it comes from a worker or the orchestrator.

The third is scope creep at the worker level, the same overreach that shows up in single-agent work, repeated across every worker. A worker given a broad, vague piece of a task will start touching things next to its actual job, which erodes the isolation that made fan-out worth the token cost. The remedy is the WIP limit that applies to a single agent: one task in flight per worker at a time, verified before the next one starts.

What Does This Look Like in Our Own Production Practice?

In our own practice we delegate research and review to subagents by default, keep one task per worker, and route the checker to a different model from the one that did the work whenever the stakes justify it, which is how we ran our own recent field test.

In our builds, research and open-ended exploration go to subagents by default, because most of the time a lean main thread is worth more than the extra tokens. We enforce one active task per worker and require a passing, executable check before anything is marked done; a worker's own say-so does not count. When the stakes are high enough, we route the checker to a different model provider from the one that built the thing, so the work gets a second pair of eyes instead of the builder reviewing itself. Our field report on running a GPT-5.6-based reviewer against a Claude-built harness used exactly this setup, applying fan-out and verification to our own system instead of to a benchmark. We build the same orchestrator-worker structure into every custom AI agent system we deliver to clients.