Orchestration Patterns: Chaining, Routing, Parallelization

The core workflow patterns from Anthropic's agent-building guidance and when each one is the right tool for a task.

Not every agentic task needs a full autonomous agent loop. Anthropic's guidance on building effective agents draws a useful line between workflows, where the control flow is defined by your code, and agents, where the model decides its own path through a task. Three workflow patterns cover most of the ground: prompt chaining, routing, and parallelization. Knowing which one fits a given scenario — and being able to say why the alternatives are worse — is a recurring exam theme.

Prompt chaining

Prompt chaining is a fixed sequence of LLM calls where each step's output becomes the next step's input. It's the workflow equivalent of a Unix pipe. You use it when a task decomposes into an ordered set of subtasks that are known in advance and where each stage benefits from focused, narrower attention rather than asking one call to do everything at once. A classic example is generate an outline, then expand the outline into a draft, then edit the draft for tone — three calls, each one refining the last, in a sequence that doesn't change based on the input.

The key property of prompt chaining is predictability: you know at design time exactly how many steps there are and what order they run in. If you find yourself needing to skip steps conditionally based on intermediate results, you've drifted from pure chaining toward routing or a more agentic design.

Routing

Routing classifies the input first, then sends it down one of several specialized downstream paths. Each path can have its own prompt, its own tools, even its own model. Use routing when your inputs fall into genuinely distinct categories that benefit from separate handling — a customer support system routing billing questions to one prompt and technical issues to another is the textbook case. The classification step itself is usually a small, cheap call (or even a simple classifier) whose only job is picking a lane.

The failure mode to watch for is applying routing when categories aren't actually distinct enough to need separate handling — in that case you've added a classification step and a maintenance burden for no real gain over a single well-written prompt.

Parallelization

Parallelization runs multiple LLM calls at once and comes in two flavors. Sectioning splits a task into independent subtasks that are dispatched simultaneously and then combined — for example, reviewing different sections of a large codebase for different concern types (security, performance, style) at the same time. Voting runs the same task multiple times, often with varied prompts or sampling, and aggregates the results for consensus — useful when you want higher confidence on a judgment call than a single pass reliably gives you, such as flagging whether content violates a policy.

Sectioning buys you speed and focus; voting buys you reliability at the cost of extra calls. The exam will expect you to distinguish "split the work" from "repeat the work for confidence" as two different reasons to reach for parallelization.

Scenario: A team wants to build a pipeline that takes a support ticket, determines whether it's a billing, technical, or account-access issue, and then handles each category with a very different tone and tool set. This is routing: the categories are genuinely distinct, known in advance, and each needs specialized handling. It is not prompt chaining, because there's no fixed sequence of transformations applied uniformly to every ticket — the path itself changes based on the input.

Try it

Pick a task you'd normally do in a single long prompt — say, "summarize this article and translate the summary into three languages." Rebuild it as an explicit prompt chain (summarize, then three parallel translation calls) using the Claude API directly, with each step's output logged. Compare the reliability and clarity of the output against the single-call version.