# Agent Patterns --- ## 1. ReAct Pattern ReAct is one of the most foundational and widely used patterns in the entire agent world, and its name is a combination of two words: "Reasoning" and "Acting." The core idea is refreshingly simple once you see it: instead of an agent either purely thinking through a problem in its head with no real-world actions, or purely taking actions with no real thinking behind them, ReAct has the agent alternate between the two, over and over, in a tight back-and-forth loop. Here's what this actually looks like in practice. The agent first writes out a short piece of reasoning — essentially thinking out loud about what it currently understands and what it should do next (something like "I need to find out the current weather in Paris before I can answer this question"). Then, based on that reasoning, it takes a single action (like calling a weather-lookup tool). It then observes the result of that action (the actual weather data that comes back), and this observation feeds directly into its next round of reasoning ("Okay, it's currently raining in Paris, so now I should check..."), and the cycle repeats. Why does this alternating structure work so well? Because it closely mirrors how a thoughtful human actually works through an unfamiliar problem — you don't typically plan out every single step perfectly in advance with zero regard for what you'll actually discover along the way; instead, you think a little, act a little, see what happens, and adjust your thinking based on what you just learned. This makes ReAct agents noticeably more reliable and less prone to going down completely wrong paths compared to earlier, simpler designs where an agent either tried to plan everything in one shot upfront, or took actions without any explicit reasoning behind them at all. Because of how well this pattern works and how simple it is to understand, ReAct became something of a foundational default — many other, more advanced patterns are really just variations or extensions built on top of this same core reason-then-act loop. --- ## 2. Planner Pattern The Planner pattern addresses a specific limitation that can show up in a purely step-by-step approach like ReAct — namely, that only ever thinking about the single very next step, without any broader view of the whole task, can sometimes lead an agent to work inefficiently, backtrack unnecessarily, or miss dependencies between different parts of a larger task. In the Planner pattern, before diving into execution, the agent (or a dedicated planning component) first produces a fuller plan — an explicit, ordered breakdown of the major steps it believes are needed to accomplish the overall goal, thought through upfront, before any of those steps are actually carried out. Picture the difference between wandering into a grocery store with no list and just grabbing whatever catches your eye as you walk down each aisle, versus writing out your shopping list at home first, organized by section, so you know exactly what you need and can move through the store efficiently without doubling back for something you forgot. This upfront planning step tends to make an agent noticeably more effective at complex, multi-part tasks, because it surfaces the overall shape and dependencies of the problem early on — for example, recognizing that a particular step can't be done until an earlier one is finished, or noticing that two parts of the task can actually be tackled independently and don't need to happen in a strict sequence. A well-designed Planner pattern typically isn't treated as a rigid, unchangeable script either — the plan is usually revisited and adjusted as the agent learns new things during execution, but having that initial roadmap still provides valuable structure and direction compared to figuring out each step completely from scratch as you go. --- ## 3. Executor Pattern The Executor pattern is closely related to, and often directly paired with, the Planner pattern above — in fact, the two are frequently used together as a matched set, which is why it's worth understanding them side by side. Where the Planner's job is to figure out *what* needs to be done and in what order, the Executor's job is to actually *carry out* each of those individual steps. This separation of responsibilities is a genuinely useful design choice, and it mirrors a very common pattern in how human teams organize work too — think of a project manager who lays out the overall plan and sequence of tasks, versus the specific team members who actually go and do the hands-on work of each individual task. In an agent system built this way, a Planner component produces the ordered list of steps, and then a separate Executor component (which might even be a completely different, more specialized agent, or several different specialized agents handling different types of steps) takes each individual step from that plan and actually performs it — calling the necessary tools, gathering the necessary information, and producing the actual result for that specific piece of the work. The benefit of clearly separating planning from execution like this is that each part can be optimized and reasoned about somewhat independently — the Planner can focus purely on the higher-level, strategic question of "what needs to happen and in what order," without getting bogged down in the messy, detailed specifics of exactly how each individual step gets carried out, while the Executor can focus entirely on reliably carrying out one specific, well-defined step at a time, without needing to hold the entire broader plan in its head simultaneously. This division of labor tends to make the overall system easier to build, easier to debug (since you can look separately at whether the plan itself was flawed, versus whether a specific step was executed poorly), and easier to extend over time. --- ## 4. Router Pattern The Router pattern addresses a common situation: not every incoming request or task should necessarily be handled the exact same way, and sending every single request down one single, identical processing path is often wasteful or simply the wrong approach for certain types of requests. The core idea is straightforward — a "router" component sits at the front of the system, looks at an incoming request, and decides which specific path, tool, or specialized agent is actually the right one to handle it, before actually sending it there. Think of it like a receptionist at a large office building who greets everyone coming in and directs them to the correct department based on what they actually need, rather than everyone being funneled through the exact same single desk regardless of their purpose for visiting. A concrete example makes this clearer: imagine a customer support agent system that needs to handle several very different kinds of incoming questions — a simple question about store hours, a complex technical troubleshooting issue, and a billing dispute. A Router pattern would first look at each incoming question and decide which of these categories it falls into, and then send it to the specifically appropriate path — perhaps a very lightweight, fast response for the simple store-hours question (since it doesn't need heavy reasoning), a more capable and specialized troubleshooting agent for the technical issue, and a completely different specialized agent (perhaps one with access to different, more sensitive tools) for the billing dispute. This pattern is valuable both for keeping costs and speed reasonable (not every request needs the most powerful, most expensive processing path) and for genuinely improving quality (a specialized path built specifically for billing disputes will likely handle that type of request better than one generic, catch-all approach trying to handle everything equally well). --- ## 5. Supervisor Pattern The Supervisor pattern is a specific way of organizing multiple agents working together, and it maps closely onto a familiar, intuitive structure: a manager overseeing a team of workers, where the manager doesn't necessarily do the hands-on work themselves, but is responsible for coordinating, delegating, and overseeing the work of others. In this pattern, there's one central "supervisor" agent that receives the overall goal and is responsible for breaking it down and delegating specific pieces of work out to other, more specialized "worker" agents beneath it — similar in spirit to the manager-and-specialists metaphor we saw with CrewAI in the previous explanation, though this is the general underlying pattern rather than any one specific framework's particular implementation of it. The supervisor typically monitors the progress and results coming back from each worker agent, decides what to do with those results (perhaps passing one worker's output along as input to another worker, or deciding a particular piece of work needs to be redone), and ultimately assembles everything into a final, complete result once all the necessary pieces have come together. This pattern tends to work especially well for tasks that naturally break down into clearly distinct areas of specialization, where having one coordinating "brain" tracking the overall goal and orchestrating the different specialized pieces produces better, more coherent results than either a single generalist agent trying to do everything itself, or a looser group of agents with no clear coordinating authority at all. The tradeoff is that the supervisor itself becomes an important, central piece that the whole system depends on — if the supervisor makes a poor delegation decision or fails to properly integrate the results coming back from its workers, the quality of the entire system's output suffers, even if each individual specialized worker agent performed its own specific piece of the task perfectly well. --- ## 6. Reflection Pattern We touched on the general concept of reflection back in the AI Agent Fundamentals explanation, but it's worth covering it here specifically as a named, reusable pattern, because of just how broadly useful and widely applied it's become across many different types of agent systems. The Reflection pattern involves explicitly building a dedicated self-review step into an agent's process — after producing some piece of work (an answer, a piece of code, a plan, a draft of some content), the agent (or sometimes a separate, distinct "critic" component) deliberately pauses to evaluate that work against the original goal, actively looking for mistakes, gaps, or ways it could be improved, before treating the work as genuinely finished. A simple, relatable comparison: think about the difference between dashing off a quick email and hitting send immediately, versus writing a first draft, then deliberately rereading it once before sending, specifically looking for typos, unclear phrasing, or a tone that doesn't quite land the way you intended. The Reflection pattern builds this same kind of deliberate, structured second look directly into an agent's process, rather than treating whatever the agent produces on its very first attempt as automatically good enough. In practice, this pattern often noticeably improves the quality of an agent's final output, particularly on more complex, nuanced tasks like writing or coding, precisely because it gives the system an explicit, structured opportunity to catch and correct its own mistakes, rather than relying entirely on getting everything exactly right on the very first attempt with no chance for self-correction at all. --- ## 7. Debate Pattern The Debate pattern takes the general idea behind reflection and extends it into a genuinely multi-agent setting — instead of one single agent reviewing and critiquing its own work, you set up two or more separate agents to actively argue different positions or perspectives on a problem, with the goal of arriving at a better final answer through this structured back-and-forth exchange than any single agent would likely reach entirely on its own. Here's the general idea in practice: you might set up one agent to argue in favor of a particular answer or approach, and a second, separate agent specifically tasked with challenging that position, poking holes in the reasoning, or proposing genuine alternatives. These two agents go back and forth over several rounds, each responding to and pushing back against the other's points, and either a set number of rounds are run before a final answer is settled on, or a separate "judge" component (which might be a third agent, or a human) reviews the full exchange and decides which position, or what combination of positions, actually represents the strongest, best-supported final answer. The underlying reasoning behind this pattern is that a single agent working alone can sometimes settle too quickly and too confidently on an answer that seems reasonable on the surface but actually has real flaws or blind spots it never considered, simply because nothing forced it to seriously entertain a genuine counter-argument. Deliberately building in this structured, adversarial back-and-forth tends to surface weaknesses in an initial answer that a single agent working in isolation would likely have missed entirely, similar to how a well-run human debate, or a genuinely rigorous peer review process, often produces a stronger, more carefully vetted final conclusion than one person simply thinking through a problem entirely by themselves with no pushback at all. --- ## 8. Human-in-the-Loop Human-in-the-loop refers to a pattern where a real human is deliberately built into an agent's process at one or more specific points, rather than the agent running from start to finish entirely on its own with absolutely no human involvement or oversight along the way. This matters more than it might initially seem, because fully autonomous agents — ones that make every single decision and take every single action entirely on their own — carry real risk, especially for actions that are irreversible, high-stakes, or genuinely hard to fully specify correct behavior for in advance (things we touched on briefly back in the "Acting" section of the agent fundamentals explanation). Human-in-the-loop patterns address this by deliberately building in specific checkpoints where the agent pauses and waits for explicit human review or approval before proceeding — for example, an agent might be allowed to freely search the web and draft an email entirely on its own, but be required to pause and get explicit human confirmation before that email is actually sent, since sending it is a real-world, hard-to-undo action with genuine consequences. There are a few different common ways this gets implemented in practice. Some systems require **approval before specific high-risk actions** (like the email-sending example above). Others build in periodic **check-ins during a long, multi-step task**, giving a human the chance to review progress so far and redirect the agent's approach if it's heading somewhere unintended, rather than only discovering a problem after the entire task has already finished. And some systems specifically use humans to **provide missing information or make a judgment call the agent genuinely isn't well-equipped to make on its own** — for example, an agent handling a customer complaint might be able to gather all the relevant facts and draft a proposed resolution on its own, but still hand the final decision on whether to actually offer a refund over to an authorized human, particularly for judgment calls that carry real financial or relationship consequences. This pattern represents a deliberate, thoughtful tradeoff — giving up some amount of full autonomy and speed, in exchange for meaningfully greater safety, oversight, and trustworthiness, particularly for the kinds of tasks where a mistake would be genuinely costly or difficult to walk back. --- ## 9. Swarm Agents The Swarm pattern describes a genuinely different way of organizing multiple agents, compared to the more centrally coordinated approaches we discussed earlier, like the Supervisor pattern. Rather than having one central, coordinating "brain" directing and overseeing everything, a swarm consists of many individual agents operating with a much more decentralized structure, where overall useful behavior emerges from the interaction of many simpler, more independent agents, rather than being explicitly directed from the top down by one central authority. The name deliberately draws inspiration from swarm behavior seen in nature — think of how a flock of birds or a colony of ants can accomplish surprisingly sophisticated, coordinated collective behavior, even though no single bird or ant is actually directing the whole group's overall strategy; each individual is simply following relatively simple local rules and reacting to its immediate neighbors, and the sophisticated group-level behavior emerges naturally out of these many simple, local, decentralized interactions. In an AI agent context, a swarm-based system typically involves many individual agents that can hand tasks off to each other somewhat fluidly and dynamically, without necessarily requiring approval or coordination from one fixed central supervisor for every single decision or handoff. This kind of structure can make a system more flexible and resilient in certain situations — since there's no single central bottleneck or point of failure that every decision has to pass through — but it also tends to be considerably harder to predict and control precisely, and correspondingly harder to debug when something goes wrong, since there isn't one clear, central place to look for exactly why the overall system's collective behavior ended up the way it did. Because of this tradeoff, swarm-style patterns tend to be used more selectively, for specific situations where flexibility and resilience are especially valuable, rather than being the default, go-to structure for most everyday multi-agent applications. --- ## 10. Hierarchical Agents The Hierarchical pattern organizes multiple agents into distinct, structured layers or levels, somewhat like an organizational chart in a traditional company, with higher-level agents overseeing broader, more strategic goals, and lower-level agents handling narrower, more specific pieces of work, often several layers deep. This extends the basic idea behind the Supervisor pattern we discussed earlier, but goes further by allowing multiple layers of this same structure to stack on top of each other. For example, picture a top-level agent responsible for an overall broad goal, which delegates out to several mid-level supervisor agents, each responsible for a distinct major sub-area of that goal, and each of those mid-level agents, in turn, delegates further down to their own specific worker agents handling narrow, specific tasks within their particular sub-area — much like how a large company might have a CEO overseeing several department heads, each of whom oversees their own team of individual specialists actually doing the hands-on work. This layered structure tends to become especially valuable for genuinely large, complex tasks or systems, where trying to have a single flat structure (one supervisor directly managing dozens of individual worker agents all at once, with no intermediate layers) would become unwieldy and difficult for that one supervisor to meaningfully track and coordinate all at once. By breaking things into layers, each individual agent at any given level only needs to reason about and manage a manageable, appropriately-scoped piece of the overall problem — a mid-level supervisor only needs to track its own specific sub-area and the handful of workers reporting to it, rather than needing full visibility and direct control over the entire system's complete complexity all at once. The tradeoff, similar to real organizational hierarchies, is that information and decisions have to pass through more intermediate layers to move between the very top and the very bottom of the structure, which can introduce more overall latency and more opportunities for something to get lost, distorted, or delayed somewhere along that longer chain, compared to a flatter, more directly coordinated structure. --- ## 11. Event-Driven Agents The Event-Driven pattern represents a different way of thinking about when and why an agent actually takes action, compared to the patterns we've discussed so far. Rather than an agent running in response to a direct, deliberate request (like a user typing in a question and waiting for a response), an event-driven agent instead sits and waits, continuously monitoring for specific events happening in its environment, and automatically springs into action whenever a relevant event actually occurs. Think of the difference between a customer support agent that only ever responds when a customer directly types in a question, versus a monitoring agent that's constantly watching a company's systems in the background, and automatically kicks off an investigation the moment it detects something like a server error rate spiking, or a payment failing, without anyone having to explicitly ask it to check at that particular moment. The "events" that trigger this kind of agent can come from all sorts of sources — a new email arriving, a file being uploaded to a shared folder, a specific value in a database changing, a scheduled time being reached, or a notification coming in from some other separate software system entirely. This pattern is particularly well suited to tasks that fundamentally involve ongoing monitoring, or reacting promptly to things that happen unpredictably, rather than tasks that are naturally initiated by a direct, deliberate human request each time. It does introduce its own particular design considerations worth being aware of — an event-driven agent needs a genuinely reliable way to actually detect and correctly interpret the relevant events in the first place, and careful thought needs to go into avoiding situations where the agent ends up firing off actions too frequently or on genuinely irrelevant or unimportant events, which could otherwise create unnecessary noise, unnecessary cost, or even actively unhelpful, unwanted behavior if the triggering and filtering logic isn't well designed and properly tuned to the specific situation.