VI · Multi-AgentMature★★

Orchestrator-Workers

also known as Dynamic Decomposition, Orchestrator-Subagents

An orchestrator dynamically breaks a task into subtasks at runtime and delegates each to a worker LLM, then synthesises results.

Context

A team is handling tasks where the right decomposition cannot be known in advance and depends on the input. A coding agent asked to audit a repository does not know how many languages or services it will find; a research agent does not know how many sub-questions a brief will need until it reads the brief. The number and shape of sub-tasks is data-dependent. This is distinct from supervisor, which routes work to a fixed set of pre-existing specialist agents; orchestrator-workers decides the sub-tasks at run time.

Problem

A static decomposition — a fixed plan-and-execute pipeline or a hard-coded prompt chain — cannot handle tasks whose shape depends on the input. Trying to enumerate every possible sub-task in the prompt produces a sprawling system that still misses the cases the team did not anticipate. Picking the wrong decomposition at design time forces every request through it, even the ones it does not fit. The team needs decomposition to happen after the task arrives, not before.

Forces

  • The orchestrator must reason at a higher level than any worker.
  • Workers should not have to know they are workers.
  • Synthesis must reconcile conflicting worker outputs.

Example

A coding agent receives a vague request — 'audit our service for unused dependencies and unused env vars'. A static plan-and-execute pipeline cannot decide upfront how many sub-tasks there are because it depends on what the audit finds. The team uses orchestrator-workers: the orchestrator inspects the repo, decides at runtime to spawn one worker per detected language toolchain, collects each worker's findings, and synthesises a single audit report. The worker count varies from one repo to the next.

Diagram

Solution

Therefore:

Orchestrator agent receives the task, decides at runtime what subtasks to spawn, hands each to a worker (often via tool call), collects results, and synthesises the final output. Worker count and roles can vary per task.

What this pattern forbids. Workers see only their assigned subtask; only the orchestrator has the global view.

The smaller patterns that complete this one —

  • generalisesSubagent Isolation★— Run subagents in isolated workspaces so their writes do not collide and parallelism is safe.
  • generalisesLead Researcher★★— A lead agent writes a research plan and dispatches parallel sub-agents that fan out for breadth-first information gathering, then merges results.
  • generalisesHierarchical Agents★★— Organise agents in a tree where higher-level agents decompose tasks for lower-level agents, recursively.
  • generalisesAgent-as-Tool Embedding★— Wrap a sub-agent (with its own loop, prompt, and tool palette) behind a single function-shaped tool signature, so the parent agent calls it like any other tool and never sees the sub-agent's internal turns.
  • usesAugmented LLM★★— Build the foundational agent block as an LLM augmented with retrieval, tools, and memory that the model actively chooses to use, rather than a bare-model call.
  • generalisesRL-Trained Conductor Orchestrator·— Train a small meta-model with reinforcement learning to dispatch sub-tasks across a pool of frontier LLM workers, learning the communication topology end-to-end and allowing the conductor to recursively invoke itself as a worker.
  • generalisesPlanner-Generator-Evaluator Harness·— Decompose a long-running job into three role-isolated agents — a Planner emitting a feature list, a Generator working one chunk per fresh context, and an Evaluator grading against a rubric without seeing the Generator's trace.
  • generalisesMagentic-One Generalist Multi-Agent★— Use Microsoft's generalist multi-agent architecture: a single Orchestrator agent dispatches to four specialist sub-agents (WebSurfer, FileSurfer, Coder, ComputerTerminal) for solving open-ended complex tasks that span web browsing, file manipulation, code execution and shell operations.

And the patterns that stand alongside it, or against it —

  • alternative-toSupervisor★★— Place a coordinating agent above a set of specialised agents and route work to them.
  • alternative-toPlan-and-Execute★★— Plan all the steps once with a strong model, then execute each step with a cheaper model under the plan.
  • complementsInter-Agent Communication★— Define a protocol for agents to exchange tasks, capabilities, and results across process or vendor boundaries.
  • complementsDynamic Expert Recruitment·— Generate the agent team — role descriptions and instances — at run time based on the specific task, then adjust team composition between iterations based on evaluation feedback.
  • alternative-toClone Fan-Out Research·— Spawn 100 or more identical, full-capability agent instances in parallel — each a complete general agent rather than a role-specialised worker — and aggregate their independent outputs into a single answer.
  • complementsRole-Typed Subagents✕— Anti-pattern: pre-allocate roles (manager, coder, designer, researcher) across a fixed set of typed sub-agents and route tasks to them by role label.
  • complementsOne Tool, One Agent★— Design agent systems as a team of narrow single-purpose agents, each owning one tool or one capability, rather than a single super-agent that handles every tool — the agent analogue of microservices over monolith.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

Used in recipes

Used in frameworks

Show 14 more

References

Provenance