If the last five articles gave you the ingredients of an agent (the loop, tools, memory, planning), this one is about the recipes. Because after several years of teams building agents in real production settings, a handful of recognisable shapes have emerged. They’re not new inventions each time; they’re the same handful of patterns, adapted to different problems. Knowing them well is what separates someone who reinvents agent architecture from scratch every time from someone who reaches for the right pattern and gets to a working system in a fraction of the time.
This article covers the four patterns that come up most often, when to use each, how they combine, and a few honest observations about when not to use them. It’s the last article of the foundations block. After this, we roll up our sleeves and build.
Why patterns matter here
You already know patterns matter from the Prompt Engineering track (article 5 there covered “the seven prompt patterns that cover 90% of cases”). The same idea applies to agents, and for the same reason: most of the time, someone smart has already solved a version of your problem, and the pattern they used is the sensible starting point.
Chasing “novel agent architectures” is romantic but usually a mistake. Boring is good. Boring is reliable. Boring is what ships. Reach for the pattern that fits, adapt it to your case, and add novelty only when the fit genuinely isn’t there.
The four patterns worth knowing
Figure 1 shows the four, and then I’ll walk through each with an honest sense of when it’s the right choice.
Figure 1: The four patterns that cover the vast majority of real-world agent designs. Reflection improves quality by reviewing work. Tool use is the workhorse. Planning enables complex tasks. Multi-agent collaboration handles genuine specialisation. Most real systems combine two or three of these.
Pattern 1: Reflection
Reflection is the pattern of having the agent (or a second model call) review its own work and improve it. You’ve met this one already: after the agent produces an answer, it takes another pass to critique it, and then either accepts it or revises it. Loop until the answer is good enough or a limit is reached.
The classic version: agent produces a draft, agent reviews the draft against clear criteria, agent revises. Two or three passes of this often produce dramatically better output than one shot. This is closely related to the “reflection” beat we introduced in the planning article, but here it’s a dedicated pattern rather than just a checkpoint.
When to use it. Any task where the quality of the output matters more than the speed, and where the model can genuinely tell good from mediocre. Writing tasks (drafts and revisions). Code generation (write, then find bugs). Analysis (draft, then question your own conclusions).
When to skip it. Simple lookups. Anything where the agent produces something you’re going to verify anyway. Tasks where speed matters and the first-shot quality is already good enough.
The trap. Reflection can also degrade output if the reviewer is more paranoid than the writer. An over-critical review pass can rewrite a good answer into a hedge-y, waffly one. Prompt the reviewer to look for specific issues (accuracy, completeness, tone), not to just “improve” freely.
Pattern 2: Tool use
Tool use is the pattern we’ve spent all of article 4 on, so I’ll be brief. The pattern is: give the agent a well-scoped set of tools and let it call them as needed. Every serious agent uses this to some degree, because it’s the thing that makes an agent an agent.
When to use it. Whenever the task requires taking action or fetching information the model doesn’t have. This is essentially always in real agents.
When to skip it. Never, for real agents. This isn’t really an optional pattern; it’s the definition of one.
The trap. Giving too many tools, or poorly-described ones. Both make the agent worse. Fewer, sharper, better-described tools almost always win.
Pattern 3: Planning
Planning is the pattern from the last article: the agent produces a plan of the whole task before executing it, and reflects on the plan as it goes. This is what lets an agent handle tasks with genuine complexity, where “just call the next tool” isn’t enough.
When to use it. Anything longer than about five steps. Anything where the order of steps matters. Anything where the agent needs to keep an overall goal in mind while working on sub-tasks.
When to skip it. Short tasks where the plan is obvious (weather-and-reminder from article 3 doesn’t need a plan). Also skip if the task is so genuinely uncertain that any upfront plan would just have to be thrown out; go straight to iterative planning instead.
The trap. Planning paralysis, as we discussed. Plans that are too long, too detailed, or triggered too often. Match the depth of planning to the depth of the task.
Pattern 4: Multi-agent collaboration
Multi-agent collaboration is the pattern where you have multiple agents working together, each with a specialised role. One writes, another critiques. One plans, another executes. One researches, another summarises. They pass work to each other and coordinate to solve the whole task.
When to use it. When the task genuinely has specialised roles, and giving one agent all of the roles would make it worse at each. Complex research tasks with distinct research/write/edit phases. Code projects with distinct build/test/review phases. Support flows with distinct triage/investigate/resolve phases.
When to skip it. Almost everywhere else. Multi-agent is exciting to design and often more expensive and harder to debug than a single well-designed agent. The number of teams who reach for multi-agent when a single agent with clear planning would have been better is genuinely alarming. Start single-agent by default. We’ll go deep on multi-agent in article 9, including a proper honest look at when it earns its keep.
The trap. Multi-agent systems get harder to debug much faster than single agents, because you now have to reason about coordination, communication, and multiple loops running in tandem. Only take on that complexity when it’s clearly buying you enough to justify it.
How the patterns combine
The interesting thing about these four is that they aren’t rival choices; they compose. Real systems typically combine two or three. Figure 2 shows a common combination.
Figure 2: Real agents stack patterns. A typical serious agent might use planning to decompose the task, tool use to execute steps, and reflection to review the final output. Multi-agent gets added only for the specific tasks that need it. The patterns compose naturally.
A real example, to make it concrete. Imagine a research agent that produces a market briefing:
- Planning breaks the task into the sub-tasks we saw in article 6.
- Tool use carries out each sub-task (search, look up, fetch, calculate).
- Reflection reviews the final briefing against a rubric (“is it accurate, complete, well-supported?”) and revises if needed.
Three of the four patterns, working together. The fourth (multi-agent) isn’t needed here because a single, well-designed agent with planning and reflection can handle the whole thing. Adding a second agent would introduce coordination overhead for no real gain.
The heuristic I’d offer: start with planning + tool use as the baseline for any serious agent. Add reflection when quality is the bottleneck. Add multi-agent only when the specialisation is genuinely there. In that order, and only as needed.
A few patterns that get called agent patterns but aren’t really
Because the discipline is young, plenty of things get called “agent patterns” that are really something else. A short honest list, so you can spot the marketing:
- “Chain-of-thought as a pattern.” Chain-of-thought is a prompting technique. It’s inside the planning and reflection patterns; it’s not a separate pattern.
- “RAG as an agent pattern.” RAG is a technique for grounding a model in retrieved data. It’s a tool the agent can call (which becomes “agentic RAG” when done well, and gets its own article coming up). But RAG on its own isn’t an agent pattern.
- “Structured output as an agent pattern.” Structured output is a prompting habit, essential in tool use but not a pattern in its own right.
- “Guardrails as an agent pattern.” Guardrails are a safety layer we covered in the LLMOps track. They wrap the agent; they’re not the agent’s architecture.
These are all genuinely useful techniques, and they show up inside good agent designs. But calling them “patterns” muddles the picture. The four core ones above are the ones that define agent shape. The others are ingredients that combine with the patterns.
Warning signs your pattern choice is wrong
A useful field guide, because pattern mismatch is a common cause of failure:
- Task feels linear, but you’re using multi-agent. Probably don’t need it. Try a single agent with planning first.
- Task is short and mechanical, but you’re using planning. Probably overkill. The plan is going to look identical every time; just make it a workflow.
- You’ve added reflection everywhere, and everything got slower without getting better. Reflection at every step is too much. Add it at natural checkpoints only.
- Your agent has ten different tools that overlap. You’ve likely got a tool-design problem masquerading as an architecture problem. Trim, sharpen, describe better.
- You’ve built a beautifully architected system that keeps failing on simple queries. You may have over-agentified. Check whether a workflow (or even a chatbot with RAG) would do a better job.
None of these are shameful. All of them are common. Being able to name them is how you fix them.
Foundations complete
Look back at what these seven articles have given you. You know what agents are, when to use them, how the loop works, how tools give them power, how memory extends them across time, how planning keeps them coherent on complex tasks, and now, the reusable shapes that fit together into real systems. That’s the whole conceptual foundation. If you understand these seven articles well, you understand agentic AI genuinely.
The next article puts all of this into action. We’re going to build a real, working agent from scratch. Not with a heavy framework, just enough code to see every part of what we’ve covered running for real. It’s the “aha” article of the track, where all the abstractions turn into something you could actually deploy. Let’s build.
Next in the series: Building Your First AI Agent (Hands-On), a working agent from scratch, no framework.