Multi-agent orchestration: when one agent isn't enough, you build a team.
A single AI agent can handle a focused task. But a complex problem - reviewing a PR across security, performance, and documentation simultaneously - breaks a single agent's context window and degrades its output. Multi-agent orchestration splits the work across specialized agents, each with a clean context and one job, then reassembles the result.
One coordinator, three specialist workers, one aggregator, one verification gate. The coordinator never touches the code. The workers never spawn sub-agents. Tool partitioning enforces this structurally - not by suggestion, by capability removal.
Every multi-agent system, regardless of pattern, is built from four operations.
These are not optional. Skip one and the system breaks in a predictable way.
Task Decomposition
Transform a high-level goal into a structured set of subtasks with defined dependencies. The output is a DAG - a directed acyclic graph - where each node is a job one agent can complete in a clean context window. If the decomposition is wrong, every downstream step produces the wrong thing.
Routing
Assign each subtask to the agent best equipped to handle it. The security agent doesn't get the performance task. Routing is a matching problem: agent capability to task requirement. A bad route wastes tokens and produces wrong output.
State Management
Carry context between agents without carrying the entire conversation history. Each agent receives only what it needs - the task description, relevant prior results, and any shared artifacts. Over-sharing state bloats context windows. Under-sharing loses critical information.
Failure Recovery
A local failure in one worker must not cascade. If the security agent times out, the performance and docs agents still complete. The coordinator receives the failure, decides whether to retry, reassign, or report partial results. 36.94% of multi-agent failures are coordination failures - recovery is structural, not aspirational.
Three patterns cover nearly every production use case.
Start with the simplest pattern that works. Add complexity only when the task genuinely demands it.
Hub and Spoke
One coordinator decomposes the task, delegates to specialist workers, and synthesizes results. Workers never talk to each other. Best for 2-5 distinct subtasks requiring different expertise. The coordinator is the single point of control - and the single point of failure.
Parallel
N independent tasks launch simultaneously. All agents run the same loop with different inputs. Results are collected and aggregated in one operation. Use when subtasks share no dependencies. If they do, the swarm produces inconsistent output - use a coordinator instead.
Sequential Transfer
Agents pass control directly to the next specialist. Each agent decides whether to handle the task or transfer it. No central coordinator. Best when the optimal agent sequence isn't known upfront. Risk: infinite handoff loops if no agent declares completion.
A code review pipeline: one PR, three agents, one result.
Here is a real multi-agent orchestration, step by step. The task: review a pull request for security vulnerabilities, performance regressions, and documentation gaps - all in parallel.
Coordinator receives the task
The coordinator agent gets the PR diff and the instruction: "Review for security, performance, and documentation." It does not read the code itself - it does not have file-reading tools. It decomposes the task into three subtasks, each with a self-contained prompt describing exactly what to check and what to return.
Fan-out: three workers launch in parallel
The Security Worker scans for SQL injection, hardcoded secrets, missing input validation, and unsafe deserialization. The Performance Worker checks for N+1 queries, unbounded loops, missing indexes, and large allocations. The Docs Worker reviews function signatures, public API comments, and README updates. Each worker gets only the diff, its focused prompt, and its domain-specific tools. They run simultaneously.
Aggregation: results are collected and synthesized
The aggregator receives all three worker outputs: security found two vulnerabilities (one critical), performance flagged one N+1 query, docs noted three undocumented public functions. It merges these into a single review, removes duplicates, and resolves any contradictions - for example, if the security agent flagged a pattern that the performance agent also noted, the aggregator deduplicates before presenting.
Verification: a QA gate checks the output
A final verification agent receives the synthesized review alongside the original PR diff. It checks that every flagged issue references a specific line of code, that no duplicate issues remain, and that the severity ratings are consistent. If the verification fails - missing line references, contradictory severity - the review goes back to the aggregator. If it passes, the review is delivered.
Tool partitioning: the structural enforcement that prompts alone cannot provide.
The most common failure in multi-agent systems is not a bad prompt. It is an agent doing something it was never supposed to do. A coordinator that starts reading files directly instead of delegating. A worker that spawns sub-agents in an uncontrolled cascade. These failures are not fixed by better instructions - they are fixed by removing the capability entirely.
Tool partitioning creates two hard guarantees. The coordinator has orchestration tools - spawn, send, cancel - but no implementation tools. It cannot read a file or run a command. If it needs information, it must delegate. Workers have domain tools - file read, search, test execution - but no orchestration tools. They cannot spawn sub-agents. No amount of creative prompting can bypass this, because you cannot call a tool that does not exist in your toolset.
A prompt that says "don't read files directly" works at turn three. By turn forty, the model has forgotten or rationalized past it. Removing the tool is a guarantee that holds regardless of how confused, tired, or creative the model gets.
"One agent can do one thing well. A team of agents, coordinated through clear boundaries and verified handoffs, can do what no single agent can."
Start with the simplest pattern that works. Orchestration pays for itself when the task genuinely benefits from parallelism, context isolation, or hierarchical planning - not before.
Tool partitioning is the only guarantee. You cannot prompt your way out of an agent doing something it should not - remove the capability, not the permission.