Orchestrator-Workers Pattern
PatternsDefinition
A workflow composition pattern where a central LLM decides subtasks dynamically at runtime and delegates them to workers, in contrast to parallelization sectioning where the subtasks are already known in advance. It is still a workflow, not an agent, as long as the fact that delegation happens is fixed in code -- only the content of the subtasks is decided at runtime. This is the point where a workflow shades most closely into an agent, and the classic exam trap is confusing it with parallelization sectioning.
Why It Matters for the Claude Certification Exams
CCAR-P solution design and CCDV-F agents items distinguish workflow patterns. Orchestrator-workers is for tasks whose subtasks are not known until the model sees the input.
In Depth
The orchestrator-workers pattern is a workflow composition where a central LLM (the orchestrator) decides subtasks at runtime and delegates them to worker models or tools. The split is not hardcoded. Contrast that with parallel sectioning, where you already know the parts (summarize each chapter, score each file) and you fan those known jobs out.
When this is the right Claude design
Use orchestrator-workers when the incoming work is heterogeneous and unknown until inspection: a messy ticket that might need a code search, a policy lookup, or an email draft; a research question that might need two different MCP servers; a codebase question that might spawn a test-writer and a reviewer. The orchestrator reads the goal, decomposes, assigns, and integrates.
Do not use it when the decomposition is stable. If every request is "classify, then extract, then format," a fixed pipeline is cheaper, easier to eval, and easier to SLA. Dynamic orchestration adds tokens, latency, and failure modes (the orchestrator invents a nonsense worker, loops, or drops a subtask).
How it maps onto Claude products
- Agent SDK / multi-agent: a coordinator with subagents, session state, and hooks. CCA-F Agentic Architecture lives here; CCAR-P expects you to know when that complexity is justified.
- Claude Code Task tool: a practical orchestrator-workers instance: the main session delegates a bounded job to a subagent with a smaller tool set.
- Your own app: one Messages API call as orchestrator that emits structured work items, then worker calls (often Haiku) per item, then a merge call.
Workers should be narrow — see Capability bloat. The orchestrator should get the integration role and the policy; workers should not all have production write access.
Eval this pattern on traces: did the orchestrator create the right jobs, and did the merge respect worker failures? A held-out eval set of messy inputs is more useful than a single happy-path demo.
Frequently Asked Questions
How is orchestrator-workers different from parallel sectioning?
Sectioning fans out a split you already know (each chapter, each file). Orchestrator-workers lets the model invent the split after it sees the input. Use sectioning when the parts are stable; use orchestrator-workers when they are not.
Should every worker use the same model tier as the orchestrator?
Usually no. The orchestrator often needs a stronger tier to plan; workers can be cheaper and narrower. Putting Opus on every worker is a cost problem, not a reliability feature.