Parallelization works when you know how to split the task in advance. But sometimes the split itself depends on the input — which files to touch, which sources to consult. Enter the orchestrator–workers pattern: a lead LLM analyzes the task, decides the subtasks, and delegates each one to a worker call.

The analogy

The site foreman. On a renovation, the foreman inspects, then decides: “plumber in the bathroom, electrician in the kitchen, painter upstairs.” Each tradesperson works with their own toolbox, then reports back. The foreman never holds a paintbrush — their job is decomposition, dispatch and final inspection.

The principle

flowchart TB
    O["LLM: orchestrator — plan & delegate"] --> W1[worker 1] & W2[worker 2] & W3[worker 3] --> M["orchestrator: merge & check"]
  • The orchestrator sees the big picture; it writes precise briefs for the workers.
  • Each worker runs in a fresh context with only its brief — no pollution from the others, full context window for its own subtask.
  • Unlike fixed parallelization, the subtasks are decided at runtime, per input.

A concrete example

“Rename this concept across our codebase”:

orchestrator → scans repo structure
             → "worker 1: update /api (7 files)"
             → "worker 2: update /web (12 files)"
             → "worker 3: update docs + changelog"
workers      → each edits its own zone, reports a summary
orchestrator → reviews reports, checks consistency, done

The full codebase would drown one context; each worker only ever sees its slice.

When to use it

  • The decomposition can’t be hardcoded — it depends on each input.
  • The task is too big for one context and splits into self-contained chunks.
  • Subtasks need different tools or focus (research vs. writing vs. checking).

When to avoid it

  • The task fits comfortably in one call — an orchestrator is pure overhead then.
  • Subtasks are tightly interleaved: workers can’t share discoveries mid-flight; the design only works if the briefs are truly separable.

The classic trap

Vague briefs. A worker only knows what the orchestrator writes in its instruction — “fix the API part” produces chaos, “rename X to Y in these 7 files, don’t touch the tests” produces results. The foreman’s real skill is writing good work orders.