Orchestrator-Worker vs Peer Agents
4 min read · updated August 3, 2026
Multi-agent diagrams all look plausible on a whiteboard because a whiteboard has no budget, no partial failures and no context window. Two questions distinguish them in production, and neither is usually asked in the design review.
Two questions that pick the topology
Who owns the budget? Somewhere there must be a component that knows the total spend and total elapsed steps for the whole task and can halt everything. If no component has that view, the system has no stopping condition — it has several local ones that can each be satisfied while the task as a whole runs away. This single question eliminates most peer designs immediately.
Where does information get compressed? Every agent-to-agent boundary is a summarisation, and summarisation is where detail dies. A worker that read 40,000 tokens of code and hands back 300 tokens of findings has thrown away 99% of what it learned, and the orchestrator cannot know which 1% it kept. Position those boundaries where the loss is acceptable; if you cannot find such a place, you have a single-agent task.
The four topologies
1. Single loop with tools
One agent, one context, N tools. Budget owner: obvious. Compression boundaries: none, until compaction. This is the baseline and it should be your default — every other row here is a reason to leave it, and the reason should be nameable.
2. Orchestrator and workers
One planning agent spawns workers with narrow briefs and receives their results. Workers do not talk to each other. State lives in the orchestrator’s context; workers are stateless between invocations. Budget owner: the orchestrator, which is what makes this the most operable multi-agent shape. Compression: at every worker return, which is one boundary you can design carefully.
3. Pipeline (handoff chain)
A fixed sequence: researcher, then writer, then reviewer. Each hands its output to the next. Sometimes called handoffs. This is a workflow with agents in the stages, and that is a compliment — it is predictable, cheap and traceable. Budget owner: the pipeline driver. Compression: at every stage boundary, and it accumulates.
4. Peer network / blackboard
Agents address each other, or read and write a shared scratchpad, with no fixed hierarchy. Genuinely useful for adversarial patterns — a critic that can push back on a writer until a quality bar is met — and for simulations where the interaction is the output. Budget owner: nobody, unless you build one. Compression: everywhere, and unpredictably.
Two of those four are not really multi-agent designs, and it is worth saying so before comparing them. A pipeline is a workflow whose stages happen to call models; the single loop is one agent. Only orchestrator-worker and peer networks introduce the genuinely new problem — a component whose input is another component’s judgement rather than a value — and all four failure modes below are versions of that.
The failure mode of each
| Topology | Description |
|---|---|
| Single loop | Context exhaustion. Around step 30-50 the transcript crowds out the evidence, compaction drops the wrong thing, and the agent starts repeating work it already did. Symptom: the same tool call with the same arguments, twenty steps apart. |
| Orchestrator/worker | The summary bottleneck. The worker found the answer and its summary did not carry it, so the orchestrator dispatches a second worker to find the same thing. Symptom: high total cost with each individual agent behaving sensibly. Fix: have workers write full findings to a file and return a pointer, not a paragraph. |
| Pipeline | Error propagation with no back-edge. Stage 1 misreads the brief, stages 2 and 3 execute faithfully on the wrong premise, and the output is confidently wrong end to end. Symptom: a polished deliverable answering an adjacent question. Fix: give at least one stage the authority to reject and return. |
| Peer network | Non-termination and mutual deference. Two agents converge on agreeing with each other, or ping-pong politely without progress, and no component has standing to stop it. Symptom: a run that ends only because the wall-clock timeout fired. Fix: an external referee that counts rounds -- which is an orchestrator. |
Notice that three of the four failure modes are invisible in any single agent’s trace. The orchestrator behaved reasonably; each worker behaved reasonably; the system wasted forty dollars. This is the argument for run-level tracing with a shared trace id, covered in observability for agents — without it, multi-agent debugging is guesswork.
Choosing, in order
- Start single. If it works within your step budget, stop. You have avoided every failure mode above except the first.
- If the work fans out, go orchestrator-worker. Parallel independent subtasks are the one shape where the cost model in multi-agent systems comes out ahead. Make workers write artefacts, not summaries.
- If the stages are genuinely fixed, use a pipeline — and then ask whether the stages need to be agents at all. Two of the three usually do not.
- Use a peer network only when the interaction is the product. Debate, critique, negotiation, simulation. Give it a referee with a round counter and a hard budget on day one, not after the first runaway.
A note on migration, because the direction is asymmetric. Going from a single loop to orchestrator-worker is a refactor; going back is not. Once workers exist, prompts specialise around them, tools are split between them, evals get written per worker, and the shared context that made the single agent work has been designed out of the system. Delaying the split until the single-agent version has hit a wall you can name in one sentence is not conservatism — it is the only point at which you can tell whether the split fixed anything.
One rule cuts across all four: an agent should never be able to spawn an agent without a budget being passed down and decremented. Recursive spawning with fresh budgets at each level is how a task with a twenty-dollar cap spends four hundred, and it is a two-line fix if you make the budget an explicit argument from the start.