Agentic AI Design Patterns Explained

Why Patterns Matter

Choosing the wrong pattern for a task is one of the most common reasons agent projects fail. A simple customer lookup does not need a multi-agent system with five specialist agents coordinating through a planner. A complex research task that spans multiple domains will not work with a single ReAct loop because the context window fills up before the work is done. The pattern determines the agent's behavior, its failure modes, its cost, and how much engineering you need around it. Understanding the patterns before you start building saves you from architectures that are either too simple to handle the task or too complex to maintain.

Andrew Ng popularized four foundational design patterns for agentic AI in his widely cited 2024 framework: Reflection, Tool Use, Planning, and Multi-Agent Collaboration. Since then, production experience has expanded the practical set to six by adding ReAct as a distinct pattern (not just tool use) and Router as a pattern that handles task classification and delegation without full multi-agent coordination. These six cover the space of agent behaviors you will encounter in production systems.

Pattern 1: ReAct (Reason + Act)

ReAct is the foundational agentic pattern and the one most developers encounter first. The model alternates between a reasoning step where it articulates its current understanding and plan, and an action step where it calls a tool. After each tool result, the model reasons again before taking the next action. This observe-think-act cycle repeats until the task is complete.

ReAct works best for tasks with 3 to 15 steps where the path depends on intermediate results. Research queries, customer service resolution, code debugging, and data analysis are all natural fits. The pattern's strength is that the reasoning trace is visible, making debugging and auditing possible. Its weakness is that it is greedy, reasoning about the immediate next step rather than planning the full sequence ahead of time, which can lead the agent down suboptimal paths when early decisions constrain later options.

In practical terms, every modern agent framework implements ReAct as the default loop. When you use LangGraph, CrewAI, or the OpenAI Agents SDK and your agent calls tools, you are running a ReAct loop whether or not you label it as such. The detailed guide to ReAct covers the pattern's mechanics, tuning, and failure modes.

Pattern 2: Reflection

Reflection adds an explicit self-evaluation step to the agent loop. After the agent produces output, whether that is a code solution, a research summary, or a customer response, a reflection step critiques the output, identifies weaknesses, and suggests improvements. The agent then incorporates that feedback and produces a revised version. This can happen once (single-pass reflection) or iterate multiple times until the output meets a quality threshold.

The pattern is especially valuable for tasks where quality is subjective or hard to verify automatically. Writing code that compiles is verifiable, but writing code that is clean, efficient, and handles edge cases requires judgment. Drafting a report that is factually accurate is one thing, but ensuring it is well-structured and clearly argued is another. Reflection gives the agent the ability to assess and improve its own work along these harder-to-measure dimensions.

There are two common implementations. In self-reflection, the same model that produced the output also critiques it, usually with a different system prompt that instructs it to be critical. In critic-agent reflection, a separate model or a separate agent with different instructions evaluates the output. The critic-agent approach tends to produce better critiques because the evaluator is not biased by having produced the original work. The deep dive on reflection covers both approaches with implementation examples.

Pattern 3: Planning

The Planning pattern separates plan creation from plan execution. The agent first analyzes the task and creates a structured plan, a list of steps, a dependency graph, or a tree of sub-tasks, before taking any actions. Then an executor processes each step, often using ReAct for individual step execution. The plan can be static (created once and followed rigidly) or dynamic (revised after each step based on intermediate results).

Planning is the right choice when the task has a known structure but variable data. Deploying a software release, processing a batch of documents, conducting a competitor analysis with a fixed methodology, these all have predictable steps even though the specific data changes each time. Planning is also better than pure ReAct for tasks where early decisions significantly constrain later options, because the planning step forces the agent to consider the full scope before committing to a path.

The main weakness of static planning is brittleness. If step 3 reveals that step 5 is unnecessary or that a new step is needed between 6 and 7, a rigid plan cannot adapt. Dynamic replanning, where the agent revises its plan after each step, solves this at the cost of additional model calls. The most effective production systems use a hybrid: plan at the start, execute with ReAct, replan when observations deviate significantly from expectations. The planning and reasoning guide walks through these architectures in detail.

Pattern 4: Tool Use Chaining

Tool Use Chaining is the simplest agentic pattern. The agent calls one tool, takes the result, feeds it to the next tool call, and chains a sequence of tool invocations to complete the task. Unlike ReAct, the chain is often partially prescribed by the developer rather than fully emergent from the model's reasoning. The model still decides parameters and handles edge cases, but the sequence of tools to call is known or heavily guided.

