Orchestrator–worker: dynamic decomposition

Lesson 4 of 6 in Workflow Patterns: Five Ways to Compose Model Calls.

Every pattern so far shares one property: code fixed the structure before any model ran. The chain’s steps, the router’s categories, the fan-out’s branches — all decided at design time. Orchestrator–worker breaks that rule in exactly one place: a central model call looks at the task and decides at runtime what the subtasks are, then code dispatches workers to execute them and the orchestrator integrates the results.

That single change is what separates it from parallelization. A fan-out always runs the same three branches; an orchestrator might spawn two workers for this input and nine for the next, with briefs no one wrote in advance. You need this the moment subtasks cannot be enumerated up front — and not a moment before, because the price is steep.

Orchestrator–worker

Task arrives
Orchestrator: plan subtasks
One model call reads the task and emits a structured plan: a list of worker briefs. This is the dynamic step — the plan differs per input.
Code checks the plan
Bound it in code: max workers, budget ceiling, allowed task types. The orchestrator proposes; your code disposes.
Worker: subtask 1
Each worker is a focused call (or a small chain) executing one brief. Workers do not talk to each other — results flow back through the orchestrator.
Worker: subtask N
N was chosen by the orchestrator, not by your code — that flexibility is the point, and the cost risk.
Orchestrator: integrate
A final call merges worker outputs into one deliverable — and may decide another round is needed, if your loop budget allows one.
Deliverable
Reject plan / escalate
Plans that blow the budget or request off-limits work die here, before a single worker spends tokens.

Failure modes: runaway plans and overlapping briefs

Unbounded decomposition. Ask a model to “break this into subtasks” and some inputs yield forty subtasks, recursively. Cost is now a model decision instead of a code decision — the one thing a workflow was supposed to prevent. Cap workers, cap rounds, cap spend, and enforce the caps in code; a limit that lives in the prompt is a suggestion, and the plan-check gate exists precisely because suggestions get ignored.

Overlapping and orphaned briefs. Nothing forces a generated plan to be a clean partition: two workers both rewrite the auth section, no worker covers the migration, and the contradiction only surfaces — if it surfaces — at integration. Validate plans structurally where you can (coverage and duplicate-target checks are code), and make the integration step explicitly responsible for resolving conflicts rather than concatenating them.

The quiet drift into multi-agent. Give workers their own multi-turn loops, memory, and tool budgets, and you have left workflow territory: that is supervisor–worker coordination between separate context windows, with the telephone-game and divergent-state failures covered in the multi-agent module. Cross the line deliberately or not at all.

The cost profile follows directly: unpredictable by design. A chain’s cost is known at design time; a fan-out’s is known at dispatch; an orchestrator’s is known only after the plan lands. Budget-wise you are writing the model a bounded blank check — so the bound, not the average, is the number to engineer. When the plan for most inputs turns out identical, take the hint: freeze it into a fixed fan-out and stop paying the orchestrator to rediscover it.

Key terms: orchestrator–worker, orchestration, supervisor–worker, subagent, structured outputs

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.