Pattern Matrix/White Paper/C2

C2 · Fan-out / Gather

What problem it solves

Some tasks are simply too slow when one agent does them sequentially. A single agent reading a hundred thousand pages of financial documents takes 35 hours, but the legal team has only a 24-hour window before quarterly disclosure.

Fan-out / gather splits a large task into multiple independently executable subtasks, distributes them in parallel to N sub-agents, and aggregates the results at the end. Its benefit is not saving tokens—token cost doubles linearly—but compressing wall-clock time: as the number of workers grows, total duration drops almost linearly. It has one frequently underestimated difficulty: dispatching the tasks costs almost no engineering effort, while merging the results back is where the real engineering lies. When multiple workers see the same material, their outputs overlap, and the aggregation stage must perform deduplication and conflict resolution.

Why the coordinate is "Collaboration × Parallel"

• Vertical axis · Collaboration: This splits one task across multiple sub-agents that work in parallel and then summarize. The entities being distributed are different subtasks, which makes it a multi-agent collaboration topology. This differs from parallel exploration in the reasoning module—the latter parallelizes multiple solution paths for the same problem (a reasoning strategy), while the former parallelizes different subtasks split across different agents (a collaboration topology).
• Horizontal axis · Parallel: N sub-agents run simultaneously, unaware of one another, and are gathered together at the end. This is the classic map-reduce parallel structure. It is neither sequential chaining nor loop iteration.

Core mechanism

A single fan-out / gather consists of three stages:

1. Split and fan out: The large task is split into N parts by "semantic independence" and distributed in parallel. The splitting criterion is not equal division by document count, but making the subtasks independent of one another—worker B must not depend on worker A's output, otherwise a handoff chain rather than fan-out is called for.
2. Isolated execution: Each sub-agent runs in an independent context and completes its own subtask without communicating with the others. The strength of isolation is proportional to the likelihood of output conflicts—research tasks that each query different corpora need only soft isolation, while code-writing tasks where multiple agents modify overlapping files require physical isolation (separate Git worktrees or separate containers).
3. Gather and collect: An aggregation strategy merges the N sets of results. If aggregation is done wrong, the entire pipeline falls apart.

Aggregation is not simple concatenation; it must do at least five things:

Suitable production scenarios

• Batch tasks under wall-clock time pressure: Quarterly compliance scans, large-scale document review, batch bid evaluation—cases where total duration is the hard bottleneck and the subtasks are independent of one another.
• Research tasks that split cleanly by semantic independence: Parallel verification across multiple corpus sources, where each sub-agent queries a different category of content and the outputs barely conflict.
• Multi-agent parallel code writing: One agent each for UI, API, database, and tests, combined with physically isolated worktrees to compress 8 hours down to 2.

Three conditions must hold simultaneously: the task can be split into independent parallel parts, total duration is the bottleneck, and the budget can absorb N times the tokens. If any one fails, fan-out merely moves the bottleneck from duration to quality.

Where it tends to go wrong

• Forcing a split when subtasks have strong dependencies: For tasks where workers need to exchange intermediate state, or must be read in sequence to recognize an evolution trajectory, fan-out flattens sequential dependencies into parallelism, and the gather stage then spends a great deal of effort rebuilding those dependencies. Such scenarios call for a handoff chain.
• Aggregation costs more than execution: When too little is invested in aggregation, fan-out merely moves the bottleneck from duration to quality. If the business has no engineering capacity for deduplication, conflict resolution, and cross-slice integration, fan-out should not be turned on.
• Aggregation bottleneck: As the number of workers N grows, the aggregator must read every worker's output, blowing out its context and causing quality to drop sharply. When N is large, the aggregator should work in layers (first group-level sub-aggregation, then final synthesis) to reduce the context pressure to logarithmic scale.
• Slicing by function rather than by conflict: Slicing for "most complete function coverage" (one group each for frontend, backend, algorithms, and testing) leads to daily conflict resolution at the integration stage; slicing to "minimize output conflicts" is the right approach. The fan-out topology should mirror the actual collaboration topology of the business team.
• Implicit batching cuts concurrency: You think you have launched 50 concurrent calls, but the LLM provider is doing implicit queuing plus batch scheduling, quietly cutting real concurrency down to 10. The fan-out implementation must align with the provider's batching behavior.

Key metrics

