AI
Fan-Out vs Pipeline: AI Agent Patterns
August 20269 min read
Fan-out is an orchestration pattern where a coordinator agent splits a goal into independent subtasks and dispatches them to worker agents that run in parallel, each in its own context, then synthesizes their results. It trades higher token usage for wall-clock speed and breadth, making it ideal for work that divides cleanly into pieces that do not depend on each other.
A pipeline chains agents in sequence, where each stage consumes the previous stage's output, such as a writer stage followed by a reviewer and then a fixer. It trades latency for tight control and coherence and suits genuinely sequential work. Its main weakness is that an error early in the chain can propagate and compound downstream.
Ask whether the subtasks depend on each other. If they are independent, fan out to gain speed and breadth at the cost of more tokens. If each step needs the previous step's result, build a pipeline to gain order and control at the cost of latency. The task's dependency structure, not preference, should decide.
Usually yes. Fan-out can multiply token usage several times over compared with a single agent, because each worker re-reads the context it needs to operate independently. That is why parallelism should be reserved for work that genuinely benefits from breadth rather than used as a default for tasks a single agent could handle.
Yes, and real systems often do. A common hybrid fans out to gather information in parallel, then pipes the merged result through a sequence of refinement stages. Thinking in phases lets a research phase use breadth and parallelism while a synthesis and review phase uses order and control, matching topology to each stage's dependency structure.
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 |
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:
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.
The structure of the work, not a preference, should pick the pattern:
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.
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.