This pattern covers a large fraction of practical automation tasks. A workflow that fetches data from an API, transforms it, writes it to a database, and sends a notification is a tool chain. An agent that takes a customer question, looks up their account, checks their order status, and generates a response is a tool chain. The steps are predictable, the data is variable, and the model's job is to handle the variability rather than to invent the workflow.

Tool chaining is less autonomous than the other patterns, which is often an advantage. Because the flow is partially prescribed, there are fewer ways for the agent to go off track. It is also cheaper than ReAct because the reasoning overhead is lower, the model does not need to deliberate about what to do next when the next step is already determined. The AI tool use pillar covers the mechanics of defining tools, validating outputs, and building reliable chains.

Pattern 5: Multi-Agent Delegation

Multi-Agent Delegation splits a task across multiple agents, each with its own role, tools, and context. A coordinator agent receives the task, decomposes it into sub-tasks, and delegates each sub-task to a specialist agent. The specialists work independently (sometimes concurrently), and the coordinator synthesizes their results into a final output.

This pattern works well when the task naturally decomposes into independent domains. A content production pipeline might have a researcher agent, a writer agent, and an editor agent. A software development workflow might have a planner agent, a coder agent, and a tester agent. Each specialist has tools appropriate to its role, and its context window contains only the information relevant to its sub-task, which avoids the context overflow problem that plagues single-agent systems on complex tasks.

The trade-off is coordination complexity. Agents can produce inconsistent results when they make independent assumptions. The coordinator can misallocate tasks or fail to synthesize conflicting outputs. And the total cost multiplies because each agent runs its own model calls. Multi-agent systems are most justified when the task is genuinely too large or too diverse for a single agent to handle within its context window. For simpler tasks, a single agent with good tools is almost always more cost-effective and more reliable. The multi-agent systems page covers architectures, frameworks like CrewAI and AutoGen, and when the complexity is justified.

Pattern 6: Router

The Router pattern uses a lightweight classification step to direct incoming requests to the right handler, which might be a specialized agent, a simple tool chain, or even a direct model call. The router examines the input, categorizes it (customer billing question, technical support issue, feature request, general inquiry), and routes it to the handler best equipped for that category. Each handler can use a different pattern internally.

Routing is essential for production systems that handle diverse request types. A customer service system that uses the same agent loop for every request wastes resources on simple questions and lacks the specialization needed for complex ones. A router can send "what are your hours?" to a simple lookup and "my payment failed and I was double-charged" to a multi-step agent with access to billing APIs. This is both cheaper (simple questions use cheap handlers) and more reliable (each handler is optimized for its category).

The router itself is typically implemented as a single model call with a classification prompt, or as a function call where the model selects which "team" or "department" to route to. The latency cost is one additional model call, which is negligible compared to the efficiency gained by matching request complexity to handler complexity. In multi-agent frameworks, routing is often built into the orchestration layer, the orchestration patterns page covers how this works across different frameworks.

Combining Patterns

Production agents almost always combine multiple patterns. The most common combinations are:

Router + ReAct: Route requests to specialized ReAct agents. This is the standard architecture for customer service, internal helpdesk, and support ticket systems.

Planning + ReAct: Create a plan, then execute each step using a ReAct loop. This gives the agent both strategic awareness (from planning) and tactical flexibility (from ReAct). Code generation systems and research agents commonly use this combination.

ReAct + Reflection: Run a ReAct loop to produce output, then reflect on the quality and iterate. This is the standard pattern for content generation, code review, and any task where the first draft is rarely the final version.

Multi-Agent + Planning + ReAct: A planner creates sub-tasks, delegates them to specialist agents, and each specialist runs a ReAct loop. This is the architecture behind complex automation platforms like coding agents that plan features, implement code, write tests, and debug failures across multiple files.

The key principle for combining patterns is that complexity should match the task. Start with the simplest pattern that could work (usually ReAct or tool chaining), and add patterns only when you hit a specific limitation: the context overflows (add routing or multi-agent delegation), the output quality is inconsistent (add reflection), or the agent makes suboptimal early choices (add planning). The cost optimization pillar provides frameworks for evaluating whether the additional complexity of a combined pattern is justified by the improvement in results.