# Orchestrator-Workers

> An orchestrator decides at runtime what subtasks to spawn and delegates each to a worker — the decomposition itself is data-dependent and can't be planned statically.

- **Category**: Agentic AI
- **Subcategory**: Multi-Agent
- **Canonical URL**: https://designpattern.fyi/patterns/orchestrator_workers/

---

## Description
**Intent**: An orchestrator dynamically breaks a task into subtasks at runtime and delegates each to a worker LLM, then synthesizes results.
**Context**: The right decomposition depends on the input and can't be predetermined. A coding agent auditing a repository doesn't know how many languages or services it will find; a research agent doesn't know how many sub-questions a brief will need until it reads the brief. This is distinct from supervisor, which routes work to a fixed set of pre-existing specialist agents.
**Solution**: Orchestrator agent receives the task, decides at runtime what subtasks to spawn, hands each to a worker (often via tool call), collects results, and synthesizes the final output. Worker count and roles vary per task.



## Use Cases
- The shape of decomposition depends on the input and cannot be planned statically.
- An orchestrator agent can decide subtasks at runtime and synthesize results.
- Worker count and roles legitimately vary from one task instance to the next.






## Trade-offs


### Advantages

- Handles genuinely data-dependent decomposition that a fixed topology can't.

- Workers stay simple and focused; all coordination complexity lives in the orchestrator.




### Considerations & Drawbacks

- Orchestrator failure is unrecoverable without explicit retry logic.

- Token cost scales with worker count — budget awareness is essential.







---
**Reference**: [Original Source](https://www.agentpatternscatalog.org/patterns/orchestrator-workers/)