Agent Orchestration Patterns: Sequential, Parallel, and Hierarchical
RedHub AI Editorialupdated October 4, 20267 min read
Jump to a section8
Most agent orchestration patterns, from supervisor to router to map-reduce, are built from three shapes. Sequential is a pipeline where each agent's output feeds the next. Parallel fans work out to several workers at once and merges what comes back. Hierarchical puts an orchestrator agent in charge of planning and delegating to specialist workers. Learn the three shapes, what each is good at and where each one breaks, and you can reason about a design you have never seen before instead of memorizing a catalog.
TL;DR: Sequential is simple, but errors compound down the chain. Parallel is fast, but the merge step decides quality. Hierarchical handles open-ended tasks, but it can loop or spawn runaway workers without a hard budget. Pick the simplest shape the task allows, put a deterministic gate at every hand-off, and measure each pattern's cost and failure mode before you trust it.
Where the named patterns come from
Anthropic's December 2024 engineering post, Building effective agents (opens in a new tab), names five workflows: prompt chaining, routing, parallelization, orchestrator-workers and evaluator-optimizer. Four of them map straight onto the three shapes. Prompt chaining is sequential. Routing is a sequential step with a branch: classify first, then hand the input to the specialist for that category. Parallelization is the fan-out. Orchestrator-workers is the hierarchy. The fifth one does not fit as neatly, and we'll come back to it.
Other names in circulation, such as supervisor, manager or map-reduce, describe the same shapes with different labels. The label matters less than the answer to two questions. Who decides the next step, your code or a model? And what gets checked at each hand-off?
Sequential: the pipeline
In a sequential pattern, agents run one after another and each output becomes the next input: extract, then validate, then format. Or research, then draft, then fact-check. It's the easiest shape to build and the easiest to debug, because at every stage you can inspect exactly what went in and what came out.
Its weakness is that errors compound. If the extract step drops a field, every step after it works on incomplete data and produces a confident wrong answer. The defense is a schema check between stages. Anthropic's post describes the same idea for prompt chaining: programmatic checks, which it calls a "gate," on any intermediate step. When a stage's output fails the check, you retry or escalate right there, before the bad data flows downstream.
Parallel: fan-out and merge
When sub-tasks are independent, run them at the same time. A parallel pattern splits one input across N workers (ten document lookups, five source summaries, a batch of classifications) and a merge step combines the results. Anthropic's post splits parallelization into two variations. Sectioning breaks a task into independent subtasks. Voting runs the same task several times to get diverse outputs. The payoff is wall-clock time, or extra confidence when several attempts agree.
The trap is the merge. Workers don't see each other, so they can duplicate findings, contradict one another, or hedge on the same uncertainty. A weak merge concatenates and hopes. A strong one de-duplicates, reconciles conflicts and flags where workers disagreed. Most of the engineering effort in a parallel pattern belongs in the merge, not the fan-out.
Fan-out also multiplies cost. Ten workers that each re-read the same instructions and context spend roughly ten times the tokens of one. That's worth it when parallelism buys real speed or coverage, and waste when a single agent could have handled the task in one pass.
Hierarchical: orchestrator and workers
Sometimes you don't know the sub-tasks until the work begins. A research request might need three lookups or thirty. A coding task might touch one file or a dozen. The hierarchical pattern handles this with an orchestrator agent that plans the work, delegates pieces to specialist workers, reads their results and decides what to do next, which may mean delegating more. Anthropic draws the line against parallelization this way: the subtasks "aren't pre-defined, but determined by the orchestrator based on the specific input."
That flexibility is what makes it the riskiest shape. Because the orchestrator decides as it goes, it can loop on a failing task, spawn far more workers than the job needs, or run up cost. It needs hard limits the orchestrator cannot override: a maximum number of delegation rounds, a total worker budget, and a token or time ceiling that ends the run and returns what it has so far, flagged as incomplete. The orchestrator-worker guide covers this pattern and its guardrails in full.
max_iterations setting stops a runaway, but when it trips it often truncates the work with no signal that anything is missing. Pair the cap with a partial-result path that says the answer is incomplete.The pattern that doesn't fit the three shapes
The fifth workflow, evaluator-optimizer, is where the three-shape model strains. One call generates a response, another evaluates it and sends feedback, and the pair repeats. Drawn on a whiteboard it looks sequential: generate, then evaluate. In production it behaves more like a hierarchy, because a model decides when the loop ends, so it can loop just like an orchestrator can. Anthropic's post says it fits best when there are clear evaluation criteria and refinement gives measurable value.
We don't have a clean fourth shape to offer for it. The practical answer is to treat any loop a model controls with hierarchical-grade limits, even when the diagram looks simple: a round cap, a cost ceiling, and a test showing the second pass beats the first on your own cases. If it doesn't, the loop is paying for nothing.
How the shapes compose
Real systems mix them. A support flow might be sequential overall (classify, handle, check), with a parallel research fan-out inside the handling stage and a small hierarchical planner reserved for the messiest tickets. Choose the simplest shape each part of the task allows, and be deliberate about the gate at every seam.
| Pattern | Reach for it when | Watch out for |
|---|---|---|
| Sequential | Steps genuinely depend on each other | Compounding errors; validate every hand-off |
| Parallel | Sub-tasks are independent and speed or coverage matters | A weak merge; cost that scales with the number of workers |
| Hierarchical | Sub-tasks aren't known until runtime | Loops and runaway workers; enforce hard budgets |
| Model-controlled loop | Clear evaluation criteria and refinement that measurably helps | Loops that cost more than they improve; cap the rounds |
Whether a pattern suits your workload depends on your model, prompts and data, so measure it on your own cases. For the bigger decision of whether to split work across agents at all, start with single agent vs multi agent.
Get five patterns as working code
The Agent Orchestration Cookbook holds five patterns as working code in four paths: the Claude Agent SDK and LangGraph, each in Python and TypeScript. They are orchestrator-worker, routing, retry-with-reflection, a code review agent and a hierarchical supervisor. It does not include a sequential pipeline. Each pattern carries a control-flow eval that runs offline against a mock model.
Get the Agent Orchestration Cookbook — $79Pairs well with
The Agent Action Admissibility Engine ($99) checks the actions an agent proposes against your own domain rules before any of them run, and returns ADMISSIBLE, REVIEW or INADMISSIBLE per action. The Agent Reliability Harness ($149) evaluates agent runs at the trajectory level and returns a SHIP, HOLD or FIX verdict you can gate CI on. The Prompt Evaluation & Versioning System ($49) runs regression tests on the prompts each stage depends on and versions them like code.
More in this guide
What are the main agent orchestration patterns?
Three building blocks: sequential (a pipeline where each agent feeds the next), parallel (fan out to workers, then merge) and hierarchical (an orchestrator that plans and delegates to workers). Supervisor, router and map-reduce patterns are built from these.
Which pattern should I start with?
The simplest one the task allows, usually sequential. It's the easiest to build and debug because every stage's input and output can be inspected. Move to parallel when sub-tasks are independent and speed matters, and to hierarchical only when the sub-tasks aren't known until runtime.
Why is the merge step so important in a parallel pattern?
Parallel workers can't see each other, so they duplicate findings, contradict each other or hedge on the same uncertainty. A weak merge just concatenates. A strong merge de-duplicates, reconciles conflicts and flags disagreement.
What's the biggest risk with hierarchical orchestration?
Runaway behavior. The orchestrator delegates as it goes, so it can loop on a failing sub-task or spawn far more workers than needed. Enforce limits it can't override: a cap on delegation rounds, a worker budget, and a token or time ceiling with a flagged partial result.
Where does an evaluator-optimizer loop fit?
It looks sequential, but a model decides when the loop ends, so it can loop like an orchestrator. Give it a round cap and a cost ceiling, and keep it only if the refined output beats the first draft on your own test cases.
Can I combine these patterns?
Yes, and most production systems do. A sequential outer flow can contain a parallel fan-out in one stage and a small hierarchical planner in another. Choose the simplest shape each part allows, and put a deterministic gate at every seam between agents.
The gate this post refers to, drawn from the tool’s own logic. See the tool.