Pattern Matrix/White Paper/C2

ADPS Agent Design Pattern White Paper

C2 · Fan-out / Gather

The orchestrator distributes independently executable subtasks to parallel sub-agents, then an aggregator deduplicates, resolves conflicts, and merges their results.

Coordinate Collaboration × Parallel (fan-out)
Cost High (parallel worker calls plus aggregation)
Pattern group Collaboration patterns
Pattern summary The orchestrator distributes independently executable subtasks to parallel sub-agents, then an aggregator deduplicates, resolves conflicts, and merges their results.

Problem

Some tasks cannot meet a business window when one agent processes every item sequentially. A quarterly disclosure review, for example, may contain more documents than one run can inspect before the legal deadline.

Fan-out / gather splits a large task into independently executable subtasks, distributes them to parallel sub-agents, and aggregates the results at the end. It usually spends more total compute to reduce wall-clock time, although provider limits and the gather stage prevent ideal linear speedup. Dispatch is the easy part; merging the results is where most of the engineering lies. When workers see overlapping material, the aggregation stage must deduplicate and resolve conflicts.

Classification: 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.

Solution and mechanics

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:

Aggregation step Function
Dedup Merge the same fact when multiple workers capture it, using semantic similarity to find duplicates
Conflict resolution Decide how to adjudicate when worker A says buy and worker B says sell
Integration Catch problems that surface only at the boundaries between worker slices
Ranking Multi-dimensional combined ranking
Attribution Anchor each conclusion to its original source

Applicability

  • 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: Assign independent agents to separable work packages and use worktrees or containers to isolate files and commits. Measure whether integration effort cancels the time saved.

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.

Known failure modes

  • 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: The application may launch many calls while the model provider queues or batches them, so observed concurrency is much lower. The implementation must measure and align with provider limits.

Verification and metrics

  • Worker completion rate: The proportion of partitions that return a valid artifact. Compliance reports must list incomplete partitions instead of hiding them behind the completed set.
  • Duplication rate: The proportion of semantically repeated entries after aggregation. A sustained rise points to weak partition boundaries, normalization, or deduplication.
  • Speedup ratio: Compare observed wall-clock time with the sequential baseline. Investigate provider throttling, shared dependencies, and gather bottlenecks when the gain is small.
  • Aggregation cost share: Track the compute, model spend, and latency consumed by gather. Stricter artifacts, layered aggregation, or deterministic deduplication may reduce it.

Reference implementation

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: choose worker and aggregator models from local quality and cost measurements; align concurrency with provider limits and raise it only after observation; failed workers must not block unrelated branches, and the final artifact must disclose partial failure; retain a complete trace of each path for audit.

Illustrative scenario

Consider a quarterly compliance-scanning agent. Sequential review cannot meet the disclosure window, while parallel workers introduce duplicate findings, inconsistent terminology, and incomparable confidence labels. The gather stage therefore performs semantic deduplication, concept normalization, evidence merging, and needs_review classification. Government or regulated bid-evaluation workflows may also require worker independence and policy-defined trace retention. Every partial failure remains visible in the final report. Throughput and coverage claims require results from an authorized document set.

Related 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).
  • 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.

Design conclusion

Fan-out / gather exchanges additional execution and aggregation work for shorter wall-clock time. It works when partitions are independent, outputs are contract-shaped, and the gather stage can reconstruct one auditable result.

Suggested citation: ADPS, C2 Fan-Out/Gather, Agent Design Pattern White Paper v0.3, 2026-07-13. Catalog · runnable code catalog · CC BY 4.0

Document status: This is a public review draft. Illustrative scenarios explain the mechanism and are not presented as verified enterprise cases. See the case library for attributed practice. ADPS welcomes case contributions with sources, measurement methods, and publication approval.