Orchestrator-workers

In orchestrator-workers a central model reads the task, decides what subtasks it needs, hands each one to a worker, and assembles the results. The difference from parallelization is that the subtasks are not known in advance. The orchestrator works them out from the input, which is what makes this a pattern for open-ended problems.

I reach for it when I cannot predict the shape of the work. A change that touches an unknown number of files, or a research question where the sources to consult depend on what the first pass turns up, both want an orchestrator. If I could list the subtasks ahead of time, I would use a chain or a parallel fan-out instead.

The cost is that the orchestrator is now a planner, and planning is where models are least reliable. It can over-decompose, under-decompose, or hand a worker a subtask with too little context to do it well. Every worker call is a separate context window, so the orchestrator has to be explicit about what each one needs to know.

It goes wrong when the orchestrator and the workers disagree about what done looks like. A worker returns something plausible, the orchestrator accepts it without checking, and the assembled result is confidently wrong in a way no single call would have been. The synthesis step is where I have seen the most quiet failures.

In a good one I look for a worker interface that is narrow and typed, so the orchestrator cannot hand over ambiguous work, and for the orchestrator's plan to be logged as a first-class artifact I can read afterwards. If I cannot see the plan, I cannot tell whether a bad result came from bad planning or bad execution.