The five patterns

Most agentic systems are assembled from a handful of recurring shapes. Learn these five and you'll recognize the building blocks in almost any design — and, just as useful, you'll see which shapes are really workflows that need no agent at all.

1. Prompt chaining. Break a task into fixed steps, each feeding the next: draft, then critique, then revise. When to use: the task decomposes cleanly into stages you can define in advance.

2. Routing. Classify the input first, then send it down the right branch — a cheap model for simple cases, an expensive one for hard cases; billing questions one way, technical questions another. When to use: inputs fall into distinct kinds that each deserve different handling.

3. Parallelization. Run several calls at once and combine them — either splitting a job into independent pieces, or asking the same question multiple times and voting. When to use: subtasks don't depend on each other, or you want multiple looks for reliability.

4. Orchestrator / workers. One model breaks a task into subtasks on the fly and hands each to a worker, then assembles the results. Unlike prompt chaining, the subtasks aren't fixed in advance. When to use: you can't predict how many pieces the task splits into until you see it.

5. Evaluator / optimizer. One model produces, another scores it against a rubric and sends feedback, and the first revises — looping until the score is good enough. When to use: you have a clear quality bar and output genuinely improves with iteration.

A plain-words picture of the last one, because it matters most for reliability:

generator -> output -> evaluator -> "good enough?"
                            no -> feedback -> generator (try again)
                            yes -> done

Two honest observations. First, the first three patterns — chaining, routing, parallelization — are really workflows. The path is fixed; the model fills in steps. That's a feature. They're the most predictable, cheapest, and easiest to test, so prefer them. Only orchestrator/workers lets the model decide the structure at runtime, and that flexibility is exactly what costs you predictability.

Second, the evaluator/optimizer pattern is the golden rule wearing a pattern's clothes. "A second thing checks the first thing's work" is just verification built into the design. Any time you catch yourself trusting a single model call to be correct, ask whether an evaluator belongs there. The evaluator can be a test suite, a linter, a rule, or another model — but something external should hold the quality bar, because the generator can't judge itself.

You'll rarely use one pattern alone. A real system might route inputs, chain a few steps on each branch, and wrap the risky step in an evaluator loop. Compose them like Lego — and keep the agentic pieces as small as the problem allows.