Key Takeaway
Fan-out and pipeline are two ways to orchestrate multiple AI agents. Fan-out runs several agents in parallel on independent subtasks and merges their results, trading tokens for speed and breadth. A pipeline chains agents in sequence, each building on the last, trading latency for control and coherence. The task's structure decides which fits.
Once you move past a single agent, you have to decide how several of them work together. Two orchestration patterns cover most cases: fan-out, where a coordinator splits work across parallel agents, and pipeline, where agents run one after another in a chain. They are built for different shapes of problem, and picking the wrong one shows up as either wasted tokens or needless waiting.
Neither is a default. Fan-out suits work that divides cleanly into independent pieces, while a pipeline suits work where each step depends on the output of the one before. This comparison walks through how each behaves on latency, cost, and failure, then gives a way to decide and to combine them.
| Dimension | Fan-Out (Parallel) | Pipeline (Sequential) |
|---|---|---|
| Topology | One coordinator, many parallel workers | A chain where each agent feeds the next |
| Latency | Low, work happens at the same time | Higher, steps wait on each other |
| Token cost | Higher, workers re-read shared context | Lower per run, but errors compound |
| Task dependencies | Subtasks are independent of each other | Each step depends on the previous output |
| Best for | Breadth-first search and gathering | Staged transforms and refinement |
Fan-out: parallel breadth
In a fan-out pattern, a lead agent decomposes a goal into independent subtasks and dispatches them to worker agents that run at the same time, each in its own context. When the workers finish, the coordinator gathers and synthesizes their results. The payoff is wall-clock speed and coverage: several agents exploring several angles finish in roughly the time one would take for a single angle.
Anthropic reported that this orchestrator-worker shape drove most of the gains in their multi-agent research system, at the cost of using many more tokens than a single agent. That trade defines the pattern:
- It excels when a problem splits into pieces that do not need to talk to each other while running.
- It spends tokens generously, because each worker re-reads the context it needs to operate independently.
- It shifts difficulty to the merge step, where the coordinator must reconcile results that may overlap or conflict.
Pipeline: sequential depth
A pipeline arranges agents in a line, where each stage consumes the previous stage's output and produces input for the next. A common example is a writer stage followed by a reviewer stage followed by a fixer stage. Because the steps are ordered, the pattern keeps tight control over how work evolves and makes each stage's contribution legible.
The cost is latency, since stages cannot start until their predecessor finishes, and fragility, because an error early in the chain propagates downstream and can compound. Pipelines reward problems that are genuinely sequential, where skipping the order would produce nonsense.
Ask one question before choosing: do the subtasks depend on each other. If they are independent, fan out and pay in tokens for speed. If each step needs the last one's result, build a pipeline and pay in latency for coherence. Forcing the wrong shape wastes the resource you can least spare.
Where each pattern fits
The structure of the work, not a preference, should pick the pattern:
- Use fan-out for parallel research, gathering evidence from many sources, or applying the same scoped change across many files.
- Use a pipeline for staged refinement, such as draft then review then revise, where order carries meaning.
- Watch the failure mode: fan-out risks a messy merge, while a pipeline risks an early error cascading through every later stage.
Fan-out is not free speed. Running many agents in parallel can multiply token usage several times over compared with a single agent, so reserve it for work that genuinely benefits from breadth. Spawning parallel workers for a task a single agent could handle mostly buys a larger bill.
Combining the two
Real systems rarely pick just one. A common hybrid fans out to gather in parallel, then pipes the merged result through a sequence of refinement stages. The orchestrator decides which shape each phase of the work needs, rather than committing the whole job to one topology.
Thinking in phases is the unlock. A research phase wants breadth and parallelism; a synthesis and review phase wants order and control. Composing a fan-out front end with a pipeline back end often beats either pattern used alone, because it matches the topology to each stage's actual dependency structure.
Fan-out and pipeline answer one question: do your subtasks depend on each other. Independent work fans out for speed and breadth; dependent work pipelines for order and control. Read the dependency structure of the task, combine the two in phases when it helps, and let the work's shape drive the orchestration.