When to Fan Out Subagents: Orchestration Patterns That Work

What Is the Orchestrator/Worker Pattern?

One agent holds the overall goal and decomposes it into independent pieces. Separate worker agents each get one piece, their own context window, and a narrow job. The orchestrator collects results and decides what happens next.

The pattern has one agent playing 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 its own fresh context. Each worker explores, calls tools, and returns a result, usually a short summary rather than its full working trace. The orchestrator reads the results, checks whether the goal is met, and either finishes or dispatches the next round of work.

The value of the pattern is separation. A worker's dead ends, false starts, and irrelevant tool output never enter the orchestrator's context. The orchestrator's window grows by one clean answer per worker, not by everything it took to produce that answer. That is the same shape of saving we cover in our report on token efficiency: 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 subtasks are genuinely independent, when the information needed exceeds one context window, and when the task is valuable enough to justify a multi-agent system's real token cost. Sequential, tightly coupled work does not qualify.

Not every task benefits. Most coding work, for instance, involves fewer truly 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 earns its keep 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.

That 15x figure is the honest cost of the pattern, straight from Anthropic's own writeup of the multi-agent system behind Claude's Research feature. It is not a reason to avoid fan-out. It is the number you weigh against the value of the task before you reach for it. 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 buy enough tokens spent on the problem to actually solve it, not because more agents are inherently smarter.

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

Cheap refers to the orchestrator's context budget, not the total bill. 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.

This distinction gets lost constantly, so it is worth stating plainly: subagent context is cheap for the thread that matters, not free for the system as a whole. 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, the wrong turns, the tool calls that came back empty, the reasoning about which direction to try next, lived and died in a window that never has to be carried forward. That is what makes an agent still tractable after ten rounds of delegation: its own context stayed small the whole time, even though the total work done across all its subagents was large.

How Do You Fan Verification Back In?

Never let the agent that did the work also grade the work. A separate checker, with its own context and its own incentive to find problems, reviews what came back before anything gets marked done.

Fanning out creates a second problem symmetric to the first: if delegation scatters the work, something has to gather it back up and confirm it is actually correct, not just returned. Self-grading fails here for the same reason it fails everywhere else. 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 flatter it, worst on subjective calls like design quality. The fix is structural, not a better prompt: separate the worker from the checker, 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.

That 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. We cover the definition-of-done side of this in full in our report on AI agent evaluation: the checker has to run the thing, not just 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 multiple agents each declare victory, and unbounded fan-out where nobody enforces one task per worker at a time.

The first failure is collision. Two workers touching overlapping files or state without coordination will silently clobber each other's changes, and neither agent has any way to know it happened. The fix is scoping subtasks so they genuinely do not overlap, and giving each worker an explicit, narrow surface it is allowed to touch.

The second is a missing done-gate. If there is no single, externally checked definition of "finished," workers and the orchestrator can each independently decide a task is complete based on their own read of it, and those reads disagree. Our report on harness engineering covers the fix directly: done means the output of a passing, executable command, not any agent's impression, worker or orchestrator.

The third is scope creep at the worker level, the same overreach that shows up in single-agent work, multiplied. Give a worker a broad, vague piece of a task and it will start touching things adjacent to its actual job, which erodes the isolation that made fan-out worth the token cost in the first place. Enforce one task in flight per worker at a time, verified before the next one starts, the same WIP-limit discipline that applies to a single agent.

What Does This Look Like in Our Own Production Practice?

We delegate research and review to subagents by default, keep one task per worker, and route the checker to a different model than the one that did the work whenever the stakes justify it, exactly as we did in our own recent field test.

In our own build practice, research and open-ended exploration go to subagents as a default, not an exception, precisely because the main thread staying lean is worth more than the extra tokens most of the time. We enforce one active task per worker and require a passing, executable check before anything gets marked done, never a worker's own say-so. And when the stakes are high enough, we deliberately route the checker to a different model provider than the one that built the thing, for the same reason a second pair of eyes matters more than a mirror. That is exactly the setup behind our own field report on running a GPT-5.6-based reviewer against a Claude-built harness: fan-out and verification, not a benchmark, applied to our own system. It is the same orchestrator-worker discipline we build into every custom AI agent system we deliver to clients.