What You Will Learn

• Explain and apply the agentic loop (decide → act → observe → repeat)
• Map and choose among the 35 agentic patterns organized into eight families
• Design workflows for tool use, planning, reflection, and RAG retrieval
• Implement memory and skills patterns (episodic-semantic, Voyager, MemGPT)
• Use sampling, search, and multi-agent strategies (ToT, LATS, supervisor, blackboard)
• Build safety and guardrails: dry-run, capability routing, and safety gates

Study Guide

Introduction: Why Agentic Design Patterns Matter

You're about to learn something that most people in AI never quite grasp. It's not about prompting. It's not about which model is best. It's about the shape of the workflow itself. After running all 35 established agentic design patterns live, I can tell you this: the architecture determines the outcome far more than the model does. The same model that fails with a simple prompt can produce brilliant results when wrapped in the right pattern. And the same frontier model that seems magical can fail when you give it a shape that fights against it.

Here's the thing. There's a loop at the heart of every agentic system. 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. It's what separates a model from an agent. A model is a function. An agent is a system that iterates toward a goal.

What you're getting here is a complete map of the 35 patterns that matter, organized into eight families. I actually ran all of them, observed their behavior, and documented what works, what breaks, and where the pitfalls live. This isn't theory. This is what happens when you put these architectures into practice.

And here's the part that changes how you work: you don't always need to build these patterns from scratch. Just naming a pattern in a prompt to a capable coding agent can change its direction of travel. Tell Claude Code to "use reflection" and it starts critiquing its own output. Tell it to "use a supervisor agent" and it begins decomposing the work. This knowledge is operationally valuable even if you never write a line of harness code.

Let's get into it.

Part I: The Foundation , What Makes a Workflow Agentic

Before we dive into the patterns, you need to understand what you're actually looking at. Every agentic pattern is a graph of nodes with a control flow running through it. The nodes are operations: LLM calls, tool invocations, decision points, memory reads and writes. The control flow is how the system moves between these nodes. Linearly. In branches. In fan-out and aggregation patterns. Or in loops.

The loop is the defining feature. It's what makes a system agentic rather than just a single-pass model call. Here's the anatomy of that loop:

The model decides what to do next based on its current state and context. It acts by invoking a tool or performing a transformation. It checks the result against its objective or criteria. Then it repeats until the job is done or a stopping condition is met.

Now, why does shape matter so much? Two reasons. First, reliability. Weaker and smaller local models need structured shapes to compensate for their limited reasoning ability. Frontier models can carry reliability through raw capability. Smaller models need the architecture to enforce quality. The weaker models need the shape to carry the reliability that a frontier model gives you for free. Second, cost and latency. Some patterns use far more tokens than others. Reflection burns tokens. Ensembles burn tokens. Multi-agent systems burn tokens. If you pick a pattern that's more complex than the task requires, you're paying for reliability you don't need.

There's also a fundamental trade-off between flexibility and constraint. Open-ended patterns like Planning allow the system to adapt to unexpected information. Constrained patterns like Constitutional AI reduce the space of possible errors but also reduce adaptability. You need to understand this tension before you can choose wisely.

Part II: Family 1 , Tools and Actions

This is the foundational layer. Every agentic system that does anything in the real world starts here. The core idea is simple: the model needs to interact with external tools, APIs, and environments. The patterns in this family are the workhorses behind virtually every production agent.

Tool Use (Basic Function Calling)
The simplest agentic pattern. A user question goes to the agent. The agent produces a structured tool call. The tool executes and returns its output. The agent synthesizes a final response. There's no explicit reasoning step. The model jumps from question to action to answer.

Here's an example. The user asks: "Who is the current CEO of Microsoft?" The agent invokes a web search tool with the query "current CEO of Microsoft." The tool returns results. The agent synthesizes the answer from those results. Done. One tool call. One answer.

This pattern works for simple, factual queries where a single tool call suffices. But it has a ceiling. When the task requires multiple steps, or when the model needs to reason about what to do next, basic tool use falls short.

ReAct Loop (Reasoning + Acting)
This is the standard agentic loop. The one you'll see everywhere. ReAct makes thinking explicit by interleaving thoughts with actions. The flow goes: Thought → Action → Observation → Thought → Action → Observation → ... → Final Response.

The model generates an explicit thought about what it needs to know. Then it takes an action, which is a tool call. Then it observes the result. Then it thinks again. This cycle continues until the model has enough information to synthesize a final response.

Here's the same CEO question running through a ReAct loop. The agent generates a thought: "I need to find out who the current CEO of Microsoft is. I should search the web for this information." Then it calls the search tool. It observes the results. It generates another thought: "The search results indicate that Satya Nadella is the CEO." Then it synthesizes the final answer.

