Orchestrator-Worker: Plan, Delegate, Synthesize
The Orchestrator-Worker pattern parallelizes complex tasks by having one LLM plan the decomposition, multiple workers execute in parallel, and the orchestrator synthesize the results. This article covers when it actually earns its 4× cost premium, how to validate plan quality before spending on workers, production hardening, and how to run an A/B eval against a single-agent baseline.
Quick Reference
- →Minimum cost: N+2 LLM calls (1 plan + N workers + 1 synthesis) — verify the quality premium justifies it
- →Plan quality is the single point of failure: validate count (3–7), overlap, and coverage before fan-out
- →Send API dynamically creates worker instances at runtime; workers get a state copy, not a reference
- →Workers write results to shared state via operator.add reducer — the fan-out/fan-in pattern
- →Use try/except in every worker; return status-tagged error results instead of crashing the graph
- →Run an A/B eval against a single-agent baseline before committing — the pattern must earn its cost
- →Monitor plan decomposition distribution, worker P95 latency, and partial failure rate in production
Should I Use Orchestrator-Worker?
Orchestrator plans → Send API fans out to workers → reducer collects → orchestrator synthesizes
The Orchestrator-Worker pattern is a two-phase approach: (1) an orchestrator LLM analyzes the task and creates a plan of subtasks, then (2) worker agents execute each subtask in parallel via LangGraph's Send API. The orchestrator collects all results and synthesizes a final output. Use it when work is genuinely decomposable into independent parallel subtasks — and when the quality improvement justifies the cost.
A 5-worker research task requires 7 LLM calls minimum (1 plan + 5 workers + 1 synthesis). With claude-sonnet-4-6 pricing, that costs roughly 4× a single-agent call on the same task. The pattern earns its keep when: (1) subtasks are genuinely independent, (2) parallelism meaningfully reduces wall-clock time, and (3) the quality improvement is measurable. If a single agent with a detailed prompt gets within 10% quality, use it instead.
| Situation | Why orchestrator-worker fails to earn its keep | Use instead |
|---|---|---|
| Fewer than 3 subtasks | Overhead of planning + synthesis exceeds parallelism benefit | Single agent or prompt chaining |
| Subtasks are sequential (step 3 needs step 2's output) | Workers can't run in parallel — they'd block each other | Plan-and-Execute |
| Simple classification or dispatch | One-hop routing, no synthesis needed | Router pattern |
| Iterative refinement needed | Workers don't self-correct | ReAct or Evaluator-Optimizer |
| All subtasks are identical operations | No specialization benefit, just fan-out | Parallelization pattern |
| Task is exploratory (unknown decomposition) | Planner can't produce a valid plan upfront | ReAct with subgraph workers |
Orchestrator-Worker is justified only when tasks are decomposable, plural, and heterogeneous
| Aspect | Router | Supervisor | Orchestrator-Worker | Plan-and-Execute |
|---|---|---|---|---|
| LLM calls | 2 (classify + worker) | Iterative (N rounds) | N+2 (plan + workers + synth) | Sequential (plan steps) |
| Coordination | One-hop dispatch | Iterative delegation | Upfront plan → parallel | Step-by-step execution |
| Subtask count | 1 (the routed task) | Variable | 3–7 parallel | 1 per step, sequential |
| Latency shape | Low, predictable | Unbounded | Workers in parallel | Bounded, sequential |
| Failure mode | Wrong route | Infinite loop | Bad plan or partial failure | Early step blocks chain |
| Best for | Dispatch by type | Complex multi-turn | Parallel decomposition | Ordered multi-step |