Orchestrator-workers and evaluator-optimizer
The two patterns for work you cannot fully specify up front.
4 min read · Lesson 5 of 12 in this domain
The first three patterns all assume you know the steps when you write the code. These two are for when you do not. In orchestrator-workers a model looks at the specific input and decides what the subtasks are — you cannot enumerate them in advance because they depend on the input. In evaluator-optimizer you cannot specify the output in one shot, but you can recognise a good one, so you generate, critique, and revise. The cost of both is real: dynamic planning and extra loops burn tokens and latency, so they only earn their place when the work genuinely resists being specified up front.
- Orchestrator-workers — a central model decomposes the task dynamically and delegates to workers. Use when the subtasks cannot be predicted in advance. If you already know the steps, chaining is cheaper and more testable.
- Evaluator-optimizer — one call generates, another critiques against criteria, and the loop repeats. Use when you can articulate what "better" means clearly enough to act on.
- Vague criteria produce noisy evaluator loops that never converge. If you cannot state the bar concretely, this pattern will not help.
- A separate fresh-context verifier generally outperforms in-context self-critique, because self-critique inherits the assumptions that produced the error.
"Ask the model to double-check its own work" is offered as the reliability answer. Independent verification beats self-review.
When does orchestrator-workers beat prompt chaining?
If you already know the steps, chaining is cheaper, faster and easier to test.
What does evaluator-optimizer require to work?
Vague criteria produce noisy loops that never converge.
Practise this domain with 27%%-weighted questions in the study app.
Open in study appSource: Anthropic Engineering — Building effective agents · Independent study aid, not affiliated with or endorsed by Anthropic.