Orchestration Patterns: Chains, Routers and Orchestrator-Workers

Anthropic's guidance on building agents draws a sharp line between workflows, where your code decides the sequence of model calls, and agents, where the model decides. Most production systems are workflows, and the exam expects you to choose the least autonomous pattern that solves the problem. This lesson covers the five composable workflow patterns and the point at which a true agent becomes justified.

The building block

Every pattern composes the same unit: a single Messages API call augmented with tools, retrieval or memory. Get that unit right first. A well-prompted single call with good tool descriptions often removes the need for orchestration at all. Add structure only when a measured failure demands it.

Prompt chaining

A chain runs a fixed sequence of calls, each consuming the previous output. Between steps your code can run deterministic checks ("gates"): validate JSON, confirm a word count, run a linter. Chaining trades latency for accuracy by giving each call one job.

outline = ask("Write an outline for a report on {topic}")
assert outline.count("\n") >= 5          # programmatic gate
draft = ask(f"Expand this outline into prose:\n{outline}")
summary = ask(f"Summarise in 3 bullets:\n{draft}")

Use chaining when the task decomposes cleanly into known steps and the order never changes.

Routing

A router classifies the input, then dispatches it to a specialised prompt, tool set or model. The classifier is itself a cheap model call, often with a structured output so that the decision is machine-readable. Routing lets you tune each branch independently: a refund request and a technical bug report need different system prompts, and a simple FAQ can go to a smaller, cheaper model while a hard case goes to the most capable one.

Routing is the right pattern when inputs fall into distinct categories that are easy to classify and hard to serve with one prompt.

Parallelisation

Two flavours exist. Sectioning splits a task into independent subtasks that run concurrently (review a pull request for security, performance and style in three parallel calls, then merge). Voting runs the same task several times and aggregates (three independent classifications, majority wins). Parallel calls cut latency and let each call focus, at the cost of more tokens. Only parallelise when the subtasks genuinely do not depend on one another.

Orchestrator-workers

Here a central model call reads the task, decides dynamically which subtasks are needed, delegates each to a worker call, and synthesises the results. The difference from parallelisation is that the subtasks are not known in advance; the orchestrator invents them from the input. A coding task that touches an unknown number of files is the canonical example. In Claude Code this pattern is literally the Agent tool: the main session is the orchestrator and subagents are the workers.

Evaluator-optimizer

One call produces a candidate; a second call evaluates it against explicit criteria and returns feedback; the loop repeats until the evaluator passes it or a budget is exhausted. This works when you can articulate what "good" means and iterative critique measurably improves results, such as translation quality or code that must pass a test suite. Without clear criteria the evaluator just adds cost.

When an agent is justified

An agent is a loop in which Claude chooses tools and the next step until it judges the task complete. Choose it only when all four conditions hold: the task is open-ended and hard to specify as steps; the value justifies the extra cost and latency; Claude is demonstrably capable at the task type; and errors can be caught (tests, review, rollback). If any answer is no, stay with a workflow. Agents need sandboxing, iteration limits and human checkpoints because their trajectory is not fixed in advance.

Pattern	Who decides the steps	Typical trigger
Chaining	Your code, fixed	Clear sequential steps
Routing	Classifier call, then your code	Distinct input categories
Parallelisation	Your code, concurrent	Independent subtasks or need for consensus
Orchestrator-workers	A model call, dynamically	Unknown number or shape of subtasks
Evaluator-optimizer	A model call judges, your code loops	Measurable quality criteria
Agent	The model throughout	Open-ended tasks with recoverable errors

Exam focus

• Workflows have code-defined control flow; agents have model-defined control flow. Prefer workflows until a measured failure demands more autonomy.
• Chaining is a fixed sequence with optional programmatic gates; orchestrator-workers decides subtasks at run time.
• Routing requires a classification step first, and lets each branch use a different prompt or model.
• Parallelisation is only valid when subtasks are independent; voting is parallelisation for consensus.
• Evaluator-optimizer needs explicit, checkable quality criteria or it merely adds cost.
• The four agent criteria are complexity, value, viability and recoverable cost of error.