Orchestrator-workers
When you cannot list the steps in advance
In parallelization, you decide the parts before running. Sometimes the parts depend on the input: a change request might touch two files or twelve.
An orchestrator model reads the task, decides the subtasks, and sends each one to a worker. It then combines what the workers return.
1. The orchestrator plans
- Orchestrator plansFinds five files that need changes
- Workers editOne worker per file, in parallel
- Results returnEach worker reports its change
- Orchestrator combinesChecks consistency and summarizes
Ask for the plan as structured output: a list of subtasks with clear inputs. You can validate the plan before any worker starts.
2. Give each worker a narrow job
A worker gets one subtask and only the context it needs. Small, focused instructions are easier to check than one large request.
3. Check the combined result
Workers do not see each other’s output. The orchestrator, or a separate check, should look for conflicts and gaps before the result is used.
4. Set limits
Limit how many subtasks the orchestrator may create and how much each one may cost. A bad plan should fail early, not start fifty workers.
When is it useful?
For complex tasks where the subtasks cannot be predicted, such as changes across many files or research across many sources. If the steps are always the same, a fixed chain is simpler.