How it works
Orchestrator-Worker organizes an agent system into two roles with a strict contract between them.
- Decompose. The orchestrator reads the goal and breaks it into subtasks small enough that a single worker can finish one in a bounded number of steps.
- Assign. Each subtask is dispatched to a worker with its own fresh context: the instruction, the inputs it needs, and nothing else. Workers do not share a scratchpad by default.
- Execute. A worker runs its own loop — reason, call tools, produce output — against just that subtask. It has no view of the wider plan and no authority to redefine it.
- Return. The worker hands back a result. The orchestrator treats that result as evidence, not as a new instruction, and decides what to do next: accept it, re-dispatch, spawn dependent work, or stop.
- Integrate. The orchestrator composes the accumulated results into the final answer or artifact.
The defining property is the split of authority. The orchestrator holds the plan, the state, and the decision to continue; workers hold only execution. Because each worker starts from a clean context and owns one narrow job, the system reads as a set of independent, replayable units rather than one long entangled trajectory. That legibility is the whole point — it is what lets you reason about, bound, and roll back the system.
Why it matters in an agent harness
A harness exists to keep an agent controllable, and the orchestrator-worker split gives you several controls almost for free.
- Blast-radius containment. A worker's permissions can be scoped to its one subtask. A worker that summarizes a document never needs write access; a worker that edits a file never needs the network. You grant least privilege per job instead of one union of everything the whole task might touch.
- Failure isolation. When a worker goes off the rails — loops, hallucinates, misuses a tool — the damage is confined to its subtask. The orchestrator sees a bad or missing result and re-dispatches, rather than the whole run collapsing.
- Observability. Each worker is a discrete unit with a clear input, a clear output, and its own log. That is a far better trace to inspect than one thousand-step monologue, and a far better surface to attach evals to.
- Context hygiene. Fresh worker contexts stop the orchestrator's context from bloating with every intermediate detail. The orchestrator keeps the plan; workers absorb the mess.
- Reversibility. Because results come back as evidence the orchestrator chooses to accept, you have a natural checkpoint boundary. You can review, gate, or discard a worker's output before it becomes committed state.
Orchestrator-Worker vs agent orchestration
These overlap but are not the same, and conflating them leads to muddy permission and eval design.
| Aspect | Orchestrator-Worker | General agent orchestration |
|---|---|---|
| What it names | A specific role split: one planner, many single-task executors | Any coordination of multiple agents or steps |
| Authority | Centralized in the orchestrator | May be peer-to-peer, negotiated, or emergent |
| Worker context | Isolated per subtask | Often shared or accumulated |
| Failure model | Contained to a worker | Depends on topology |
Orchestrator-Worker is an opinionated orchestration topology. You reach for it when you want central authority and hard isolation between units — not when you want agents negotiating as peers.
The Rifty take
We treat the orchestrator as a control point, not just a dispatcher. What we optimize for is that every worker is a bounded, replayable, least-privilege unit whose result is proposed, never automatically committed — the orchestrator decides what becomes state. We accept the coordination cost and the extra latency of that boundary, because a contained, legible failure is worth far more than a fast one you cannot localize. The moment a worker can silently rewrite the plan, you have lost the pattern's only real guarantee.
Common failure modes
- Worker scope creep. Subtasks defined too broadly turn workers back into full agents, erasing isolation and blast-radius limits. Keep each subtask small enough to verify.
- Instruction leakage. Treating a worker's output as an instruction rather than as evidence lets a confused or injected worker steer the orchestrator. Parse results; never execute them.
- Shared mutable state. Workers writing to a common store behind the orchestrator's back reintroduce the entanglement the pattern was meant to remove.
- Uniform permissions. Granting every worker the orchestrator's full tool surface throws away least privilege — the cheapest control the pattern offers.
- Unbounded fan-out. Spawning workers without an iteration or concurrency budget converts parallelism into runaway cost. Cap it.
- No integration check. Composing worker results without validating their consistency ships a plausible-looking but internally contradictory artifact.
Frequently asked questions
When should I use Orchestrator-Worker instead of a single agent loop?
Reach for it when a task has separable subtasks that benefit from isolation, parallelism, or different permissions. A single loop is simpler and cheaper for linear work; the orchestrator-worker split earns its coordination cost when you need failure containment, per-subtask least privilege, or a cleaner trace to evaluate.
How is Orchestrator-Worker different from a Multi-Agent System?
Multi-agent system is the broad category; Orchestrator-Worker is one specific topology within it. The pattern fixes a centralized authority — one orchestrator plans and decides — and gives workers isolated, single-task contexts. Other multi-agent designs allow peer negotiation, shared state, or emergent coordination without that strict role split.
Should workers share context with the orchestrator?
By default, no. Isolation is the pattern's main value: each worker gets only what its subtask needs, and returns a result rather than mutating shared state. Share context deliberately and narrowly when a subtask genuinely requires it, not as a convenience, or you reintroduce the entanglement you were avoiding.
What is the biggest risk in an orchestrator-worker system?
Treating worker output as instructions instead of evidence. If a worker's result can silently steer or rewrite the orchestrator's plan, a confused or prompt-injected worker compromises the whole run. The orchestrator must parse results and hold sole authority over what becomes committed state and what work happens next.
How do I keep worker cost under control?
Bound the fan-out. Set concurrency and iteration budgets so the orchestrator cannot spawn workers indefinitely, and keep each subtask small enough to finish in a few steps. Uncapped decomposition turns the pattern's parallelism into runaway token and latency cost with no natural stopping point.