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.
Intent & 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.
Real-world Use Case
- 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.
Source
📌 TL;DR
The orchestrator reads the input, decides what subtasks to spawn on the fly, dispatches to workers, synthesizes results — task decomposition is data-driven, not pre-wired.
Advantages
- Handles genuinely data-dependent decomposition that a fixed topology can’t.
- Workers stay simple and focused; all coordination complexity lives in the orchestrator.
Disadvantages
- Orchestrator failure is unrecoverable without explicit retry logic.
- Token cost scales with worker count — budget awareness is essential.