10 Design Patterns for AI Agent Development
Note: this article is an English adaptation of a Japanese piece I wrote on Zenn. The English version was produced with AI assistance and edited for an English-speaking engineering audience.
1. Why design patterns, why now
1.1. “If you want to build an agent, don’t build an agent”
LangGraph, AutoGen, and similar frameworks have made it easy to build AI agents. In demos, the agent works fine and completes the task end-to-end.
The moment you try to put it into production, the difficulty shows up:
- The user’s instructions are vague, and the agent goes off the rails.
- A trivial task ends up in an infinite loop and your costs explode.
- You can’t debug it — the whole thing is a black box and you can’t reason about its behaviour.
Anthropic, who is closer to the frontier of agent development than most, says the quiet part out loud:
“Start with simple prompts, optimize them with comprehensive evaluation, and add multi-step agentic systems only when simpler solutions fall short.”
— Anthropic, “Building Effective Agents” (2024)
In other words: don’t reach for a complex agent first. Solve it with a simple prompt; reach for the agent only when that genuinely isn’t enough.
And yet most of us jump on the framework and dive straight into over-abstraction.
1.2. Learn the “shapes” before learning the framework
The problem isn’t the tools. It’s that we don’t have a shared vocabulary for what kind of structure should solve what kind of problem.
When someone says “let’s let the agent handle this”, one person hears “an autonomous ReAct loop” and another hears “a deterministic workflow with fixed steps”. The conversation can’t converge.
This piece tries to organise a framework-agnostic set of design patterns that show up repeatedly in real AI work. Once you have these in mind, choosing the right architecture for the phase your project is in becomes a much easier conversation.
2. A practical shared vocabulary
2.1. Cross-referencing three sources
To pin down a “shared vocabulary” for agent design, I cross-referenced three of the most practical sources available right now:
- Anthropic’s “Building Effective Agents” — design principles drawn from Anthropic’s own agent development experience.
- LangGraph’s documentation — architecture guidance from one of the leading agent frameworks.
- DeepLearning.AI’s “AI Agentic Design Patterns with AutoGen” — patterns presented in Andrew Ng’s practical course.
Names and granularity differ, but the same patterns keep showing up. I’ve consolidated them into ten.
The “ten” isn’t sacred. In practice you’ll combine multiple patterns, and new ones will emerge. What matters isn’t the count — it’s getting into the habit of thinking in shapes.
| Pattern | Category | Anthropic | LangGraph | DeepLearning.AI |
|---|---|---|---|---|
| 1. Prompt Chaining | Level 2: Workflow | ✓ | ✓ | - |
| 2. Routing | Level 2: Workflow | ✓ | ✓ | - |
| 3. Parallelisation | Level 2: Workflow | ✓ | ✓ | - |
| 4. Orchestrator-Workers | Level 2: Workflow | ✓ | ✓ | ✓ |
| 5. ReAct | Level 3: Agent | ✓ | ✓ | - |
| 6. Planner-Executor | Level 3: Agent | - | ✓ | ✓ |
| 7. Reflection / Critic | Utility | (mentioned) | ✓ | ✓ |
| 8. Evaluator-Optimiser | Utility | ✓ | ✓ | - |
| 9. Human-in-the-Loop | Utility | (mentioned) | ✓ | ✓ |
| 10. Memory-Augmented | Utility | (mentioned) | ✓ | - |
Notes:
- ✓ = explicitly named. (mentioned) = present as a related concept. - = not addressed.
- For Anthropic on Reflection / Critic, I mapped it to the self-critical loop they describe under Evaluator-Optimiser.
- The LangGraph column draws on the wider LangGraph documentation, not just one page — including the ReAct agent and Plan-and-Execute tutorials.
- Evaluator-Optimiser can be read as a kind of Reflection, but Anthropic treats it as a distinct concern, so I keep it separate. The difference:
- Reflection / Critic: the same LLM critiques its own output and improves it qualitatively (self-critique).
- Evaluator-Optimiser: a separate LLM acts as an evaluator and the loop runs against quantitative criteria.
2.2. Three levels of complexity: start simple
Before you can use these patterns well, you need to understand three levels of implementation complexity. Anthropic’s piece makes this point explicitly: start with the simplest pattern, and only add complexity when you have to.
The Level 1 / 2 / 3 labels below are my own framing for organising the patterns.
Level 1: Single prompt
- An LLM call with no branching. RAG (retrieval-augmented generation) sits here too. This is the building block for Level 2 and above.
- Control: the prompt.
Level 2: Workflow (deterministic)
- A system where the path and steps are defined ahead of time. The LLM makes branching decisions or processes data, but the overall control flow is fixed in code.
- Control: code.
Level 3: Agent (autonomous)
- The LLM decides “what to do next” dynamically and runs its own loop. Flexible, but harder to control and more expensive.
- Control: the LLM.
For prototyping or early iterations, Level 1 or Level 2 is usually enough — yet teams routinely jump straight to Level 3 and end up unable to control the result.
3. Pattern-by-pattern guide: when to reach for which
The order below roughly follows how often each pattern shows up in real work.
Level 1: Single prompt
Before reaching for any system-level structure, push as far as you can with a single prompt.
0. Single Prompt / Simple RAG
What it is: an LLM call with no branching. Retrieval-augmented generation (RAG) belongs here.
When to use it:
- Summarisation, translation, simple Q&A.
- Most business use cases can be solved with prompt engineering alone (few-shot examples, careful instructions, etc.).
Level 2: Workflow (deterministic)
Reach for these when Level 1 isn’t enough. They’re predictable and easy to debug.
1. Prompt Chaining
What it is: split the task into sequential steps. The output of one step becomes the input of the next.
When to use it:
- Long-form generation (outline → write each section → integrate).
- RAG (query expansion → retrieve → answer).
Why it works: you can inspect the intermediate artefacts, which makes quality far more stable than a single prompt.
2. Routing
What it is: use an LLM as a classifier to decide which downstream flow to send the request into.
When to use it:
- Customer support (“returns” goes to flow A, “technical question” goes to flow B).
- Guardrails (“inappropriate query” routes to a refusal flow).
Implementation tip: use a smaller, cheaper model (Gemini Flash, GPT-4o-mini, etc.) for the routing call itself.
3. Parallelisation
What it is: run independent tasks concurrently and aggregate at the end (voting, summarisation).
When to use it:
- Multi-perspective review (security, performance, usability — code-reviewed in parallel).
- Web search (fan out multiple queries simultaneously to gather information).
Why it works: it softens the latency cost of LLM calls.
4. Orchestrator-Workers
What it is: a central Orchestrator (an LLM) decomposes the task, hands sub-tasks to specialised Workers, and integrates the results.
A note on classification: Anthropic puts this in the Workflow bucket. The reasoning: as long as the Orchestrator’s instructions are clear, the overall behaviour stays predictable.
When to use it:
- Complex coding tasks (e.g. separate roles for design, implementation, and testing).
- Wide-reaching changes that touch many files at once.
Level 3: Agent (dynamic and autonomous)
Use these only when the task genuinely is “you can’t know the next step until you’ve tried this one”. From here on, you’re not controlling the system — you’re guiding it.
5. ReAct (Reasoning + Acting)
What it is: a loop of Thought → Action → Observation.
When to use it:
- Exploratory questions where you don’t know how much you’ll need to look up (“compare the latest iPhone specs”).
- OS-level operations, browser automation.
Watch out for: without a hard cap on iterations, you’ll hit infinite loops and runaway costs. For OS / browser-level operations, the security surface is real — restrict the available commands and consider sandboxing.
6. Planner-Executor
What it is: produce a full plan first, then have an Executor work through it step by step. This avoids the short-sighted moves that ReAct sometimes makes.
When to use it:
- Long-running tasks with a clear goal (“upgrade the library versions in this repo and get the tests passing”).
Why it’s easier to control: you can let a human review and edit the plan before execution starts.
Utility & Governance: quality and trust
These aren’t standalone architectures. They sit alongside the Level 1–3 patterns above and are how you make the whole thing actually trustworthy.
7. Reflection / Critic
What it is: the LLM critiques its own output and produces a revised version.
Effect: in code generation and writing tasks, this dramatically improves quality.
8. Evaluator-Optimiser
What it is: an Evaluator scores the output against quantitative criteria, and the Optimiser loops until the criteria are met.
When to use it:
- Code generation (success criteria: compiles, tests pass).
- Translation (loop on a mechanical metric like BLEU).
9. Human-in-the-Loop (HITL)
What it is: insert a human approval step before consequential decisions.
Effectively required for: financial transactions, sending email, writes to production databases — anything that’s hard to undo or has wide blast radius.
Implementation: this is exactly where frameworks like LangGraph earn their weight (state checkpointing, pause and resume).
10. Memory-Augmented
What it is: store more than the conversation history — user preferences, established facts, prior interactions — in a database (e.g. a vector store), and retrieve from it on subsequent turns.
When to use it: personal assistants, long-running coaching bots, anything where continuity over weeks matters.
4. A practical roadmap
A few rules of thumb to make this stick:
Stop reaching for ReAct first. Try Level 1 or Level 2. Most tasks are solvable that way and will be more stable.
When you hit a quality wall, add Reflection before going agentic. Self-critique tends to buy more than scaling the model up.
When the task is genuinely complex, split responsibilities with Orchestrator-Workers rather than cramming everything into one giant prompt.
Reach for Level 3 (ReAct, Planner-Executor) only when there’s a genuinely unpredictable element you can’t pin down — and when you do, ring it with guardrails (HITL is usually mandatory).
Closing: pick the framework last
“LangGraph or AutoGen?” is a question that only makes sense once the pattern is settled. If what you actually want is a stateful, cyclic flow (a ReAct loop), LangGraph fits. If you want multiple autonomous agents talking to each other, AutoGen might. But if Prompt Chaining is enough, plain Python plus the OpenAI SDK is often the most honest answer.
(Personally I’ve been enjoying Pydantic AI — type-safe, not heavy, and it sits well with the “start simple” instinct.)
One more thing. The right moment to pick a framework isn’t actually when “the agent shape” becomes clear. It’s when “the shortest path to solving the customer’s problem” becomes clear.
Don’t grab the trendy tool. Ask yourself: what’s the simplest, most reliable pattern that solves the problem in front of me? Once you can answer that, you won’t get pushed around by the framework.
What’s next
This piece set up the shared vocabulary — the overall map of agent design patterns. The hard part of agent work isn’t understanding the theory, though, so if there’s interest I’ll go deeper into specific patterns with concrete implementations and how to wire in evals.
There are also newer angles being actively discussed in the industry — Multi-Agent Collaboration and Agentic AI Governance among them. I’ll get to those when they come up in real work.