Back to the map

Module 11 · Workflow patterns · Lesson 4 of 5

Orchestrator-workers

A central model decomposes the task at run time, delegates subtasks to narrow worker calls and synthesises their results: how it differs from sectioning, what each prompt holds, how context flows down and results up, and the failure modes.

CoreMust-knowMid 12 minPro Updated Nov 2026

Why it matters

Sectioning assumes you can write the split into the code. Many tasks resist that: a research question whose sources are discovered as you go, a code change whose affected files depend on what the first file reveals, a report whose sections depend on what the data contains. Orchestrator-workers hands the split to a model. One call reads the task and produces a plan of subtasks; worker calls do the subtasks; a synthesis step merges the results. It is the pattern beneath most research features and multi-file coding tools, and the last stop before a full agent loop. Interviewers ask because cost and quality both scale with how well the decomposition is controlled.

The idea

The split is dynamic

In sectioning the subtasks are known before the first call. In orchestrator-workers they are the output of the first call. The orchestrator reads the task and the available context and emits a plan: a list of subtasks, each with a goal, the slice of context it needs and the shape of result expected. Code reads the plan, runs a worker call per subtask, usually in parallel, collects the results and runs a synthesis call. The plan is data, which is what keeps this a workflow: the code decides how many workers run, in what order, and when to stop.

Three prompts

The orchestrator's prompt has three jobs: decompose the task into subtasks that are independent and sized for one call, assign each the context it needs and nothing more, and specify the merge, including what a contradiction between results should do. It returns a schema, not prose, and the schema caps the number of subtasks.

{
  "shared": { "period": "2026 Q3", "audience": "board", "currency": "USD" },
  "subtasks": [
    { "id": "pricing", "goal": "Summarise pricing changes in the period", "context": ["pricing-log.md"] },
    { "id": "churn", "goal": "Report churn by segment with sources", "context": ["churn-q3.csv"] }
  ],
  "merge": "One report. Flag any number that two sections disagree on; do not pick silently."
}

A worker's prompt is narrow. It states one goal, carries the context slice the plan assigned, repeats the shared facts, and asks for a result in a fixed shape with sources. It does not see the whole task, the other subtasks or the other workers' results; what it sees is what it will be distracted by. A worker that lacks context must say so rather than guess.

The synthesis prompt receives every result with its subtask id and the original task. It is where contradictions surface, so it is told how to resolve them: prefer the result with the stronger source, flag the conflict, or send the pair back for one more round.

Context down, results up

The orchestrator passes context down by selection, not by broadcast: each worker gets a slice. Results travel up in a fixed shape with provenance, so the synthesis can weigh them. Facts the workers need in common, the reporting period, definitions, the audience, are stated once by the orchestrator and copied into every worker prompt, because a worker that does not know the period will pick its own.

Orchestrator: plan, assignWorker: pricingWorker: churnWorker: marketsubtasks downone slice eachSynthesis: merge, resolveresults upcost: 1 plan + n workers + 1 merge; each worker sees only its slice
The orchestrator emits a plan; each worker gets one subtask and its slice of context; results flow into a synthesis step that is told how to handle conflict.

Cost

One orchestrator call, n worker calls, one synthesis call. The workers dominate: eight workers at 3,000 input tokens each is 24,000 tokens, before the orchestrator's 5,000 and a synthesis that reads all eight results, perhaps 10,000. Against one large call the token count is two to four times higher, but each call is small enough to evaluate alone. Latency is the orchestrator plus the slowest worker plus the synthesis, since workers run in parallel.

Failure modes

Over-decomposition. Twenty subtasks for a task that needed three; cost grows and the merge has more to reconcile. Cap subtasks in the schema and in the code. Workers lacking context. A worker without the shared facts answers a slightly different question; its result looks fine alone and conflicts in the merge. Merge conflicts. Two workers return incompatible numbers and the synthesis picks one silently. Make conflict a first-class output, with a rule or a flag. Runaway rounds. If the synthesis can ask for more work, bound the rounds, or it becomes an agent without the design of one.

 Orchestrator-workersParallel sectioningSingle agent
Subtasks known in advanceNo; a model plans them per requestYes; the split is in the codeNo; decided step by step in a loop
CostPlan plus n workers plus merge; variablen calls plus merge; predictableHighest and least predictable
Quality on complex tasksHigh when the plan is good and context flowsLimited to what the fixed split foresawHighest ceiling; widest variance
ControlCode caps workers and rounds; plan is inspectableFullLowest; the model decides what happens next
Orchestrator-workers · Backplane