Orchestrator-Worker Pattern
One Claude routes subtasks to specialized subagents.
The orchestrator-worker pattern uses one Claude session as a router and multiple short-lived subagents as workers. The router reads the goal, decomposes it, dispatches subtasks, and stitches results.
Use it when subtasks are independent and parallelizable. Avoid it when subtasks share heavy context — pay the marshalling cost only if you save more in token reduction.
Real-world example: Contract review at a legal-ops team
A legal-ops team gets 200 commercial contracts a week. Each contract has ~60 clauses spanning indemnity, IP, payment terms, termination, governing law. A single agent reading the whole contract sequentially burns context and time.
The fix: an orchestrator parses the contract into clause chunks and dispatches each to a specialized worker ("indemnity-classifier", "payment-terms-extractor", etc.). Workers run in parallel and return structured findings. The orchestrator merges them into a risk report.
| Approach | Time per contract | Cost (Sonnet) | | ------------------ | ----------------- | ------------- | | Single agent | 80s | $0.42 | | Orchestrator + 8 workers | 14s | $0.31 |
Why this matters: when subtasks are independent and well-scoped, fan-out drops both latency and cost. The orchestrator-worker pattern is the right reach when subtasks share little context.
- Orchestrator routes subtasks to specialized workers
- Workers are short-lived and isolated
- Best when subtasks are independent and parallel
- Avoid when subtasks share heavy context
- Marshalling cost is paid for parallel speedup
- Stitching results is the orchestrator's job