If I’m building an AI system, using Claude Code, Codex, or working with an agent such as Hermes, I don’t want to rely on prompting alone. Prompts matter, but the workflow shape matters just as much.
That’s where agentic design patterns come in. I think of each pattern as a small workflow graph. It defines the order in which an AI model thinks, calls tools, checks results, stores information, or hands work to another specialist. Some patterns run in a straight line. Others branch into several paths. The important ones include a loop: the model decides what to do, acts with a tool, checks what happened, and continues until it completes the task.
I built an Arena dashboard around 35 of these patterns, based on Fareed Khan’s open collection of agentic architectures. The point isn’t to memorize every diagram. It’s to know which shape fits the job.
These patterns fall into eight families:
- Tools and actions
- Reasoning and reflection
- Retrieval
- Memory
- Sampling and search
- Multi-agent systems
- Safety and guardrails
- Specialty patterns
A smaller local model often needs a stronger workflow shape to produce dependable results. A frontier model may handle more of that internally, but even then, a good architecture can improve quality, safety, and consistency.
1. Tools and Actions: The Core Agent Loop
Most practical agents begin here. The model receives a task, chooses a tool, uses it, reads the result, and responds. This is the workhorse pattern behind coding agents, web research agents, file-system agents, and browser automation.
Basic tool use
The simplest possible pattern is direct tool use. An agent gets a question, decides that it needs outside information, calls a tool, then turns the result into a usable answer.
For example, an agent asked for the current CEO of Microsoft can call web search with that exact query. It receives the search result, feeds it back into the model, and generates the final answer. There’s no explicit planning or visible reasoning stage. It’s simply request, tool call, result, response.
ReAct: reason, act, observe
ReAct adds an explicit thinking cycle. The agent forms a thought, takes an action, observes the outcome, then repeats if needed. This gives it a chance to decide what information it needs before it acts.
That loop is the common foundation of modern agent systems:
- Interpret the task.
- Decide the best next action.
- Call a tool.
- Read the observation.
- Choose whether to continue or answer.
In practice, ReAct often produces better outcomes than direct tool use because the agent can reconsider its approach after each result. It doesn’t just rush into the first available action.
Planning agents
A planning pattern makes sense when a task has several dependent steps. The agent first turns the goal into an ordered plan. It then executes each item one by one. Crucially, it can revise the plan when new information changes the situation.
Consider an itinerary for three vegetarian-friendly days in Tokyo on a fixed daily budget. A planner can begin with five steps, such as identifying suitable areas, finding food, estimating transport, selecting activities, and organizing each day. During execution, it may discover that the budget or travel times require extra steps. The plan can grow and adapt instead of failing because the first version was incomplete.
Plan, execute, verify
The plan, execute, verify pattern, often shortened to PEV, separates responsibility across stages. One part produces the plan. Another follows it. A separate evaluator checks whether the outcome meets a defined rubric.
That evaluator should be impartial. It doesn’t simply continue the work. It asks whether the answer satisfies the actual requirements. If the response fails, it returns a structured result such as “not satisfactory” and sends the workflow back through another improvement loop.
This is useful whenever quality matters more than speed. It also helps when success has clear criteria, such as whether a research brief covers required topics or whether generated code meets an acceptance checklist.
SWE agents and browser agents
The same general loop can operate over different surfaces.
A SWE agent is a software engineering agent with access to a sandbox file system. It can inspect folders, read files, edit code, write new files, and run commands. The architecture is still decide, act, inspect, repeat. The tools simply operate on code and files.
A browser agent follows a similar pattern through browser automation tools such as Playwright. It can open a website, inspect page content, click elements, fill forms, and extract headings or other data. Because browser actions affect an external environment, it needs tighter controls than a simple search tool.
2. Reasoning and Reflection: Generate, Critique, Refine
Reflection is one of the cheapest ways to improve reliability. Instead of accepting the first answer, the system drafts a response, critiques it, then revises it.
I think of it as a model wearing two different hats. One role produces the work. The other role judges the work against a defined standard. Those roles can use different system prompts, even if they use the same underlying model.
Standard reflection
A reflection agent generates an initial answer, then sends it to a critic. The critic can score it from one to ten, explain the weaknesses, and identify what needs changing. The generator then rewrites the answer using that feedback.
The loop stops when the score clears the target or when it reaches a maximum number of attempts. This pattern is valuable for logical reasoning, structured writing, and tasks where a poor answer creates real downstream cost.
It does spend more tokens and takes longer. That’s the trade-off. I use it where quality matters more than latency.
Reflection with memory
A stronger version stores lessons from the critique stage. After an attempt, the system records a short verbal lesson in episodic memory. The next attempt can retrieve that lesson and avoid repeating the same mistake.
Over repeated tasks, the agent builds a set of useful reminders. It may learn that it regularly misses edge cases, gives too much detail, or fails a certain format requirement. This turns isolated correction into improvement across future trials.
Self-discover
Self-discover is a more unusual pattern. Before solving a problem, the agent chooses a set of reasoning modules that suit the task. Those modules might include critical thinking, fact listing, analogies, step-by-step reasoning, reverse engineering, evaluation, or algorithm design.
The agent selects useful modules, adapts them to the task, builds a reasoning recipe, and follows that recipe to solve the problem. It works well for novel problems where there’s no obvious standard method.
Chain of verification
Chain of verification, or CoVe, aims to reduce factual errors. The agent drafts an answer, then creates independent verification questions for each important claim. It answers those questions separately before rewriting the final answer.
The independence matters. A weak claim can’t keep defending itself through one continuous reasoning path. If the task asks for novels by an author that won a particular award, the system should verify each book and award claim independently.
This is especially useful for factual lists, citations, and other content where hallucinations are costly.
Constitutional AI
Constitutional AI checks an answer against an explicit list of rules. The system evaluates each rule separately, marks it as pass or fail, then fixes only the failed areas.
The rules can reflect a style guide, brand voice, compliance policy, or output requirements. For example, a response may need to avoid political positions, show uncertainty where appropriate, cite facts, and stay concise. The system checks each criterion before releasing the answer.
This pattern is useful because vague requests such as “make it sound on brand” are often unreliable. Clear rules give the critic something concrete to judge.
3. Retrieval: Giving Agents Access to Your Knowledge
Retrieval turns a general chatbot into an agent that can work from your own documents, databases, and knowledge bases. Instead of relying only on model training data, the agent looks up relevant material and uses it to form its response.
Agentic RAG
Agentic retrieval-augmented generation, or agentic RAG, lets the model decide whether retrieval is necessary and how many searches it needs. It can search once, inspect the returned material, then run another query if the first results aren’t enough.
This works well with unstructured sources such as PDFs, Word documents, and internal documentation. The underlying search might use vector search, keyword search, or a hybrid of both.
For a question about the Phoenix 2 engine, the agent can retrieve chunks from a private knowledge base, inspect them, and answer from that evidence. It may need one search, or it may need ten. The architecture gives it that flexibility.
Corrective RAG
Corrective RAG adds a relevance check between retrieval and answer generation. The system grades each retrieved chunk and discards irrelevant material before it enters the answer context.
This matters because irrelevant documents can distract the model. If search results contain weak or unrelated passages, they can push the final response in the wrong direction. Corrective RAG can reject those chunks, perform another internal search, or route to web search if the private knowledge base lacks the answer.
Self-RAG and adaptive RAG
Self-RAG uses reflection indicators for retrieved passages. The model evaluates whether each passage is relevant, supported, and useful. It only answers from material that passes those checks.
Adaptive RAG classifies the question first. A simple factual question may need a single retrieval step. A difficult question may require a deeper, multi-stage search process. Some questions don’t need retrieval at all.
This can be particularly helpful with smaller models that need a more explicit retrieval workflow rather than the freedom to decide every step themselves.
GraphRAG
GraphRAG moves beyond raw document chunks. During ingestion, the system extracts entities and relationships from the source material. In other words, it identifies subjects, predicates, and objects, then builds a knowledge graph.
The graph can also group related entities into communities and create summaries of those groups. A later query can be classified as:
- Local, focused on a specific entity or relationship.
- Global, focused on a broad topic spanning a community of related entities.
A local question about an engine can retrieve the engine node, its relationships, and connected components. A global question about an entire launch program can use community summaries instead of flooding the context with raw source chunks.
4. Memory: State That Survives the Session
Memory gives an agent continuity. Without it, each conversation begins from zero. The patterns in this family differ mainly by what the system stores and how it retrieves that information later.
Episodic and semantic memory
Episodic memory stores past interactions. Semantic memory stores extracted facts. The combination is powerful because the agent can retrieve either the full history of a past discussion or just the relevant fact.
For instance, if someone mentions that they run a Shopify store selling ceramics with a budget of $200 per month, the full interaction can live in episodic memory. The facts “runs a Shopify store,” “sells ceramics,” and “budget is $200 per month” can also live in a semantic graph.
When asked for a favourite colour, the agent may retrieve both a prior conversation and a semantic fact such as “favourite colour: teal.” In many cases, the fact alone is safer and more efficient. Loading too many past conversations can add noise and send an agent in the wrong direction.
Graph memory agents
A graph memory agent uses a knowledge graph to store those extracted facts and their relationships. It’s effectively the semantic side of the episodic-semantic pattern. This is useful when the system needs to remember stable information without pulling entire old exchanges into context.
Voyager and reusable skills
Voyager is an early form of agent skills. The agent creates a Python script to solve a recurring task, saves the script to a skills library, then runs that existing skill on future requests instead of recreating it.
The key idea still matters. If an agent successfully solves a repeatable programmatic task, it shouldn’t need to rediscover the same procedure from scratch every time.
MemGPT and context management
MemGPT treats memory more like an operating system. It keeps a small core set of information in active context and stores less immediate information in an archive. The agent can move facts in and out as needed.
This approach addresses long-running conversations that exceed the context window. In production, systems often compact older context rather than archive every detail, but the basic concept remains useful: preserve what matters without overloading the active prompt.
Agent workflow memory
Workflow memory extracts reusable procedures from completed work. After solving a task, the agent mines a three to six step recipe and indexes it. A future task can retrieve the closest recipe and follow it rather than starting cold.
This is close to how modern agent skills work. The value isn’t just remembering facts. It’s remembering how to do something successfully.
5. Sampling and Search: Generate Several Options, Then Choose
Some tasks don’t have one obvious route to the best answer. In those cases, a system can generate multiple candidates and select the strongest one. The challenge is how to score or compare them.
Tree of Thoughts
Tree of Thoughts generates several different next reasoning steps rather than committing to one chain. It scores each candidate against a rubric, keeps the strongest branches, and explores deeper from there.
This can help with puzzles, planning, and other tasks where the first idea may be wrong. The system prunes weak paths and spends more work on promising ones.
There’s a catch. Language models often compress numerical scoring into the middle of a range. If the rubric runs from one to five, many outputs may receive a three or four. That makes subtle distinctions difficult.
Mental loop
A mental loop generates possible actions, simulates the likely outcome of each one, scores them, then picks an action. It’s useful for planning scenarios, such as choosing among several itinerary options.
It suffers from the same scoring problem as Tree of Thoughts. If every option gets a four, the score doesn’t tell the system much.
Ensembles and self-consistency
An ensemble uses multiple independent agents or personas. An analytical voter, skeptical voter, and pragmatic voter can each solve the same task. Their answers are aggregated, and a majority vote or weighted choice determines the result.
Self-consistency uses the same principle, but focuses on different reasoning paths. Several model calls solve the same problem independently. The final answer is selected by a deterministic vote.
Both can offer a relatively cheap reliability gain for short factual or logical tasks. A one-off error is less likely to survive if most independent paths agree on another answer.
LATS
Language Agent Tree Search, or LATS, applies Monte Carlo tree search to reasoning moves. The system picks a promising point in the reasoning tree, creates several concrete next moves, evaluates them, and sends the reward signal back up the tree.
LATS is different from vague one-to-five scoring because it can use clearer checks: Is the reasoning making progress? Is it complete? Does it avoid loops? Is confidence high enough?
That lets the system cut branches that lead nowhere. It’s a pattern for difficult search problems and game-like tasks, not something I’d reach for in a simple automation.
6. Multi-Agent Systems: Specialists, Shared Workspaces, and Debate
Multi-agent systems can look impressive, but I use them carefully. Splitting a task across agents creates more calls, more coordination, and more token cost. It only makes sense when the work is genuinely parallel or needs distinct specialist contexts.
Supervisor and specialist agents
The standard pattern has a supervisor agent that routes work to specialists. A financial specialist, technical specialist, and news specialist can each receive the part of the task that matches their expertise. The supervisor or a writer agent then combines their contributions.
The main benefit is isolated context windows. Each sub-agent can stay focused on its own domain without filling one giant prompt with unrelated material.
Blackboard systems
A blackboard system gives several agents access to a shared workspace. Each agent decides whether it has something useful to contribute. The strongest contribution gets written to the workspace, and the cycle repeats until a synthesizer turns the board into a final answer.
For a product tagline, an optimist, skeptic, historian, and quantitative analyst might each provide a different angle. Their work accumulates in one place before the final writing step.
MetaController routing
A MetaController is an outer router. It receives a task and chooses the architecture that should handle it. One request might go to a planning agent. Another could go to a reflection workflow. A third may route to retrieval.
This can be very effective for smaller local models because the routing layer reduces the number of decisions each specialist must make. Instead of asking one model to solve every type of problem, the harness selects a suitable workflow first.
Debate and STORM
In a debate architecture, several agents answer independently, read each other’s positions, argue across multiple rounds, and then pass their disagreement to a judge or voting mechanism.
STORM extends this idea into multi-angle research. It creates several perspectives, such as technical, historical, and social. Each perspective asks pointed questions, gathers answers, contributes to an outline, and feeds a final writer.
This can produce deeper research because it forces coverage from multiple angles. It can also become expensive very quickly, so it’s better suited to substantial research tasks than routine questions.
7. Safety and Guardrails: Keep Irreversible Actions in Code
Safety patterns matter most when an agent can affect files, systems, money, credentials, or external users. I don’t want a probabilistic model making the final call on irreversible actions. Code and deterministic checks should sit at those decision points.
Dry run
In a dry-run pattern, the agent can propose an action but cannot execute it directly. A simulator predicts the effect. A reviewer then approves or blocks the action.
Take a command that would delete files from a production folder. The system should inspect the proposed command, model its likely impact, assess irreversibility and safety concerns, then decide whether execution is allowed. Destructive requests should stop during review.
Capability routing
Capability routing asks the agent to assess its competence before answering or acting. It can give a qualified answer, add caveats, or escalate the task to a human based on what it knows and what information is available in context.
The rules can live in the system prompt, an agent instructions file, or a loaded skill. The important part is that the system has a defined route for uncertainty instead of bluffing.
Computer use with a safety gate
Computer-use agents operate graphical interfaces through a strict action loop. They need a safety gate because websites and interfaces may contain malicious instructions or prompt-injection attempts.
For example, an untrusted page could try to direct an agent to a phishing site. The safety gate should assess the proposed action before the agent follows it. The model can suggest the step, but the guardrail decides whether that step is safe.
8. Specialty Pattern: Reinforcement Learning Self-Improvement
The final specialty pattern uses an iterative improvement loop for short artifacts such as taglines, headlines, and marketing copy. The system generates candidates, scores them against detailed criteria, keeps the best version, and repeats.
The scoring needs to be specific. Rather than a generic score from one to five, the evaluator can ask:
- Does it match the brief?
- Does it use concrete imagery?
- Does it avoid clichés?
- Is it engaging?
- Does every required check pass?
This gives the model useful feedback. It can refine the copy until it meets the quality threshold rather than guessing what a broad numerical score means.
Which Agentic Design Pattern Should I Use?
The answer is usually simpler than people expect. I start with the smallest shape that can solve the task. Many systems don’t need a complicated team of agents, a giant search tree, and a memory layer from day one.
A practical progression looks like this:
- Start with a ReAct loop and tool calling. This handles a huge share of useful agent tasks.
- Add reflection when output quality isn’t reliable enough.
- Add verification or adversarial critique when factual accuracy or rule compliance matters.
- Add planning when the agent must discover and revise a multi-step route.
- Add retrieval when answers depend on private documents or current external information.
- Add memory when facts, preferences, or procedures must survive beyond one session.
- Add multiple agents only when work can run in parallel or needs genuinely separate specialists.
- Add deterministic guardrails before the system can make consequential external changes.
Each added layer creates a trade-off. It can increase reliability, but it may also reduce flexibility, add cost, and slow the system down. A standard ReAct loop with appropriate tools will often be enough.
The important shift is to stop treating agent failures as a prompting problem alone. Sometimes the system needs better instructions. Often, it needs a better shape. Planning, critique, retrieval, memory, search, routing, and safety gates each solve a different class of problem. Once I can name the pattern, I can build it directly or tell a coding agent which architecture to use.
For the complete collection of runnable architectures, the open agentic architectures repository provides a useful starting point.