Why does this matter? Because explicit thinking before acting produces substantially better results than jumping directly to actions. The thought step forces the model to consider what it's doing and why. This is the workhorse behind most commercial coding agents, including Claude Code and Codex. If you're building an agent system, start here.

Planning Pattern
Planning decomposes a goal into an ordered list of steps, executes them one by one, and includes the ability to replan when intermediate results change the picture. This is for open-ended goals where the path isn't fully known in advance.

Here's a real example from my testing. I asked the agent to plan a three-day vegetarian-friendly itinerary for Tokyo on a $200-per-day budget. The agent output an initial five-step plan. But during execution, it encountered new information that required additional steps. Mid-execution, it added three more steps. The final execution had eight steps instead of five.

That's the power of planning. It's not a rigid sequence. It's a living document that adapts as new information emerges. This pattern is ideal for travel planning, project management, and multi-stage research tasks.

Plan-and-Execute with Verification (PEV Loop)
This extends the planning pattern by adding an impartial evaluator. The flow goes: Plan → Execute → Verify → If criteria not met → Fix → Re-verify → Finalize.

Here's how it works. A planning stage creates the steps. An execution stage carries them out. Then a separate agent , acting as an impartial evaluator , checks whether the output adheres to a predefined rubric or criteria. If the evaluation fails, the loop re-plans and re-executes.

The key insight here is that the evaluator is a different agent with a different system prompt. It's not self-critique. It's independent oversight. This matters when correctness is paramount and you can afford multiple passes. Use this for content generation with strict requirement compliance, report writing, and automated problem solving that must meet audit standards.

SWE-Agent (Software Engineering Agent)
This is a coding agent with access to a sandboxed file system. The flow goes: Agent decides → List files → Read files → Write files → Execute in sandbox → Verified output.

In my testing, the agent updated a file inside a sandbox environment to complete a coding task. It's a full software engineering workflow in an isolated environment. This pattern is for automated bug fixing, feature implementation, code refactoring, and repository-level tasks.

Browser Agent
Similar to the SWE-agent, but the tool is a browser automation interface like Playwright. The agent navigates to websites, extracts page content, and interacts with page elements. The flow goes: Agent decides → Triggers Playwright → Interacts with browser tabs → Extracts data → Response.

In my testing, the agent navigated to a specified website and extracted the main heading element. This pattern extends agent capabilities into the web domain. Use it for web scraping, form filling, website testing, and automated data collection from online sources.

Part III: Family 2 , Reasoning and Reflection

This family is the cheapest win for boosting output reliability. The core principle is simple: generate, critique, then refine. These patterns separate the generation phase from the evaluation phase, creating genuine adversarial distance that improves quality.

Reflection
Reflection uses a single model wearing two hats through two system prompts. The producer drafts an initial answer. The critic grades the answer on a scale, provides structured feedback, and hands it back. The draft is rewritten using that critique. The loop repeats until the score clears a target or the iteration limit is reached.

Here's an example from my testing. I gave the agent a calculation requiring logical reasoning. The generate stage produced its best answer. The critique stage scored it on a 1-10 scale and provided structured feedback. The draft was refined. The loop continued until the score passed the bar.

The important distinction here is that reflection uses separate system prompts for generation and evaluation. This creates genuine adversarial distance, even within the same model. Multi-agent variants use separate generator and evaluator models for even more distance.

Use reflection for any task requiring quality over latency. Complex calculations, mathematical reasoning, and highly polished writing all benefit. This is the pattern to reach for when your outputs contain errors and you need to boost reliability.

Reflection with Memory (Episodic Memory Integration)
This is a variation on standard reflection. Successfully solved tasks write a verbal lesson to episodic memory. Future attempts are informed by accumulated lessons from previous runs.

Here's how it works. The agent solves a task. It extracts a lesson from that experience. It stores the lesson in memory. The next time it encounters a similar task, it retrieves the lesson and applies it.

This enables improvement across trials. It's useful for tasks that repeat with variation. Continuous learning systems, adaptive question answering, and personalized assistants all benefit from this pattern.

Self-Discover
Instead of applying a fixed reasoning method, the agent composes its own reasoning recipe before solving. The flow goes: Select thinking modules → Adapt modules to the task → Assemble an implementation plan → Solve by following it.

The module library includes critical thinking, listing facts, considering analogies, step-by-step reasoning, reverse engineering, evaluating, devising algorithms, and more. The agent selects several modules, adapts them to the specific problem, composes them into a plan, and executes the plan.

Here's an example. Given a calculation requiring logical processing, the agent selected several modules, adapted them to the problem, composed them into a plan, and executed the plan to produce the output.

