A single agent loop can hold a complex project for hours. It can track state, call tools, write files, revise based on feedback, and complete tasks that took a human most of a day. That loop is the working unit of agentic work.
The next failure mode arrives when that loop is asked to hold too much at once — to simultaneously manage a research task, a code review, a content pipeline, and a compliance check, each with different context requirements and different tool sets. The loop can switch between them, but switching is not the same as parallel execution, and context for one task actively dilutes context for another.
Multi-agent orchestration is the discipline of splitting one loop into a coordinator and specialists, with explicit handoffs and a shared contract. It is not a silver bullet. Most of the time, a single well-scoped loop is the right answer.
When one agent is enough
The default should be one agent. The conditions that make a single loop correct:
- The task is decomposable only at a coarse granularity — you can define the inputs and outputs clearly, and the loop can execute without external coordination.
- Context requirements are shared — all steps benefit from the same loaded knowledge, and no step's context would actively interfere with another.
- The task does not have independent parallel sub-tasks. If two sub-tasks can run simultaneously, a single loop is inefficient by definition.
The sessions and sub-agents model covers the most common case: a parent session spawning a child session for a bounded subtask, with the parent resuming when the child completes. That is not multi-agent orchestration — it is delegation within a single-loop architecture.
The line is whether the child has its own loop identity, its own memory scope, and its own coordination contract — or whether it is simply a scoped execution of the parent's logic.
When a team is the right shape
The signal that multi-agent orchestration is needed:
1. The task has genuinely independent sub-tasks that could run in parallel without sharing state during execution. 2. The sub-tasks have different context requirements that would require purging and reloading context if run in a single loop. 3. The coordination logic is complex enough that the coordination itself would dominate a single loop's execution time. 4. The handoffs between sub-tasks are well-defined enough that a contract can be written: "Specialist A produces X, hands it to Specialist B, which produces Y."
If the sub-tasks are not independent — if the output of one is the input to another in a tightly coupled way — you may have a pipeline rather than a team. The distinction matters: a pipeline is a directed flow; a team is a set of parallel specialists with a coordinator.
The three orchestration patterns
Planner / Worker
The coordinator holds the full picture; the specialists hold narrow, deep context.
The coordinator receives the top-level goal, decomposes it into sub-tasks, assigns each sub-task to a specialist worker, receives the outputs, and assembles the final result. The workers do not know about each other. They only know their assigned task and the interface they must output.
This pattern works when:
- The top-level goal is clear enough to decompose reliably.
- Sub-task outputs are composable — the coordinator can assemble them without re-executing the work.
- Worker failures are recoverable — if one worker fails, the coordinator can reassign the sub-task without restarting the whole decomposition.
The failure mode is a bad decomposition. If the coordinator makes a wrong call about how to split the work, the whole execution fails in a way that is hard to debug, because neither worker had the full picture.
Peer Review
Each worker produces output, then a review agent checks it against the original requirements before the result is accepted.
This pattern works for quality-critical pipelines where a single execution pass is insufficient. The reviewer is not a supervisor — it is a second specialist with a different context. It reads the original goal, reads Worker A's output, and flags discrepancies. If the discrepancies are fixable, Worker A revises; if they are design errors, the coordinator intervenes.
The failure mode is review loops — Worker A revises, Reviewer B rejects again, Worker A revises again. Without explicit termination criteria, peer review can iterate indefinitely. Build a maximum revision count into the contract.
Pipeline
The output of Worker A is the input to Worker B, which is the input to Worker C. There is a coordinator, but the coordinator's role is to manage the pipeline state — which stage is running, what the current output is, when to terminate — not to decompose the work.
A pipeline is not a team in the same sense as the other two patterns. It is a directed graph where each node is a specialist and the edges carry state. The state graph is the architecture.
The pipeline pattern works when the sub-tasks are sequential by definition — research before writing, write before review — and when the output of each stage must be correct before the next stage begins. It is the least "multi-agent" of the three patterns architecturally, because the agents are executing a flow, not making independent decisions.
Context drift between agents
The most common multi-agent failure is not a crash. It is silent context drift: Agent A and Agent B loaded different assumptions at intake, and the artifact they both think they are working on has two slightly different definitions.
This happens because each agent in a multi-agent setup has its own session scope. The coordinator's context is not automatically the workers' context. If the coordinator produces a task brief for Worker A, and Worker A interprets that brief differently than the coordinator intended, the handoff artifact will be subtly wrong — correct enough to pass a cursory check, wrong enough to cause a downstream failure.
The mitigation is a written shared contract: the coordinator writes a brief that Worker A signs off on before execution. The brief specifies not just what to produce but what the output looks like, what counts as complete, and what counts as a failure. That contract is the only shared state. Everything else lives in the individual agents' sessions.
Responsibility gaps at handoffs
The second most common failure is at the handoff: Agent A finishes its work and waits for Agent B to pick it up, but Agent B is still busy with a previous task, or Agent B's intake process loaded the wrong version of the artifact, or Agent B finished hours ago and the artifact has been superseded without Agent A knowing.
Responsibility gaps are a coordination problem, not an agent problem. The agent loop of each agent is correct; the problem is that no single loop owns the handoff boundary.
The mitigation is an explicit state owner. One agent — usually the coordinator — is responsible for the artifact at every point in time. When the artifact is handed from Worker A to Worker B, the coordinator confirms the handoff, updates the state, and notifies Worker B before Worker A is considered done. If Worker B does not confirm receipt, the coordinator escalates.
Without this, you get agents that finish their work and leave it in an undefined state — not a crash, not an error, just work that is done but not owned by anyone.
Deadlock between agents
The third failure mode is deadlock: Agent A is waiting for something from Agent B, and Agent B is waiting for something from Agent A. Both loops are correct; the system is stuck.
Deadlock happens when the shared contract allows circular dependencies. Agent A will not hand over output X until it receives confirmation Y from Agent B. Agent B will not confirm Y until it receives artifact Z from Agent C. Agent C is waiting on Agent A.
The mitigation is contract discipline: the coordinator must verify that the dependency graph is acyclic before execution begins. If a cycle exists, it must be broken by giving one agent unilateral ownership of the circular resource — the coordinator, typically.
What multi-agent orchestration cannot fix
Multi-agent orchestration adds coordination overhead. The coordinator must manage state, track handoffs, and handle failures. That overhead is paid in development time and in runtime infrastructure. If a single agent can do the job, it will almost always be faster to build, easier to debug, and more reliable.
The multi-agent pattern is justified when the parallelism provides a genuine speed or quality benefit that cannot be achieved in a single loop. If the task can be decomposed but the decomposition adds more coordination overhead than it removes execution cost, it was the wrong choice.
The loops versus graphs distinction is the relevant frame: a single loop is a loop; a multi-agent setup is a graph. Graphs are more expressive. They are also harder to debug. Reach for loops first.