Introduction
The Five Workflow Patterns
Coinbase's Claude-powered customer support system operates under real financial-compliance guardrails — a wrong or non-compliant response has actual regulatory consequences, not just an unhappy customer. A system like this doesn't use one workflow shape for everything; a support message needs to be classified and dispatched to the right handling path, a written response may benefit from being drafted then checked against compliance rules before it ships, and some categories of question may need to be answered by combining several independent checks run at once. Five named patterns cover the overwhelming majority of workflow-shaped orchestration needs, and picking the wrong one for a given task doesn't make it impossible — it just makes the implementation awkward, slower, or more expensive than the shape the task actually has.
Choosing among the five isn't about picking a favorite and forcing every task into it — that's the same mistake as defaulting to "just build an agent" from the previous lesson, one level down. Each pattern exists because it captures a specific, recurring shape that real workflow-appropriate tasks actually take. Recognizing which shape a task has, before writing any orchestration code, is what determines whether the resulting system is a clean fit or an awkward one bent to accommodate the wrong structure.
The five patterns
Prompt chaining decomposes a task into an ordered sequence of steps where each step's output feeds the next — generate an outline, then a draft from the outline, then a critique of the draft. This fits when a task naturally breaks into stages that benefit from focused attention one at a time, rather than trying to do everything in one pass.
Routing classifies an input and dispatches it down one of several fixed, predetermined paths based on that classification — a simple query goes to a fast, cheap handling path; a complex one goes to a more thorough path. The paths themselves are decided in advance by the engineer; only which path a given input takes is decided at runtime.
Parallelization runs multiple independent instances of a task concurrently, in one of two forms: sectioning (splitting a larger task into independent pieces run at once, like analyzing several documents in parallel) or voting (running the identical task multiple times with variation and aggregating the results for higher confidence than any single run).
Orchestrator-workers uses a central orchestrating call to dynamically determine what subtasks are needed for a given input — unlike routing, where the paths are fixed in advance, here the set of subtasks itself is decided at runtime based on what the specific input actually requires, then delegated to worker calls.
Evaluator-optimizer pairs a generating step with an independent evaluating step that checks the output against explicit criteria — if it fails, the generator gets specific feedback and tries again, looping until the evaluator is satisfied or a retry limit is hit. This is the workflow-pattern version of the generator/validator diversity principle from c12-00-4, formalized into an explicit loop.
Routing versus orchestrator-workers — the distinction that gets confused most
Routing picks among paths the engineer already defined; the classification decides which pre-built path runs, but the paths themselves don't change. Orchestrator-workers decides the actual list of subtasks at runtime — for one input it might dispatch two workers, for another input five, in an order and combination nobody wrote down in advance. If the set of possible "paths" is fixed and small, it's routing. If the subtasks themselves vary by input, it's orchestrator-workers.
A compliance-review feature needs to check a draft customer response against five independent regulatory rules (data privacy language, financial-advice disclaimers, discriminatory-language screening, accuracy of stated fees, required disclosures) and can check all five simultaneously since they don't depend on each other. Which workflow pattern fits, and why?
The defining feature here is independence: none of the five checks needs another's result to run, and they're a fixed, known set for every response (not dynamically determined per input, which would suggest orchestrator-workers). That combination — a fixed set of independent subtasks executed concurrently — is exactly parallelization via sectioning, not routing (which dispatches to one path, not five simultaneous ones) or prompt chaining (which is sequential).
A support-ticket handler needs to draft a response, then have a second, independent check confirm the response doesn't violate any compliance rule before it's sent — regenerating with specific feedback if it does, up to 3 attempts. Which pattern is this, and how does it differ from prompt chaining?
The defining feature is the loop: evaluator-optimizer specifically pairs generation with independent evaluation that can reject the output and send it back with feedback for another attempt. Prompt chaining is purely forward-flowing — outline to draft to critique — with no step ever sending work backward for revision, which is exactly what distinguishes it from evaluator-optimizer's retry loop.