Use Self-Discover for unusual, novel problems where standard approaches don't apply. Complex puzzles and research questions benefit from this pattern.

Chain of Verification
This is a hallucination-reduction technique that verifies each claim independently. The flow goes: Draft baseline answer → Plan independent verification questions → Answer each question independently → Rewrite, keeping only claims that survived verification.

Here's an example. I asked the agent to name five novels by a particular author that won a particular award. The agent generated a baseline answer listing two books. It created a verification plan , a series of independent questions. It executed each verification. Then it revised the answer so that only verified claims remained.

The key insight is that each claim is verified independently. Errors cannot defend themselves because each claim is checked separately. This strongly reduces hallucinations in factual outputs, particularly for lists and citations.

Use Chain of Verification for fact-checking, bibliography generation, historical and legal citation systems, and encyclopedia-style content. If you need hallucination-free factual outputs, this is the pattern.

Constitutional AI
This is a variation on reflection that checks draft answers against an explicit rule list. The flow goes: Generate draft → Critique against rule list → Revise to fix failed rules → Repeat → Finalize.

Here's an example. I asked the agent "What is the best programming language?" , an intentionally opinionated question. The agent generated an answer: "Python." Then it critiqued the answer against rules such as: "Don't include political stances," "Cite or hedge appropriately," and "Be concise." Failed rules triggered revision.

The rules are user-defined, making this highly customizable. You can enforce style guides, tone-of-voice mandates, or brand guidelines. Use Constitutional AI for enterprise content generation with strict compliance, customer-facing copy that must adhere to legal disclaimers, and moderation systems.

Part IV: Family 3 , Retrieval-Augmented Generation (RAG)

This family bridges the gap between a generic chatbot and an agent that knows your organization's specific information. The unifying idea is simple: let the agent look things up externally, not just rely on training data.

Agentic RAG
The agent decides whether, when, and how many times to retrieve information. It can issue multiple retrieval tool calls against vector databases or hybrid search indexes before synthesizing a response.

Here's an example from my testing. I asked: "What propellant does the Fenix 2 engine use?" The agent triggered a retrieval tool. It received five relevant chunks from a knowledge base. It synthesized the answer: methylox, a mixture of liquid methane and liquid oxygen.

This is flexible and industry-standard for unstructured knowledge bases. PDFs, Word documents, and internal wikis all work. The agent may call the retrieval tool multiple times, try different tools, or query multiple knowledge bases before answering.

Corrective RAG
This adds a grading step that filters retrieved documents before generation. The flow goes: Retrieve → Grade each chunk → Discard irrelevant chunks → Take corrective action → Generate.

Here's how it works. After retrieval, each document is graded for relevance. Irrelevant documents are discarded before the answer is generated. The grading triggers corrective actions, such as routing to web search or re-querying a private knowledge base.

The key benefit is keeping the context window clean. Irrelevant chunks can pollute the context and distract the model. This pattern prevents that pollution. Use it in scenarios where retrieval quality is inconsistent or where noisy documents degrade answer quality.

Self-RAG
This uses reflection tokens to decide what to retrieve and what to keep. The flow goes: Question → Decide whether retrieval is needed → Retrieve → Emit reflection tokens for each chunk → Keep endorsed chunks → Generate answer.

Here's how it works. The model emits reflection tokens during retrieval and generation. For each retrieved passage, it evaluates whether the passage is relevant, supported, or useful. It only answers from passages that have been explicitly endorsed by these flags.

The model explicitly endorses or rejects each piece of evidence, making the reasoning auditable. Use this for high-accuracy retrieval tasks, customer support systems, and applications where hallucination control is critical.

Adaptive RAG
This classifies each incoming query to determine whether retrieval is needed and, if so, how complex the retrieval pipeline must be. The flow goes: Question → Classify query type → If simple: single-stage retrieval → If complex: multi-stage retrieval → Generate.

Here's an example. A simple factual question about the Fenix 2 engine propellant was classified as requiring only a single retrieval pass. A complex, multi-part question routed to a deeper multi-stage pipeline.

This optimizes cost and latency by matching retrieval depth to query complexity. It works well with smaller models that lack sophisticated tool-calling intelligence because the decomposition is explicit and prescriptive. Use it for production RAG systems with variable query difficulty and limited computational budgets.

Graph RAG
This builds a knowledge graph from the corpus and answers questions using pre-summarized community clusters. The ingestion flow goes: Ingest documents → Extract triples → Build knowledge graph → Detect communities of related entities → Pre-summarize each community.

The query flow goes: Question → Classify as local or global → Search local nodes or global communities → Build context → Generate response.

