Agent orchestration patterns are the architectural templates that determine how multiple agents (or a single agent across multiple steps) coordinate to accomplish a task. Just as software engineering has design patterns for recurring problems — factory, observer, singleton — agent systems have patterns for recurring coordination challenges: how to divide work, how to manage dependencies, how to handle errors, how to verify outputs before committing to the next step. Understanding these patterns lets you design agent systems deliberately rather than discovering the right architecture through trial and error. This guide covers the six most important patterns with concrete descriptions of when each applies.
Sequential Pipeline
The sequential pipeline is the simplest orchestration pattern: agents or steps execute in a fixed order, with each step consuming the output of the previous. The output of step N is the input to step N+1. Examples: a research pipeline where one agent searches the web, a second extracts key facts, and a third synthesises a report; a content pipeline where one agent generates a draft, a second edits for clarity, and a third checks facts. Sequential pipelines are easy to understand, easy to debug, and easy to build. The limitation is that they have no parallelism — the total latency is the sum of all steps — and they are brittle to step failures: if one step produces bad output, all subsequent steps inherit that error. Best for: tasks with clear linear dependencies where each step requires the output of the previous.
Parallel Fan-Out and Fan-In
The fan-out/fan-in pattern runs multiple independent subtasks in parallel and combines their results. A coordinator agent decomposes the main task into N independent subtasks (fan-out), dispatches them to N agents or sub-processes running simultaneously, waits for all to complete, and combines the results (fan-in). Examples: a competitive analysis agent that simultaneously researches five competitors and then synthesises a comparison; a document processing agent that splits a large document into sections and processes each section in parallel. This pattern reduces total latency for decomposable tasks from the sum of subtask latencies to the maximum of subtask latencies. The complexity is in the fan-out decomposition (deciding how to split the task) and the fan-in synthesis (how to merge results that may have inconsistencies). Best for: tasks that decompose into independent subtasks where the decomposition and recombination logic is clear.
Supervisor / Worker
The supervisor pattern has a coordinator agent that plans and delegates, and worker agents that execute specific tasks. The supervisor receives the high-level goal, determines which workers to engage and in what order, delegates to them, reviews their outputs, and decides whether to accept the output, request revision, or escalate. Workers are specialised — each has a defined scope of capability — and communicate only with the supervisor, not with each other. Examples: a software engineering agent where a supervisor understands the overall codebase and delegates specific file edits to worker agents; a research agent where a supervisor plans the research strategy and delegates individual searches and analyses to specialist workers. The supervisor pattern provides centralised control and quality checking at the cost of the supervisor becoming a bottleneck. Best for: complex tasks requiring coordination of specialised capabilities where quality control at each step is important.
Figure 1 — The six core agent orchestration patterns
Evaluator-Critic Pattern
The evaluator-critic pattern separates generation from evaluation: one agent (or model call) generates output, and a separate evaluator agent reviews it against defined quality criteria and either approves it or sends it back for revision with specific feedback. This is a structured form of quality control that catches errors before they propagate. In its simplest form, it is a loop: generate, evaluate, revise if needed, evaluate again — with a maximum iteration count to prevent infinite loops. Examples: a code generation agent where a generator writes code and an evaluator runs tests; a writing agent where a drafter writes and an editor reviews for accuracy and tone; a planning agent where a planner proposes a plan and a critic checks it for logical consistency. The pattern improves output quality at the cost of additional latency and token usage. Best for: tasks where output quality is measurable against clear criteria and the cost of a bad output justifies the overhead of review.
Swarm Pattern
The swarm pattern consists of multiple peer agents, each with specialised capabilities, that hand tasks between themselves based on which agent is best suited to the current step. There is no central supervisor — routing decisions are made by whichever agent currently holds the task. When an agent determines that the next step is outside its specialisation, it hands off to the appropriate peer. Examples: a customer service system where a triage agent hands off to a billing specialist, which may hand off to a technical support agent; a research system where a general research agent hands off specific sub-questions to domain specialists. Swarm patterns scale naturally as you add new specialist agents and are resilient to individual agent failures — the task simply routes to a different agent. The complexity is in routing logic: how does each agent decide when and to whom to hand off? Best for: systems with many distinct specialisations and dynamic task routing needs.
ReAct Loop
The ReAct (Reason-Act) loop is the foundational single-agent orchestration pattern: the agent alternates between reasoning about what to do next and taking an action (tool call), then observing the result before reasoning about the next step. Every tool-use agent implements some form of this pattern — it is the core loop that turns a language model into an agent. The key design decisions are: how much reasoning is the agent allowed before each action, what is the maximum loop depth (to prevent infinite loops), how to handle tool failures, and when to conclude that the task is done or unachievable. The ReAct pattern is the building block from which all the multi-agent patterns above are constructed — each complex pattern is ultimately built from multiple coordinated ReAct loops. Best for: single-agent tool use and as the internal loop within each agent in any multi-agent system.
Choosing the Right Pattern
Pattern selection follows task structure. If the task is linear with clear step dependencies, use sequential. If the task decomposes into parallel independent subtasks, use fan-out/fan-in. If the task requires specialised capabilities with quality control, use supervisor/worker. If the output needs review before acceptance, add an evaluator layer. If you have many specialisations and unpredictable routing, use swarm. In practice, most production agent systems combine multiple patterns: a supervisor that fans out to parallel workers, each of which runs a ReAct loop internally, with an evaluator checking the final output before it is returned. The patterns are composable, and the right architecture is usually a combination rather than any single pattern applied uniformly.
Orchestration patterns give agent system design a common vocabulary and a set of proven templates. The value is not that patterns are prescriptive — no pattern fits every situation — but that they make the design space navigable. When you encounter a new agent design problem, mapping it to the nearest pattern tells you which trade-offs to expect, which failure modes to design for, and which implementation approaches have worked before. Design from patterns deliberately, adapt them to your specific constraints, and document which patterns your system uses so the architecture remains understandable as it grows.
Error Handling Across Patterns
Every orchestration pattern needs a defined error handling strategy, and the right strategy differs by pattern. In sequential pipelines, a step failure can mean retrying the failed step, skipping it with a fallback output, or aborting the pipeline and returning a partial result. In fan-out/fan-in, a single subtask failure may be recoverable — complete with the successful subtasks and note what was missing — or it may require retrying just the failed branch. In supervisor/worker systems, the supervisor decides whether a failed worker output is acceptable, needs revision, or should be delegated to a different worker. In evaluator-critic loops, the maximum revision count needs a hard limit so that the system does not loop indefinitely when the generator and evaluator disagree. Swarm systems need circuit-breaker logic to prevent a task from bouncing indefinitely between agents that each refuse it. Designing error handling explicitly — not as an afterthought — is what separates production-grade orchestration from prototypes that work only on the happy path.