The Workflow Patterns You'll Actually Use
Before you reach for a full agent, there are five composable building blocks that solve most of the work. Knowing them is the difference between writing automation and reinventing it.
What changed›
- New chapter — added in the June 2026 restructure.
Once you've decided a task is a workflow, you don't start from scratch. Almost everything is one of five shapes — and most of what people build with agents is really these, composed.
Anthropic's Building Effective Agents names a small catalogue of patterns, and once you can see them you stop reinventing them. They're worth holding in your head as a set, because choosing the right one is most of the design:
The first three are pure workflow — fixed control flow you write. Routing earns its keep by separation of concerns: classify once, then send easy cases to a smaller, cheaper model and hard ones to a stronger one. Parallelization comes in two flavours — sectioning (independent subtasks running together for speed) and voting (the same task run several times, taking the majority for confidence). Master these and you'll reach for an agent far less often.
Orchestrator–workers, and the multi-agent temptation
The fourth pattern is the doorway to “multi-agent,” and it's where honesty matters most. An orchestrator — a lead model that decomposes a job and hands pieces to workers at runtime — is genuinely the right tool when you can't know the subtasks ahead of time, like a research task that fans out into however many threads the question turns out to need. But it's also the most over-reached idea in the field. Every extra agent multiplies cost, latency, and the number of ways things can go wrong. Reach for orchestration when the work truly can't be enumerated; treat “let's make it multi-agent” as a smell until then. Most problems that look like they need a team of agents need one good workflow.
Where it goes wrong
Skipping straight to orchestrator–workers because it sounds powerful, when a three-step prompt chain would have done it — now you're debugging a swarm. The other miss is the reverse: forcing genuinely open-ended work through a rigid chain with twenty branches. Match the pattern to the shape of the task, not to how advanced it feels.
Try this
Take an automation you're planning and name its pattern out loud before writing a line: is it a chain, a router, a parallel fan-out, an orchestrator, or a generate-and-critique loop? If two patterns fit, you've probably found a seam where the task splits into a small pipeline of them. Naming the shape first is how you build the simplest thing that works instead of the most impressive thing you can.
Grounded in Anthropic, Building Effective Agents (workflow patterns) and its multi-agent research-system writeup (when orchestration earns its cost).