Here's an example from my testing. For a corpus about the Stardust launch, the graph contained entities like the "Fenix 2 engine," the relationship "powers," and the entity "first stage of Stardust 9." A query about the Fenix 2 engine targeted local nodes and returned this relationship context.

The answer came from a relationship chain: Fenix 2 engine → powers → first stage of Stardust 9. That's reasoning over relationships, not just raw chunks. Use Graph RAG for complex reasoning over interconnected facts, recommendation systems, and enterprise knowledge graphs.

One important note: graph construction happens at ingestion time, not query time. Kicking off ingestion while a query is being processed is not the intended production flow.

Part V: Family 4 , Memory

Memory is state that survives into the next session. It's what transforms a stateless model into something that remembers users across conversations. The patterns in this family differ primarily by what they store.

Episodic-Semantic Memory
This pattern stores two memory types simultaneously. Episodic memory saves entire past conversational turns, searchable verbatim. Semantic memory extracts facts from those turns into a graph of facts.

Here's an example. If a user says they run a Shopify store selling ceramics and have a $200 monthly budget, the fact "user sells ceramics on Shopify" is saved to the semantic graph. The entire turn is saved to episodic memory.

When asked "What is my favorite color?", the system retrieves both known semantic facts , favorite color is teal , and past episodes , a prior conversation about liking teal. It formulates the response from both sources.

There's a risk here. Loading too many past conversations into context can send the agent in the wrong direction. Recalling specific facts can be more powerful than loading conversational transcripts. This pattern reduces context pollution by prioritizing specific facts over lengthy conversation logs.

Graph Memory Agent
This is a close relative of episodic-semantic memory. It relies explicitly on a knowledge graph for storing and recalling facts rather than conversation transcripts. Facts are stored as entities and relationships, enabling structured retrieval.

Use this for applications requiring precise factual recall about users, domains, or projects.

Voyager (Agent Skills Library)
This is an early implementation of agent skills. The agent writes reusable Python scripts for recurring tasks and saves them to a skills library on disk. On subsequent requests for the same task, it executes the saved script instead of regenerating it.

Here's how it works. The user requests a task. The agent creates a Python script. It saves the script to a skills library. The next time the same task is requested, the agent retrieves and executes the existing script instead of generating from scratch.

The key benefit is speed. Tasks that recur become faster over time. This pattern dramatically increases speed and reliability for repetitive programmatic tasks. Use it for automating common data manipulations, code generation, and API integrations.

MemGPT (OS-Style Memory)
This models memory like an operating system's virtual memory. A small, always-in-context core memory holds critical state. A larger storage area is paged in and out of the context window as needed.

Here's the structure. Core memory holds the most important state. Storage holds everything else. When the model needs a fact that's not in core memory, it pages it in. When it needs to free up space, it pages facts out.

This is ideal for long-running chats that would otherwise overflow the context window. In production, memory management is usually achieved via context compaction or summarization rather than literal disk paging. Use it for very long conversations, persistent assistants, and systems that must handle unbounded conversation history.

Agent Workflow Memory
This extracts reusable procedural recipes from completed tasks. The flow goes: After each solved task → Mine reusable 3-6 step recipe from previous turns → Index the recipe → New tasks retrieve closest recipe → Follow it instead of starting from zero.

Here's an example. The Hermes agent regularly reviews recent conversation turns to identify procedural knowledge worth extracting as reusable skills. It stores these recipes and retrieves them when similar tasks arrive.

Just as semantic memory stores facts, workflow memory stores procedures. This is the foundation of modern agent skill systems. Use it for recurring business workflows, onboarding scripts, and automating repeated operational processes.

Part VI: Family 5 , Sampling and Search

These patterns apply when a single answer is not enough. You generate many candidates and pick the best one. The key difference between them is the method used to evaluate candidates.

Tree of Thoughts (ToT)
This explores multiple reasoning branches rather than a single chain. The flow goes: Generate N substantively different next thoughts → Score each → Prune to top-K → Expand deeper → Repeat → Best complete path wins.

Here's an example. For a logical calculation task, the model proposed two different reasoning next steps. An evaluator scored them on a strict 1-5 scale. The top-scoring thoughts were kept and expanded. Lower-scoring ones were pruned.

There's a known limitation here. LLM evaluators tend to produce mid-range scores. On a 1-5 scale, four appeared in five of six LLM calls in a single node during my testing. This reduces the discriminative power of the rubric. The score-flattening problem is real.

Use Tree of Thoughts for problems where the first idea is often wrong. Complex puzzles, planning, and multi-step reasoning tasks benefit from this pattern.

Monte Carlo Tree Search / Mental Simulation Loop
This generates candidate actions, simulates their effects, and scores each simulation. The flow goes: Generate candidate actions → Simulate each → Score → Decide → Execute.

