Years of teaching Java taught me that the hardest thing to give a junior engineer is not a technique. It is a word. I would watch someone write a tangle of conditionals that swapped behaviour at runtime, and the code was not wrong, it just had no name, so nobody could talk about it. Then one afternoon I would say "that is a Strategy," and something changed in the room. The tangle became a thing with edges. Two engineers could now mean the same shape when they said the same word. That is the entire quiet power of a design pattern, and the agent loop was overdue for a vocabulary of its own.
An agentic pattern is really a design pattern for the loop: a named, reusable move you already reach for by instinct, written down so a team can name it, choose it on purpose, and know when not to.
- Why the Gang of Four gave software its most durable gift by naming things engineers already built, and how the agent era just repeated the trick.
- The core catalogue - reflection, planning, routing, delegation, tool use - each as what it solves, its shape, and when it is overkill.
- The line where a pattern stops and a fleet begins, and why naming a move is worth more than any framework that ships it.
This dive is a change of register on purpose. The loop dive was mechanics; the memory dive was storage. This one is about words, not wiring: the vocabulary a team uses to reason about what its agents do. The loop is the given here. These are the moves you make with it.
Patterns Are Vocabulary, Not Machinery
In 1994, four authors, remembered ever since as the Gang of Four, wrote down twenty-three solutions that working programmers were already using without names. They did not invent Strategy or Observer or Factory; engineers had been building those shapes for years. What the book invented was the sentence that lets two engineers mean the same thing. The value was never new code. It was a shared language, and a shared language is what turns a pile of individual cleverness into a craft a team can practise together.
Agentic patterns are that same move, one abstraction layer up. Nobody invented reflection or planning; people were bolting self-review and task decomposition onto their agents ad hoc the moment agents could loop. Naming them does the 1994 thing again: it lets someone say "add a reflection pass here" or "route this one" and be understood exactly, without drawing the diagram. Everything below is a catalogue in that spirit. It is not a list of features to install. It is a vocabulary to think in.
The Catalogue
Five moves cover most of what you will build, and each is worth holding as problem it solves, shape, and the zone where it is overkill, because a pattern used where it is not needed is not sophistication. It is a tax you pay to look careful.
Reflection
The model critiques its own output against a standard, then revises. A second pass that catches what the first missed.
Planning
Decompose a goal into an ordered set of sub-tasks before acting, so the loop follows a plan instead of improvising each turn.
Routing
Classify the request, then dispatch it to the right handler, model, or tool. The switch statement of the agent world, made semantic.
Orchestrator-worker
A controller breaks work into pieces and hands each to a worker, then gathers the results. Delegation, under one roof.
Tool use
Reason about which action is needed, call it through a contract, read the result, continue. The spine most agents run on.
Evaluator-optimizer
One role generates, another scores against a rubric, and the loop repeats until the score clears the bar. Reflection with a separate judge.
Reflection leans on the same self-critique asymmetry that the evals dive built its judges on, verifying being easier than generating. But note the difference so the two never blur: an eval measures the system from outside; reflection is a step inside the loop. One is the grade; the other is a move the agent makes.
One Controller, or Many Agents?
Orchestrator-worker is where readers most often get lost, because the same words describe two very different things. Here is the line, and it is worth holding sharply.
You Have Named Moves Before
If the catalogue felt familiar, it should. The agentic patterns map almost one to one onto the object-oriented patterns a working engineer already carries, because they are solving the same shapes of problem in a new medium.
When a Pattern Is the Wrong Tool
The discipline that keeps a catalogue from becoming a hype list is knowing every pattern's overkill zone, and reaching for the simplest thing that works. Reflection on a task with one verifiable answer is a tax you pay to look careful. A planner for a two-step job is ceremony. A router with one real branch is a switch statement wearing a costume. The governing instinct is the Route's own, and the industry's best current guidance agrees: start simple, and add agentic structure only when a real, repeated failure proves the simpler thing is not enough. A framework is a box of patterns someone else already chose for you. Learn the patterns and you can put the box down.
A Vocabulary the Team Can Share
The prize was never the patterns. It is the shared language they create. A team that can say "add a reflection pass," "route this," "give it a planner," and have every member picture the same shape, ships faster and argues less, because the argument about what to build is already half-settled by the words. The Gang of Four knew this in 1994. The agent loop just earned its own edition. Learn the names, and you stop describing your agents and start designing them.
These moves all live under one controller. What happens when the workers become agents in their own right? The Fleet Is a Distributed System takes the orchestrator-worker line across into genuine multi-agent territory. Or step back onto the Route at Stage 04.