• Success rate (healthy range ≥ 95%): The proportion of workers that return valid results. In compliance review scenarios this is a hard floor—missing a few items will be flagged at the audit stage.
• Duplication rate (healthy range < 30%): The proportion of similar entries after aggregation. Exceeding this means deduplication was not done well, and the report will bloat to the point that "readers cannot get through it."
• Speedup ratio (healthy range close to N): The actual duration-compression factor delivered by N workers. Significantly below N means concurrency was cut by rate limiting, or the task actually has dependencies.
• Aggregation cost share (healthy range < 15%): The proportion of total cost consumed by the aggregation step. Too high, and you should switch to a lighter aggregation strategy or use layered aggregation.

Minimal implementation skeleton

FanoutGather.execute(goal, perspectives, strategy):
                workers = decompose(goal, perspectives)    # split into N parts by semantic independence
                results = parallel gather(                  # semaphore for concurrency + retry + backoff
                    execute_worker(w) for w in workers      # independent context each, failures don't block others
                )
                return aggregate(goal, results, strategy)   # the soul is in this step

            aggregate(results, strategy):
                concatenate → simple concatenation (only when no overlap)
                vote        → majority vote
                synthesize  → strong model synthesis, explicit contradiction resolution + dedup
                structured  → schema-based structured merge
            

Four engineering points: use a cheap model for the workers, but the aggregator model must be strong (synthesis is the quality bottleneck); set the initial concurrency to match the provider's RPM tier, starting at 5–10 and raising it gradually with monitoring; failed workers must not block others, and set a partial-failure threshold; retain a complete trace of each path for audit.

Enterprise implementation example

A listed company's quarterly compliance-scanning agent: the first version, a single agent reading a hundred thousand pages of financial documents sequentially, took 35 hours, well past the legal team's 24-hour pre-disclosure window. The second version switched to 12 workers, each responsible for one document category (4 for financial reports, 4 for emails, 4 for contracts), scanning in parallel and compressing total duration to 4 hours. But once live, it immediately hit the aggregation problem: the 12 workers each flagged more than 200 risk points, the same contract change was flagged by three workers in three different phrasings ("VAM clause added," "earnout clause expansion," "new VAM term may trigger buyback"), and the gather stage tallied 600 risks, at least sixty percent of them duplicates. The legal director put it plainly: "the agent runs fast, but I can't get through the report." The third version added three things to gather: embedding-based semantic deduplication, concept normalization (canonicalizing the three phrasings into one entry), and confidence weighting (a single-worker flag weighted 0.6, an item flagged by multiple workers weighted 1.0). The final risk report was compressed from over 600 items to 80 high-confidence plus 120 needs-review. In a large government or state-owned-enterprise bid-evaluation scenario, additional compliance constraints would stack on top: strict isolation between workers to satisfy evaluator-independence requirements, full trace retention for 7 years, and a partial-failure threshold no lower than 95% (missing one submission will be flagged at the audit stage).

Relationship to other patterns

• Parallel exploration (reasoning module R3): Same structure, shared aggregation mechanism, differing in what is parallelized. Fan-out / gather assigns different subtasks to different agents (a collaboration topology); parallel exploration runs multiple solution paths for the same problem (a reasoning strategy). Both follow "N times the tokens for 1/N of the duration," but the objects being distributed differ.
• Hierarchical delegation (C1): Both are one-to-many, but fan-out is one-to-many by quantity (multiple workers simultaneously handling different parts of the same kind of work) with shallow collaboration (fire-and-collect), while hierarchical delegation is one-to-many by specialty with deep collaboration (the supervisor continuously monitors). Anthropic's multi-agent research is both hierarchical (the lead supervises) and fan-out (the subagents run in parallel).
• Adversarial review (C3): The N workers in fan-out are complementary (each looks at one facet to assemble the full picture), while the reviewers in adversarial review are adversarial (independently scrutinizing the robustness of a decision).
• Sub-agent isolation (C5): Each parallel branch in fan-out depends on the inner discipline of isolation—an independent context, with the gather stage seeing only the reduced result.

What this pattern teaches

Fan-out / gather looks like saving wall-clock time, but in engineering practice it is investing in aggregation complexity and replicating your team's real collaboration topology—the premise for N times the workers turning duration into 1/N is that you also invest N times the engineering effort into aggregation.

This page is part of the ADPS pattern white papers. Back to the pattern matrix, or see the runnable code catalog.