Here's an example. For the Tokyo itinerary task, multiple candidate itinerary actions were generated, simulated, and scored. The same score-flattening issue appeared. The evaluator produced many fours.

Like Tree of Thoughts, this is constrained by the score-flattening problem. Use it for action planning, game-playing, and navigation tasks.

Ensemble Voting
Multiple independent LLM voters produce answers to the same question. Their outputs are aggregated. The flow goes: Task → N independent voters → Aggregate responses → Majority vote or weighted selection → Final answer.

Here's an example. Three voters , an analytical voter, a skeptical voter, and a pragmatic voter , each solve a logical calculation. Their responses are aggregated in an LLM call and one is selected.

This is a cheap reliability boost for short, factual questions. Errors in a single voter are unlikely to survive the aggregation. Use it for factual QA, classification, and high-stakes decisions where accuracy outweighs cost.

Self-Consistency
This is similar to an ensemble, but instead of varied personas, all calls use the same question with different reasoning paths. The flow goes: Question → N independent chains of thought → Majority vote on final answer → Response.

Here's an example. Several LLM calls each produce a different chain of thought to solve the same problem. The final answer is determined by majority vote on the final output.

This is simpler than ensemble voting. No persona separation. It relies on multiple chain-of-thought trajectories. Use it for arithmetic and logical reasoning, where multiple solution paths converge on the same result.

LATS (Language Agent Tree Search)
This applies Monte Carlo Tree Search over reasoning moves. The flow goes: Pick most promising leaf → Generate N substantively different next reasoning moves → Evaluate each with a rubric → Propagate reward up the tree → Prune unproductive branches → Loop.

Here's the evaluation difference. Unlike 1-5 rubrics, LATS uses true/false flags on discrete criteria. Is it making progress? Is it complete? Does it avoid loops? Is confidence high? This is less susceptible to score flattening because the criteria are structured and deterministic.

This is more robust than simple 1-5 scores. It's expensive but highly effective. Use it for hard search problems, game-like tasks, and research reasoning.

Part VII: Family 6 , Multi-Agent Systems

Multi-agent architectures have gone through waves of enthusiasm and consolidation. Early enthusiasm treated them as a solution to everything. The field later consolidated around single-agent context management. Now multi-agent systems are re-emerging for problems that genuinely benefit from specialization and isolated context windows.

The key principle: be specific and conservative about creating teams. Unnecessary agents simply burn tokens without improving outcomes.

Supervisor / Sub-Agent Pattern
A supervisor agent routes tasks to specialist agents, each with its own tools, context window, and persona. The flow goes: Task → Supervisor → Route to specialist → Collect contributions → Synthesize → Response.

Here's an example. A supervisor has a news specialist, a technical specialist, and a financial specialist. Each query is routed to the appropriate domain expert.

The key benefit is isolated context windows. Each specialist can maintain focused expertise without cross-contamination from other domains. Use this for customer support triage, multi-domain research, and complex content generation pipelines.

Blackboard Pattern
All cooperating agents share a single open workspace. The flow goes: Task → Shared workspace → Each round, every agent bids → Best bid writes to workspace → Loop until complete → Synthesize agent merges everything → Final answer.

Here's an example from my testing. Tasked to write a product tagline for a coffee shop, four agents participated: an optimist, a skeptic, a historian, and a quantitative analyst. Each placed a bid across multiple iterations, contributing to a shared blackboard. A synthesis agent merged all outputs into the final tagline.

This enables diverse perspectives to build on each other's work. Use it for ideation, marketing copy, report generation, and tasks that benefit from diverse expertise.

Meta-Controller (Router) Pattern
An outer router selects which agent or architecture handles a given task. The flow goes: Task → Meta controller → Route to appropriate agent architecture → Execute → Response.

Here's an example. The controller routes a task to the planning architecture. The planning agent then decomposes and executes the task step by step, just as in the standalone planning pattern.

This works especially well for smaller local agents because the router handles the task-architecture mapping. Use it for modular agent systems where different task types require different processing pipelines.

Debate Pattern
Multiple agents independently produce answers, then read each other's positions and argue across multiple rounds. The flow goes: Task → N agents answer independently → Each reads others' positions → Argue across R rounds → Judge or vote settles the disagreement → Final answer.

Here's an example. For the question "Will AI agents replace SaaS dashboards?", two agents argued opposing positions across multiple rounds before a judge voted.

This can surface and resolve ambiguity. Use it for decision support, policy analysis, and high-stakes judgment calls.

