Orchestrator-Worker Pattern
Ask one agent to migrate forty files and it loses the thread somewhere around file nine. Split the job so that one agent decides what needs doing and others each do a single piece, and it holds together. That division of labour is the orchestrator-worker pattern.
How the division works
The orchestrator — also called the lead or planner — never touches the work itself:
- It breaks the goal into subtasks and decides which of them can run at the same time.
- Each subtask goes to a worker with a fresh context holding only that piece: the one file to edit, the one question to research.
- Workers return results, not transcripts. The orchestrator synthesises them, and can spawn further work based on what came back — a source a search turned up, a test that still fails.
Why it matters
The gain is about context, not just parallelism. A worker that only ever sees one file is not distracted by the other thirty-nine, and its mistakes stay local instead of poisoning the whole run. Research agents are built this way — Anthropic's multi-agent research system is the canonical write-up — fanning subqueries out to workers while the lead writes the report.
Where it breaks
Everything rests on the orchestrator's task descriptions. Vague instructions produce two workers doing the same job, or a gap neither covered, and the lead cannot tell because it never saw the work. Token cost multiplies with the worker count, worker failures need a retry policy at the orchestrator, and a plan written before the first result arrived has to be allowed to change.
The orchestrator-worker pattern structures a multi-agent system around one coordinating agent that decomposes a goal into subtasks, dispatches each to a worker agent with its own fresh context, then synthesises the returned results. It keeps each worker's context narrow and its errors local, which is what makes long, wide jobs such as research sweeps and code migrations tractable. Its weak point is the orchestrator's task descriptions: vague ones produce duplicated or missing work.
Think of a building site. The foreman does not lay the bricks. They work out what needs doing, hand each task to the right tradesperson, and put the finished pieces together.
AI software can be organised the same way. One agent plays the foreman: it takes the big goal, splits it into separate jobs, and gives each job to its own helper, who knows nothing about the others and only has to do that one bit. The helpers report back, and the foreman assembles the final answer. This keeps every helper focused on one small task — which is exactly when this kind of software is at its most reliable.