Parallel Fan-Out / Gather
also known as Fan-Out Fan-In, Parallel + Aggregator
Multiple independent agents execute in parallel on a partitioned task; a dedicated aggregator agent reconciles their results into a single output.
This pattern helps complete certain larger patterns —
- specialisesParallelization★★— Run independent LLM calls concurrently and combine results.
- specialisesHeterogeneous-Model Council with Synthesis Judge★— Three or more role-specialized personas run on different model architectures in parallel; a synthesis judge — given only their structured JSON, not the original input — produces the final verdict.
Context
A team uses parallelization for throughput. The post-parallel reconciliation step is implicit — either the orchestrator does ad-hoc merging or downstream code assembles the parts. The aggregator role is unnamed.
Problem
Without a named aggregator, reconciliation logic accretes in the orchestrator or in downstream consumers. Conflicts between parallel results (disagreement, overlap, missing pieces) have no designated handler. Distinct from generic parallelization by naming the aggregator role.
Forces
- Parallel results often disagree — reconciliation policy must be explicit.
- Adding an aggregator means another agent (or step) in the path.
- Aggregator design is hard for unstructured outputs.
Example
A research agent fans out 5 sub-agents on 5 sub-questions. Each emits a structured finding {claim, citation, confidence}. The aggregator takes all 5, deduplicates citations, resolves contradictions (preferring higher-confidence or majority), and emits one consolidated report. Without the named aggregator role, downstream code would have had to merge ad-hoc.
Diagram
Solution
Therefore:
Partition the task into N sub-tasks. Spawn N workers in parallel; each emits a structured result. The aggregator (a dedicated agent or a deterministic merger) takes the N results and produces one output. Conflict resolution policy is part of the aggregator's design. Distinct from existing parallelization by mandating the named aggregator role. Pair with parallelization, scatter-gather-saga, heterogeneous-model-council-with-judge.
What this pattern forbids. Reconciliation may not be performed by the orchestrator or downstream code; only the designated aggregator may merge worker outputs.
The smaller patterns that complete this one —
- generalisesHeterogeneous-Model Council with Synthesis Judge★— Three or more role-specialized personas run on different model architectures in parallel; a synthesis judge — given only their structured JSON, not the original input — produces the final verdict.
And the patterns that stand alongside it, or against it —
- complementsScatter-Gather Plus Saga★— Distribute tasks across worker agents and aggregate results while maintaining distributed-transaction semantics via compensating actions on partial failure.
- alternative-toMapReduce for Agents★— Split an oversize task into independent chunks, process each in parallel, then aggregate.
- alternative-toVoting-Based Cooperation★— Finalise a decision across multiple agents by collecting and tallying their votes on candidate options, so the joint output reflects collective rather than single-agent judgement.
- complementsContract Net Protocol★★— Classical bid-based multi-agent task allocation: a manager broadcasts a task announcement, contractors submit bids, and the manager awards the contract to the best bid.
Neighbourhood
Click any neighbour to follow the language. Scroll to zoom, drag to pan.