STORM (Multi-Angle Research System)
This generates a comprehensive article by simulating multiple perspectives. The flow goes: Topic → Spawn multiple personas → Each interviews the topic with pointed questions → Answers are grounded → An outline organizes results → Writer produces the article.

Here's an example. For an article on the rise of agentic AI, perspectives included a technological framing and a historical-social framing. Numerous questions were asked and answered, an outline was generated, and the writer produced the final piece.

This mimics the research process of a team of writers. It can scale to extensive, deep-dive research projects. Use it for research reports, article generation, literature reviews, and educational content synthesis.

Part VIII: Family 7 , Safety and Guardrails

In safety-critical applications, code , not the model , should make irreversible decisions. These patterns use hooks, deterministic checkers, and logic baked into the harness.

Dry Run Pattern
Nothing executes directly by the agent. The agent proposes. A simulator predicts. A reviewer approves. The flow goes: Agent proposes action → Simulator predicts effects → Reviewer approves or blocks → If approved: Execute → If blocked: Stop.

Here's an example from my testing. I asked the agent to delete all files in a particular folder on a production server. The agent proposed a shell command targeting that folder. The dry run generated predicted effects, an irreversibility metric, and safety concerns. This fed into an approval decision: execute or skip.

The destructive request was stopped at the review stage. Tools like Claude Code's harness implement similar deterministic and probabilistic checkers for tool calls before execution. If you're building an AI system with flexible tool calls and arbitrary shell command execution, this pattern is essential.

Capability Routing
The agent assesses its own competence before answering. The flow goes: Question → Agent assesses competence → If capable: answer → If uncertain: escalate to a human.

The decision is determined by what is available in context: system prompt, agent metadata, skills files. This protects against silent overreach. It ensures users are not misled by false confidence.

Use this for customer support bots, legal and medical advice systems, and any application where escalation to human experts must be seamless.

Computer Use with Safety Gate
A computer-use agent controls a graphical user interface through a strict loop. The loop includes a mandatory safety gate that evaluates each action for prompt injection or unsafe behavior before allowing it. The flow goes: Goal → Agent proposes GUI action → Safety gate evaluates action safety → If safe: Execute via GUI automation → Observe → Repeat → Done.

Here's an example. A prompt injection attempted to make the agent use computer-use tools to navigate to a phishing site. The safety gate evaluated the action as unsafe and blocked it.

The key insight: prompt injection resistance is not a model-level feature. It must be enforced at the architecture level. Use this for desktop automation, UI testing, and personal assistants that can click, type, and navigate.

Part IX: Family 8 , Specialty Patterns

Reinforcement Learning Self-Improvement
This specialty pattern iteratively improves short-form outputs through detailed, multi-dimension scoring. The flow goes: Generate candidates → Score against explicit dimensions with deterministic rubrics → Keep the best so far → Iterate → Finalize when threshold met.

Here's an example. Writing a product tagline. Each iteration evaluates the candidate on criteria such as: Is it on brief? Does it have concrete imagery? Does it avoid clichés? Is it engaging? The system iterates and refines until the overall score meets the threshold and all checks pass.

Unlike generic 1-5 scores, the detailed multi-dimensional critique provides richer feedback. This is especially effective for optimizing short artifacts like taglines or copy. Use it for brand messaging, advertising copy, naming, and other creative tasks where small improvements matter.

Part X: How to Select the Right Pattern

You now have the complete map. But knowing the patterns isn't enough. You need to know which one to reach for, and when. This is where most people go wrong. They overcomplicate it. They build elaborate multi-agent systems when a simple ReAct loop would do.

The most important practical rule: reach for the smallest shape that actually works. Many patterns constrain the system, reducing flexibility. Complexity should be added only when a simpler approach demonstrably fails.

Here's a decision ladder that will guide you through most situations.

Start with a standard ReAct loop with tool calling. This suffices for a large majority of use cases. If quality is not high enough, add reflection. Introduce critiquing and adversarial prompting. If steps are genuinely unknown up front, add planning. If work is truly parallel or requires genuine specialists, build a multi-agent team on top. If safety is a concern, add dry-run validation, capability routing, and safety gates regardless of the other patterns in use.

Here's the thing about prompting. Prompting will only get you so far. You do need certain shapes if you want to get reliable outcomes from these systems. But merely naming a pattern in a prompt to a capable coding agent can redirect its approach. This demonstrates that knowledge of these patterns is operationally valuable even when you're not building a harness from scratch.

Let me give you a concrete example. You're using Claude Code to fix a bug. You could just ask it to fix the bug. Or you could say: "Use a planning agent with replanning to fix this bug." Or: "Critique your output before sending." The pattern name changes the direction of travel. The agent starts decomposing the task differently. It starts evaluating its own work.

