Vollständiges Transkript anzeigen (4.732 Wörter)
If you're building AI systems, or looking to get the most from tools like Claude Code, Codex, or the Hermes agent, then there are 35 agentic design patterns that you need to know about, otherwise you're flying blind. Knowing the right pattern for the job can dramatically improve your results, and often you don't even need to build it. Just naming the pattern in a prompt to your coding agent can change its direction of travel.
And here they are, all 35 spread across eight families. This is a live dashboard that I built where we can actually see each one of these in action. It's built on top of this free, open repo from a developer called Fareed Khan, who has aggregated all of these from various sources. And before we get into it, it's worth noting that these patterns are just workflow shapes. Each one is a small graph of nodes, with a control flow running through it. So things can chain together, they can branch, or fan out. And the Arena, the dashboard, draws that shape live for each run.
And the special shape, the one that makes all of this agentic, is the loop. The model decides, it acts with a tool, it checks the result, and it goes again until the job is done. You'll see that loop inside most of these patterns, and you don't need to memorize any of these. You just need to know what's the right shape for the job.
These patterns can be broadly grouped into eight families. You've got Tools and Actions, Reasoning and Reflection, Retrieval, there's Memory, Sampling and Search, Multi-Agent, Safety and Routing, and then there's a couple of specialty ones. And knowing these shapes is useful in a lot of scenarios. If you're driving coding agents like Claude Code or Codex, you can replicate a lot of these using sub-agents, agent teams, or dynamic workflows. If you design workflows and automations, every one of them is secretly one of these shapes. If you're building custom AI systems or harnesses, these are your architecture menu.
And importantly, if you run smaller, local models, the weaker models need the shape to carry the reliability that a frontier model gives you for free. Let's jump into the first family, which is Tools and Actions. And this is the most familiar ground, because ToolUse and ReAct are the loops that you drive every day using Claude Code or Codex. The model reasons, it calls a tool, it reads the result, and it carries on. That's the workhorse behind pretty much every real agent. ReAct just makes thinking explicit, so a thought, then an action, then an observation, and round it goes.
And you can see this in action for yourself in the Claude app. So you ask it a question, and then that fires off a round of thinking, and it then follows up with actions, further thinking, actions, and then it eventually synthesizes a response. And that's what this first family of design patterns is, Tools and Actions. And the first is the most basic. So what's a question that's asked, it goes directly to an agent to trigger an output. So in this case, it's going to be a tool call output, to search for the name of the CEO of Microsoft. So let's run it. And you can see the first LLM call is happening. That then triggers a tool call, where it's using the web search tool. The query is current CEO of Microsoft. And the output of that tool call then goes back to the agent for a second run, which then results in the synthesized response. And there we go. So the difference between what you saw here versus what we saw in the Claude desktop app is there was no thinking involved. This is just a ToolUse design pattern. Whereas with the ReAct loop, there is explicit thinking. So it's the same question here, but if we run it now, initially there's a thinking process that takes place, and then the agent acts on that thought process, which is in this case to call a tool, and then off the back of the output, it synthesizes the response. So the ReAct loop is the standard, common loop across all agent systems. And you get much better results from an agent synthesizing thoughts first before jumping straight into actually carrying out an action.
And the next step out of a ReAct loop is then a Planning pattern. So here we are decomposing a goal into an ordered, stepped list. And then we execute the steps one by one. And also we have the ability to replan when a result changes the picture. So let's run this one. And here we're asking to plan a three-day, vegetarian-friendly itinerary for Tokyo on a $200 a day budget. And if we click into plan, you can see it has outputted this five-step plan. And now it's going to execute those individually. So if the output from one of those steps changes the nature of the initial plan, it can make some changes. And there's the result. So the task is complete. We have our full itinerary, but what's interesting is the plan, which was initially five steps, ended up as eight steps because during this replan phase, three additional steps were added. So it has the ability to reorganize itself midway through the process. And this type of planning management is very open-ended. It's driven by a single agent, whereas in the next pattern, which is our PEV loop. So here we have our planning stage that creates the steps as before, it then goes to an execution stage to execute those step-by-step, but then we have a different agent with a different system prompt, and its job as an impartial evaluator is to judge whether the expected steps result fully adheres to whatever rubric, whatever criteria you have set at this stage. And as you can see, if it doesn't meet the criteria, it outputs an is satisfactory equals false, and then it works its way through the loop to fix the output. And as you can see, it's finalizing the result now, having gone through the entire flow, and all checks have now passed and have been verified.
We spent a lot of time on this channel diving into the latest in AI architecture, so if that's what you're into, then make sure to subscribe to our channel so you don't miss the next one. And there's two more variations within this family that have different surfaces. So the SWE agent is a coding agent that has access to a sandbox file system. So here we have an agent that decides what action to take, so it needs to list the files in the file directory, it needs to read files, it needs to write files, and then there's the execution of that within the sandbox to generate the output. And in this case, it has successfully updated a file within the sandbox. The browser agent is similar again. It's deciding and executing, except this time it's triggering playwright and interacting with browser tabs. So here it needs to navigate to a specific website and pull out a heading, for example.
Next up is Reflection and Reasoning. And this is the cheapest win if you're looking to boost reliability in your outputs. With Reflection, you generate, then you critique, and then you refine. It's exactly the same as the PEV loop you saw a few minutes ago. So it's a model wearing two hats, essentially, two system prompts. There's a producer that drafts an answer, and a critic that grades that answer and hands it back for another pass. And this is different to the basic tool loop because that was the same model critiquing its own work. So with your standard reflection, you're drafting an answer, you're generating, and then you have a judge score and critique it from one to 10, so that's the critique stage, and then you rewrite using that critique, so you're refining. And then you loop until the score clears the target or the iterations run out. So here we have a task that is a calculation that requires a level of logical reasoning. And the generate stage produces its best answer, and the critique stage is the impartial evaluator that provides a structured response. It scores it out of 10 and it provides its critique, and then if it passes the threshold or the bar, the output is finalized and delivered to the user. And again, this is multi-agent because you have a generator and a critiquer or an evaluator. You could have this deterministic using linters or custom code, but it is a very useful pattern if you're looking for quality over, let's say, latency or token cost. A variation on the reflection pattern is one that saves these reflections to memory. So here we're attempting the task, evaluating the answer, and then writing a verbal lesson into episodic memory, and then retries are informed by its accumulated lessons, and then you have improvement across trials. So this is useful if you're looking to carry the learnings from one task into all future runs of a similar task.
Onto other variations then of this think-before-act pattern. The first is SelfDiscover and here you're composing your own reasoning recipe before solving. So you're selecting useful thinking modules as they call them, you're adapting them to the task, you're assembling an implementation plan, and then solving by following it. So that all sounds quite abstract, but if we jump into it, firstly you select your thinking modules, so within the prompt there's a module library, you know, you have critical thinking, listing facts, considering analogies, step-by-step reasoning, reverse engineering, evaluating, devising algorithms, there's lots of these thinking modules. So the first call is to select some specific to the task at hand, so it selected these modules. It then adapted them to the task at hand, which is this same calculation that requires logical processing and thought, it then implements them, solves, and produces the output. So while this is a bit abstract, it's very useful for kind of unusual, novel problems where there isn't a standard approach to actually solve them.
Chain of Verification is a different approach where you verify each claim independently. So you draft a baseline answer, and then you plan independent verification questions, and then you answer each one independently, so errors can't actually defend themselves, and then the rewrite keeps only what actually survived. So you can see this in action here, we're asking it to name five novels by a particular author that won a particular award. The baseline answer is then generated, which are these two books, and then the verification plan is created, so a series of questions that need to be answered independently. All of those are then executed, and then you can revise the answer based off those independent verifications, and all of those did stand up to scrutiny. So this is a really good approach if you're looking for hallucination-free kind of factual outputs, so it could be lists or citations in particular. We built something similar for a legal citation system that we created in our community.
Constitutional AI is another variation on this reasoning and reflection. So here we're checking the draft answer against an explicit rule list. So each rule gets its own pass or fail, its critique, and then it revises it to fix exactly the failed rules. Here we've asked it to choose what's the best programming language, so something obviously opinionated that we're looking for, it generates a response, Python, and then it critiques that response based off the specific rules that you have in your system. So don't include personal stances, cite or hedge appropriately, be concise, so whatever your custom kind of logic is around the critique, and then it runs the review against those rules, so you can see it failed here, it failed there, it passed this one, and then it goes in the loop to revise, finalize and output. So a good example here would be if you're looking to enforce a particular kind of tone of voice or style guide or brand guidelines on outputs, you can get it to critique the outputs before it actually is outputted to screen.
Onto Retrieval, and this is an area we've covered extensively on this channel. So here in a single line, you're letting the agent look things up externally, so it can answer from let's say your documents, not just its training data, and it's the bridge from a basic chatbot to an agent that actually knows your stuff. So you ask a question, it can use a tool call to check your database, to check your knowledge base, whatever it is, retrieves information, and then off the back of that returned knowledge, it can then output and synthesize an answer. And there are various versions of this retrieval loop, things like GraphRAG, AgenticRAG. So let's dive into it. With AgenticRAG, the agent can decide if and when to retrieve depending on the question that's asked, and it can do it several times if it needs, to flesh out its knowledge on a particular topic before producing a response. And this works very well with unstructured knowledge bases, things like PDFs, word documents that you can ingest and carry out vector search or text-based keyword or hybrid search. Here we're asking what propellant does the Phoenix 2 engine use, and if we run this, this library has seeded all of the information that's needed to answer this question, so it goes to the agent, it provides the request and it provides the tool call, so it can trigger the retrieval action, passes in the query, and then it gets the response, so these are the five chunks, let's say, that were returned, and it can then synthesize the output off the back of that. Now it only carried out a single retrieval tool call there, but it could have done that 10 times, it could have tried different tools, different knowledge bases, whatever else to formulate the answer. And as you can see, it uses methalox propellant, which is a mixture of liquid methane and liquid oxygen. So this is pretty much the industry standard now when it comes to retrieval, um, from custom knowledge bases. A variation on this is CorrectiveRAG, which does something quite clever, which is that it grades each document that it retrieves and it throws away the ones that aren't relevant before it answers, so it's not polluting the context window. So with the same question asked, you can see that it carried out retrieval, it's now grading the chunks, the documents that came back, and you can see here, relevance, irrelevant, in that case. So these are small LLM calls, and then all of that triggers corrective action which could be to route to web search, it could be to carry out another search of a private knowledge base, and all of that then feeds in to the generation of the response. SelfRAG is an interesting pattern because it's all based off this idea of reflection tokens. So it emits a reflection tokens based on each retrieved passage. Is it relevant? Is it supported? Whatever your custom criteria is, and it only answers from passages that have been explicitly endorsed. And for the same task, it initially decides does it need to retrieve? If so it carries out the retrieval, and then it's an LLM call to reflect on the retrieved chunks, and this is where you can have your custom criteria, so is it relevant, supported, or useful? And then based off those indicators or flags, you choose to either keep or discard and that can then feed into the response. AdaptiveRAG is a nice approach where you can classify different queries to determine whether you actually need to carry out retrieval at all. So in this case for the same task, we do need to carry out retrieval, but it's a simple question so a single stage retrieval is likely all that we need. If it's a complex question that requires multi-stage retrieval, you can go down a different track, so you can adapt to the questions that are asked. This pattern works better for more traditional RAG where you might be using smaller models that don't have the intelligence around tool calling and complex retrieval, so you need to decompose and build it out like this. I published an entire RAG design pattern masterclass which goes into all of this in great detail. Um, it's about eight months old but very relevant still, I'll leave a link for this in the card above. The last approach I'm going to cover in this category is GraphRAG. So if we kick it off, we're asking the same question again, but here we're building initially a knowledge graph from the corpus of information, we're detecting communities of related entities, and then those are pre-summarized so that these global questions around these clusters are answered from the summaries and not raw chunks. So I've ran that, but our live graph hasn't kicked off yet because we are now ingesting all of the documents and extracting triples, so subjects, predicates and objects, entities and relationships essentially. All of those are plotted in a network X in memory knowledge graph which you'll see on screen now. And this would only be done on ingestion, you wouldn't necessarily do this when triggering a query like I've done here. And you can see the knowledge graph that has been generated from this, the LLM has processed the corpus of information around the stardust launch, there's propulsion, payloads, and the various colors that you see are the different communities and the clusters. So within the events feed here, you can see the summaries then of those clusters, and when it came to answering the question then, initially we classify the question as either local or global, and then you can search across either the local nodes which are the specific named entities or the global communities and their summaries. So here the scope was local, target entities was the Phoenix 2 engine, and from there then it builds the context to answer the query, and the context that came back from the graph is this. This is the entity Phoenix 2 engine, the relationship is that it powers, and the entity is here the first stage of stardust 9, and then all of that context is used to create the response. I go into a lot more detail on GraphRAG in this video here, so again I'll leave a link for that in the card above.
Next up we're going to dive into Memory, and you can think of memory as state that survives into the next session. So what turns a stateless model essentially into something that remembers you across conversations. The interesting thing about this family is that the patterns differ by what they store. First up is episodic semantic memory, and here you are remembering two ways at once. So you're saving and recalling past turns and you can search over those turns, but then you also extract out all of the facts from the turns, and you can retrieve from that graph of facts. So for example, if you said that you run a Shopify store selling ceramics, budget 200 a month, then the fact that you sell ceramics on Shopify would be saved to a graph, whereas the entire turn would be saved into memory. So let's see it in action. Here I'm asking what is my favorite color, just return the color name. So we are retrieving from memory, and you can see in this turn, there are known facts from semantic memory that the user has a favorite color which is teal. But there's also the past episodes, so there was a conversation that took place a few weeks back where the user talked about how they like the color teal and the assistant responded with X. So all of that then can be used as retrieval essentially to formulate the response. Now the risk with this is that if you load in lots of previous conversations into context, it's going to send off the agent in the wrong direction. So that's why recalling the specific facts can be powerful enough that you might not need the specific conversational transcripts. And that semantic episodic agent used a knowledge graph for those facts, so a graph memory agent is essentially the same thing.
The next design pattern is an early implementation of agent skills. So Voyager has reusable Python skills that run as real sub-processes, and this is ideal for recurring programmatic tasks that should get faster every time. So initially the agent will create the script, in this case it's a Python script, and then it will save that script to a skills library to file, so the next time that the user asks for that task to be run, instead of generating that function again, it can just trigger the script that was previously generated. This was produced in 2023, so it is an early implementation of agent skills, but specifically for memory as well.
Next we have MemGPT, this is an operating system style memory. So it's ideal for long-running chats that outgrow the context window. And so it's a small always in context core plus a storage area where the agent can page facts in and out of itself. So it's like virtual memory. In production, this pattern isn't really used, the archiving of context, instead it's usually the compaction of context to free up space in a context window. But it is possible to offload parts of your context to disk via an archive like this.
Agent Workflow Memory is the last pattern in this family, and it's exactly what makes the Hermes agent so good. So with this, you're creating reusable workflow recipes or skills essentially. After each solved task, it mines a reusable three-to-six step recipe in this case, so it extracts it from the previous turns and indexes it, so any new tasks retrieve the closest recipe and follow it instead of starting cold. So again, this is very much agent skills nowadays, the Hermes agent will regularly review the most recent turns in the conversation to figure out is there anything procedural that we can extract out and have as a reusable skill.
In the Sampling and Search family, we're dealing in scenarios where a single answer isn't enough. All of these patterns, they all share the same shape. Generate several candidates and then pick the best one. Which then raises the question, how do you actually pick the best one? Let's dive in. So first up is Tree of Thoughts. Here, instead of a single chain of reasoning with the model, we're proposing X number of deliberately different next thoughts, so we're generating lots of thoughts, then we're judging each on a strict one-to-five score or a rubric, and then we're only keeping the top beam or pruning everything else, and then you can loop deeper, and then the best complete path wins. And here we've asked it to generate substantively different next reasoning steps. Hard rules: Each candidate must explore a different angle, framing, or approach—not a different wording of the same idea. If you cannot find truly different angles, write fewer candidates rather than fill with paraphrases. At least one candidate should be deliberately unconventional (a rinky path that might dominate or might flop). And in this case it has produced two different variations. And then we have an evaluator agent score that reasoning thought on a strict one-to-five scale, and you'll see, for this thought it scored it as a four. The next thought it scored it as a four, the next one was a two. So based off those then, you can keep the top thought and then go deeper, so it generates more candidate reasoning thoughts, and then scores those and goes deeper again, and that way it is a tree of thoughts, a tree of reasoning, to get to the right output. So this is a very good approach in a situation where there's a problem, let's say, where the first idea may be wrong, for example some sort of planning that you need to trigger or a complex puzzle that needs to be solved. And an issue with this approach is this rubric, the one-to-five score, because out of all of these LLM calls, there was six in this node, we had four appear as the output in five of those six. And this is an issue when dealing with LLMs, is that they're likely to produce a number that's the middle point in a band, so if it's one-to-five, it'll pick something like three or four, if it's one-to-10, it'll pick something like six or seven. And you can see that in the second pattern here as well, which is our MentalLoop where we are simulating, scoring and acting. So back to the task of planning this itinerary for our Tokyo trip, we have generated distinct candidate actions, and then that passes into a simulation where it works out what that would look like, but then it also scores it from one to five, and we end up with lots of fours again. And then off the back of that we decide, and there's an explanation around the output. So we're still limited and constrained by this flattening of the scores. And Ensemble is another example of this, so we have X number of independent voters that vote on the same task and then they aggregate their answers, and then the majority vote or weighting wins. So if there are errors in particular LLM calls, they wouldn't survive because you have a number of LLM calls and the majority would win. With self-consistency, it's down to reasoning paths again, so you can have X number of reasoning path for the same question and then majority vote on the final answer. So you can see this here, we have a number of LLM calls, all producing different chains of thought to solve this problem, and then majority wins on the final answer. And finally, LATS is the last one, so this is the Monte Carlo tree search over reasoning moves. So you pick the most promising leaf, and then you generate X number of candidate next moves, you judge each with a rubric again, a deterministic rubric to evaluate, and then propagate the reward in this case up the tree and loop again. And then you can see the reasoning trajectory so far, and then the task is to propose two substantively different next reasoning moves to extend this trajectory. Each should be a single concrete step. If the trajectory already solves the task, repeat the final answer as the only candidate. And then each move should be a concrete next step. So then that is evaluated to see are you making progress, is it complete, does it avoid loops, is it confidence high, and this is the difference between a one-to-five rubric versus true, false flags. And then that evaluation is carried back up the tree so that any tasks that were happening earlier on, any branches that were going nowhere can be cut off so that they don't waste further agent calls. So this is used for really hard search problems and kind of game-like tasks. And these types of agentic design patterns are exactly what we get into in our AI Architects course in our community. We have over 50 lessons that ground you in agentic systems, full deep dives into agentic retrieval and all of the various strategies and approaches, and then an entire module on harness engineering. And we have hundreds of builders in here all creating production-grade systems. So if this sounds like something that you'd be interested in, then definitely check out the link below. As I mentioned earlier, if you're building systems grounded in private data, then you should definitely check out my RAG design patterns video here.
Video
Video
