Which Agent Workflow Pattern Should You Use? Anthropic's 5 Patterns Compared

Anthropic's "Building Effective Agents" post names five workflow patterns, and most summaries of it just list the five names in a row. That leaves the two questions people actually search for unanswered: which pattern fits this task, and what's the real difference between the two that get confused constantly — parallelization and orchestrator-workers. Both patterns fan a task out across several LLM calls and combine the results, so from a distance they look identical. The difference is whether you can write down the subtasks before the model ever runs.

Start here: is the task's shape fixed or input-dependent?

Prompt chaining: a fixed sequence, each step feeding the next

Prompt chaining decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one. It fits whenever the task "can be easily and cleanly decomposed into fixed subtasks" — you already know the steps before writing any code.

Worked example: a team wants a product-announcement email translated into French, German, and Japanese. Call 1 drafts the English copy. A cheap check — code or a second call — then confirms the draft mentions the price, release date, and headline feature before any translation happens. Only if that gate passes do calls 3–5 each translate the approved draft into one target language; if it fails, the draft goes back for a rewrite instead of translating broken copy three times over. The step count is fixed every run: 1 draft + 1 gate + 3 translations = 5 calls, in that exact order.

Use prompt chaining when latency is an acceptable trade for accuracy on a well-understood pipeline. It is the wrong tool once the number or order of steps can't be known ahead of time — that's a sign you need orchestrator-workers instead.

Routing: classify once, then specialize

Routing classifies an input and directs it to a specialized follow-up prompt, for tasks with "distinct categories that are better handled separately."

Worked example: a support inbox gets billing questions, technical-support questions, and general inquiries. Rather than one giant prompt trying to handle all three well, a single cheap classification call reads the incoming message and picks one of the three categories, then hands it to a prompt written and tuned specifically for that category — the billing prompt knows about refund policy, the technical prompt knows about the product's error codes, and neither has to carry the other's instructions. The same pattern routes by difficulty instead of topic: a lightweight router sends simple lookups to a small, cheap model and only forwards genuinely hard requests to a large, expensive one.

Routing earns its keep when an LLM (or even a traditional classifier) can categorize accurately and the categories genuinely need different handling. If every category ends up needing the same prompt anyway, the classification step is pure overhead.

Parallelization: fixed, independent pieces run at the same time

Parallelization runs several LLM calls simultaneously on a task, then combines their outputs programmatically. Anthropic describes two variations, and the worked examples below show why each exists.

Sectioning splits one task into independent pieces that are all known in advance. A 300-page manual is split into 10 chapters; 10 calls translate one chapter each at the same time; the results are concatenated in order. Running the chapters one after another takes roughly 10× the time of one chapter; running them in parallel compresses that down to roughly one chapter's worth, since chapter 7 never depends on chapter 3's translation.

Voting runs the same task multiple times for diverse outputs, then aggregates by agreement. Three independent calls review one pull request for security bugs: call A flags a SQL-injection risk and an XSS issue; call B flags only the SQL-injection risk; call C flags the SQL-injection risk plus an unrelated false positive about rate limiting. With a "flag if at least 2 of 3 agree" threshold, the SQL-injection finding survives (3/3) while the other two are dropped (1/3 each) — the disagreement is itself the signal that those two are noise.

What both variations share, and what separates them from the next pattern: the set of subtasks (10 chapters, or "run this exact review 3 times") is decided by a human before the run starts, not by a model reacting to that specific input.

Orchestrator-workers: the subtasks are decided per input, not predefined

A central "orchestrator" LLM dynamically breaks a task into subtasks, delegates each one to a worker LLM, and synthesizes the results — with the number and nature of those subtasks determined by the orchestrator at run time, not fixed in the code beforehand.

Worked example: a coding agent is asked to rename a widely-used function across a codebase. Nobody can say in advance how many files reference it — 3, or 40. The orchestrator reads the repository, finds (say) 4 files that actually call the function, and dispatches one worker call per file with that file's specific edit; once the 4 workers return, the orchestrator combines their edits into a single patch. Compare this to the manual-translation example above: there, "10 chapters" was known before any model ran. Here, "4 files" is only knowable after the orchestrator looks at this specific repository — a different function might touch 2 files, or 15.

That's the distinction worth memorizing: if you could write the subtask list in a config file today, it's parallelization; if the orchestrator has to inspect the input to discover that list, it's orchestrator-workers. The extra planning call only earns its keep when subtasks genuinely can't be predicted in advance.

Evaluator-optimizer: generate, critique, revise, loop

One LLM call generates a response while a separate LLM call evaluates it and gives feedback, looping until the evaluator is satisfied — used when there are clear evaluation criteria and iterating demonstrably improves the result.

Worked example: a literary translation tool drafts a translation (generator call 1); an evaluator call reads it against the source for tone and idiom, flagging that one phrase was translated literally and now reads unnatural. The generator revises just that phrase (call 2); the evaluator checks again and approves. Total cost: 2 generator + 2 evaluator calls, versus 1 call for a one-shot translation — the extra calls bought a translation that reads naturally rather than merely literally correct.

This pattern only pays off when the LLM can actually give useful feedback on its own domain (translation nuance, code review against a style guide, structured-data validation). If there's no reliable way to judge "better," there's nothing for the evaluator to loop on.

Workflows vs. agents: when to stop composing patterns and hand over control

All five patterns above are workflows: LLMs and tools orchestrated through predefined code paths, chosen because the task's shape is knowable ahead of time even when (as with orchestrator-workers) the exact subtask count is not. An agent, by contrast, lets the model dynamically direct its own process and tool usage with no predefined path — for genuinely open-ended problems where the step count can't be bounded in advance, at the cost of less predictability and a real risk of compounding errors over a long run.

The practical rule: start with the simplest option that could work — often one well-prompted call with retrieval and a few in-context examples — and move down this list only when that proves insufficient. Reserve a full autonomous agent for tasks where not even orchestrator-workers can bound the shape of the work in advance.

Putting it together

Ask, in order: is the sequence of steps fixed? → prompt chaining. Does the input just need sorting into one of a few categories? → routing. Can you list the independent pieces today? → parallelization (sectioning for speed, voting for confidence). Do the subtasks only reveal themselves once you've looked at this specific input? → orchestrator-workers. Is there a clear way to judge quality, with iteration demonstrably helping? → evaluator-optimizer, possibly layered on top of any of the above. Only once none of these fit — because the number and shape of steps are themselves unknowable in advance — does a full autonomous agent become the right tool.

For more on how these patterns combine with tool-use design, multi-agent handoffs, and production agent evaluation, try the AI agents & tool use practice quiz.

Source: Anthropic, "Building Effective Agents" (anthropic.com/engineering/building-effective-agents).

Drill AI Agents & Tool Use practice questions →