Agent design patterns
Most LLM systems that work in production are not one clever agent. They are a handful of well known shapes, wired together with ordinary code. Learn the shapes and you will recognise them inside every AI product you use, and you will stop reaching for a fully autonomous agent when a two step chain would do.
These five come from Anthropic's 2024 guide on building effective agents, and they have become a shared vocabulary. Each one is a workflow except the last two, which hand the model progressively more control.
A product turns a long PDF contract into a one page summary for a lawyer, flagging risky clauses. Sketch how you would split that into model calls. One big call, or several? In what order?
The five shapes#
Flip through them. Each has a concrete example in its note.
The building block underneath#
Every box above is the same unit: a model call with access to retrieval, tools and some memory. Anthropic calls it the augmented LLM. The patterns are just different ways of wiring those units together with code. That is good news, because it means most of the engineering is ordinary engineering: queues, retries, timeouts and tests.
Coding assistants are a stack of these patterns. Routing decides whether a request is a question or an edit. An orchestrator plans which files to change. Workers edit files in parallel. An evaluator loop runs the tests and feeds failures back. Almost nothing in that stack is a single autonomous agent doing everything in one context.
| Choice | What you gain | What you pay | Pick it when |
|---|---|---|---|
| Prompt chaining | Each step is simple, testable, and can be checked by code before the next. | Added latency from steps in sequence. A bad early step poisons the rest. | Tasks that split into clear, fixed stages. |
| Routing | Specialised prompts and tools per case, and cheaper models for easy cases. | A misrouted input gets the wrong handler, so the router needs its own eval. | Inputs that fall into distinct categories handled differently. |
| Parallelisation | Faster, and voting raises confidence on judgement calls. | More calls, so more cost, and merging conflicting results needs rules. | Independent subtasks, or decisions worth checking several times. |
| Orchestrator and workers | Handles tasks whose parts are only known at run time. | Unpredictable cost, and the orchestrator's plan is a single point of failure. | Large tasks with a variable number of parts. |
| Evaluator and optimiser | Measurably better output when the criteria are clear. | Several rounds of calls, and a judge that can be wrong in the same way as the writer. | Quality matters more than speed, and "good" can be written down. |
Checkpoint#
1. What separates orchestrator and workers from plain parallelisation?
2. Your evaluator and optimiser loop sometimes runs for 30 rounds. What is missing?
3. Why is routing often the cheapest pattern to add first?
- Five shapes: chaining, routing, parallelisation, orchestrator and workers, evaluator and optimiser.
- The first three are workflows. Your code fixes the path.
- Every loop gets a hard cap on rounds, enforced in code.
- Real products stack these patterns. Few are one big autonomous agent.
Most production LLM systems are a few standard shapes wired together with code. Prompt chaining splits a task into fixed steps with checks between them. Routing classifies an input and sends it to a specialised handler, which is also how you save money by sending easy cases to small models. Parallelisation runs independent calls at once, either different aspects or the same task several times for a vote. Orchestrator and workers lets a model decide the subtasks at run time. And evaluator and optimiser loops a generator against a judge until the output meets clear criteria. The first three are workflows I control. The last two give the model more control, so they get hard caps on rounds and cost.