Wiki
Core11 min read

Orchestrator and workers

A lead decomposes the goal, fans subtasks out to workers with fresh contexts, and merges the results — a latency win, not a cost win.

The workhorse multi-agent pattern is orchestrator–worker: one lead agent decomposes the goal, dispatches each subtask to a worker with its own context, then merges what comes back. It is the planning chapter's decomposition, executed across several windows instead of one — and it is the pattern behind most systems that call themselves multi-agent and actually work.

Start here

The lead's job is not to do the work — it is to decide what the work is, hand out pieces small enough for a fresh context, and stitch the answers together. Workers never see each other's noise; the lead never sees each worker's raw context. That isolation is the whole point.

One lead, 3 workers — parallel or sequential

lead: decompose the goal (2u)
worker 1: subtask (3u)
worker 2: subtask (3u)
worker 3: subtask (3u)
lead: merge results (1u)

wall-clock

6u

model calls

3

Parallelism is a latency win, not a cost win: the workers still run once each, you just stop waiting for them one after another. Add a worker only when a subtask genuinely needs its own context — every extra worker adds a call, a result to merge, and a chance for the lead to misread it. Durations are illustrative.

Add workers and toggle parallel execution: the wall-clock time drops, the model-call count does not.

The shape

  1. Decompose — the lead turns the goal into independent subtasks (planning again, now with a worker per piece).
  2. Dispatch — each subtask goes to a worker with a focused prompt and only the context it needs.
  3. Merge — the lead combines the returns into one result, resolving overlaps and conflicts.

Why it works

  • Context isolation — a worker's 50-page read becomes a paragraph in the lead's window.
  • Parallelism — independent subtasks run concurrently, so wall-clock time tracks the slowest worker, not the sum.
  • Focused prompts — a worker that only routes tickets is easier to get right than one agent doing everything.

Careful

Parallelism buys latency, not money: every worker is a full model call, so N workers cost ~N× regardless of how fast they finish. The merge step is also a new failure point — the lead can misread a worker's result or silently drop one. Keep subtasks genuinely independent; workers that need each other's output are a sign the split was wrong.

Check yourself

Eduspheria wiki · Agentic AI, Multi-agent & orchestration

0 / 4 answered

  1. 1In the orchestrator-worker pattern, what does the lead agent do?
    Multiple choice
  2. 2Parallel workers reduce the total model-call cost.
    True / false
  3. 3What multi-agent role executes each subtask with its own focused context?
    Short answer
  4. 4Which is a new failure point introduced by the merge step?
    Multiple choice

Next: routing before you even reach the expensive agent.