For smaller or local models, the pattern itself often carries the reliability that frontier models provide natively. This makes this knowledge essential for cost-constrained or privacy-sensitive deployments. If you're running a small model for privacy reasons, you need the shape to do the heavy lifting.

Let me walk you through some matching scenarios.

If your agent needs external tools, start with Tool Use or ReAct. If it's a multi-step goal with unknown steps, use Planning or the PEV Loop. If you're dealing with hallucination-prone factual output, reach for Chain of Verification, Self-RAG, or Corrective RAG. If you have custom constraints on output, use Constitutional AI or Reflection. For private knowledge answering, Agentic RAG, Graph RAG, or Adaptive RAG. For recurring tasks, Voyager skills or Agent Workflow Memory. For long-running personalization, Episodic Semantic Memory or MemGPT. For hard reasoning or puzzle solving, Tree of Thoughts, LATS, or the Mental Simulation Loop. For reliability on short factual queries, Ensemble or Self-Consistency. For deep research synthesis, STORM. For parallel specialist execution, Supervisor or Blackboard. For safety-critical automation, Dry Run, Computer Use with Safety Gate, or Capability Routing. For high-quality short copy, RL Self-Improvement.

Part XI: Key Insights from Running All 35 Patterns

I ran all 35 patterns. I watched them succeed. I watched them fail. And I learned some things that aren't obvious from reading about them.

The loop is the heart of agency. The decision-action-observation cycle is what separates a model from an agent. Most of the 35 patterns are variations on this loop. Once you see this, you stop thinking of patterns as separate things and start seeing them as different arrangements of the same fundamental mechanism.

Patterns are workflow shapes, not rigid frameworks. They can chain together, branch, and fan out. You don't need to memorize them. You only need to understand which shape fits the job. When you understand the shape, you can combine patterns in ways that weren't documented anywhere.

Reach for the smallest pattern that works. A standard ReAct loop is often sufficient. Add complexity only when quality or safety demands it. This is the single most important principle in this entire guide. It will save you from wasting tokens on unnecessary complexity.

Naming a pattern in a prompt can steer commercial agents. Practitioners can improve output from coding tools like Claude Code, Codex, and Hermes by explicitly requesting a known pattern. Just saying "use reflection" or "use a supervisor agent" changes the behavior.

Smaller and local models need patterns to compensate for capability gaps. A well-chosen workflow shape can supply the reliability that a frontier model provides natively. This is why this knowledge matters even if you're not using frontier models.

Retrieval patterns are not one-size-fits-all. The choice between Agentic RAG, Corrective RAG, Self-RAG, Adaptive RAG, and Graph RAG depends on the quality of the corpus, the model size, and the complexity of queries. There's no universal best. There's only the right fit for your situation.

Memory patterns differ by what they store. Semantic facts go in graphs. Episodic turns go in conversation logs. Procedural recipes go in skills. Operating-system-style paging handles long-running sessions. Each serves a different use case.

Multi-agent systems should be used conservatively. Create a team only when tasks are genuinely parallel, require specialized personas, or need adversarial debate. Otherwise, you're wasting tokens. I saw this firsthand. Some of the most expensive runs produced the worst results because the team architecture wasn't justified by the task.

Safety must be deterministic. For irreversible actions, code-based checks must supplement or override model judgment. Dry runs, capability routing, and safety gates are not optional. They're the difference between a system that fails safely and one that causes real damage.

Quality gains require explicit evaluation. Reflection, Chain of Verification, and Constitutional AI improve reliability by separating generation from critique. The separation is what creates the quality gain. Self-critique in a single pass is much weaker.

Score-flattening is a real limitation. LLM-based scoring on simple numeric scales tends to cluster around mid-range values. Use structured true/false flags and detailed rubrics for better selection. This is why LATS outperforms Tree of Thoughts in many scenarios. The evaluation method matters as much as the search strategy.

Part XII: Practical Applications Across Domains

These patterns aren't academic exercises. They have direct applications across multiple domains. Let me show you where they fit.

Software Engineering and Coding Agents
Developers using tools like Claude Code, Codex, or Hermes can name patterns in their prompts to steer behavior. Say "use a planning agent with replanning" or "critique your output before sending." Engineers building custom coding harnesses can implement SWE-agent or Browser-agent patterns to manage files and web interactions.

Here's a real scenario. You're using a coding agent to refactor a large codebase. Instead of just asking for the refactor, you say: "Use a planning agent. Decompose the refactor into steps. Replan if you encounter unexpected dependencies." The agent changes its approach. It starts by listing files, understanding dependencies, and creating a step-by-step plan before making any changes.

Business Workflow Automation
Every modern automation workflow is secretly one of these shapes. Designers can map their processes to patterns instead of reinventing the wheel. Use supervision for task routing. Use a blackboard for collaborative ideation. Use dry-run safety for production changes.

Here's a scenario. You're automating a customer onboarding process. The workflow has multiple stages: data collection, verification, document generation, and notification. That's a supervisor pattern. Each stage is a specialist agent. The supervisor routes the customer through the stages.

Enterprise Knowledge Systems
Retrieval patterns are foundational for building customer support chatbots, internal knowledge assistants, and legal and financial research tools. Graph RAG is particularly suited for domains requiring relationship-aware reasoning, such as due diligence and compliance.

Here's a scenario. You're building a support bot for a manufacturing company. The knowledge base includes technical specs, maintenance manuals, and troubleshooting guides. Agentic RAG lets the bot decide when to retrieve. Corrective RAG filters out irrelevant documents. Self-RAG ensures only supported claims reach the customer.

Product and Policy Development
Decision-makers can use Debate and STORM patterns to generate balanced multi-perspective policy briefs. The safety patterns provide a framework for designing ethical guardrails in autonomous systems.

Here's a scenario. You need a policy brief on AI regulation. You use STORM. It spawns personas representing different stakeholders: industry, consumer advocates, regulators, academics. Each persona interviews the topic. The writer synthesizes a comprehensive brief that covers all perspectives.

Education and Training
Educators can teach these patterns as a taxonomy of agentic design. This gives students a structured vocabulary for describing and comparing AI systems. The patterns serve as excellent case studies in human-centered AI design, especially regarding reliability, transparency, and accountability.

Edge and Local Deployments
Organizations running small local models for privacy, cost, or latency reasons can use these patterns to maintain output quality. The shape carries the reliability that frontier models provide natively. This enables safe, predictable behavior without frontier-scale models.

Part XIII: Action Items for Practitioners

You've absorbed a lot. Now let's turn it into action. Here are concrete steps you can take to apply these patterns immediately.

Inventory your existing AI workflows. Identify the implicit pattern behind each automation or agent you already run. Name it using the taxonomy in this guide. You'll be surprised how many of these shapes you're already using without knowing it.

Start with a ReAct baseline. For any new agent task, implement a simple ReAct loop with tool calling. Measure performance before adding complexity. This gives you a baseline to compare against.

Add reflection when quality is insufficient. If outputs contain errors, introduce a generate-critique-refine cycle. Use structured rubrics rather than 1-10 scores to avoid score-flattening.

Implement retrieval early for domain-specific systems. Choose the simplest retrieval pattern that meets your data and model constraints. For high-volume and factual applications, Chain of Verification or Corrective RAG are recommended starting points.

Build a safety layer for any agent that touches production systems. Integrate a dry-run or approval step for destructive actions. Route requests beyond an agent's competence to human operators.

Use memory strategically. Deploy episodic-semantic memory for personalized assistants. Use workflow memory for recurring business processes. Use MemGPT-style compaction for long-running chat sessions.

Experiment with multi-agent designs sparingly. Before spawning a team, confirm the task benefits from parallel execution, diverse perspectives, or adversarial debate. Otherwise, a single well-prompted agent may suffice.

Create an internal pattern library. Document each pattern your team uses, with examples and benchmarks. Make it accessible to all developers working on AI systems.

Train teams on the taxonomy. A shared vocabulary for patterns improves communication across engineering, product, and design teams. When everyone says "reflection" and means the same thing, collaboration gets easier.

Adopt a "smallest shape" review policy. During architecture reviews, require justification for every added layer of complexity. This will keep token costs low and systems maintainable.

Conclusion: The Shape of Things That Work

You now have the complete map of agentic design. Thirty-five patterns. Eight families. One underlying principle that ties them all together: the loop of decide, act, check, and repeat.

The power of these patterns lies in their reusability and transferability. They enable consistency across different AI tools and platforms. They allow developers to steer commercial agents through prompt-level instruction. They provide a safety net for smaller models that lack native frontier capability.

Don't overcomplicate it. The guiding principle is simple: choose the smallest shape that solves the problem effectively. A ReAct loop is usually enough. Reflection, planning, retrieval, memory, and team-based architectures are incremental upgrades for increasingly complex demands.

Here's what I want you to remember above all else. 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.

As AI agents continue to move from experimentation into production, familiarity with these patterns will be a distinguishing skill for engineers, architects, and organizations. This guide is your foundation. The next step is practice.

Start with one pattern. Run it. Break it. Fix it. Then move to the next. The only way to truly understand these shapes is to watch them work in your own systems, with your own data, on your own problems.

The patterns are the map. Your experience is the territory. Go explore.

Frequently Asked Questions