Agent Design Patterns: A Practical Guide to Building Reliable AI Agents

What Are Agent Design Patterns?

Most AI agents that fail in production do not fail because the model is weak. They fail because the system around the model is unstructured, so the agent answers from stale knowledge, acts on a tool result it never checked, or takes an irreversible step that no one approved.

Agent design patterns are the accumulated engineering response to those failures, and each pattern exists to close off a specific one. They are also the difference between a demo and a system you can actually ship, which is why production AI agents are built with evals, observability, and guardrails rather than patterns alone.

This guide walks through the patterns that make up the working vocabulary of agent engineering, grouped into the two families that the field has settled on. For each pattern you will find the failure it addresses, the situations that call for it, a working Python example, and the trade-offs that surface once the system is live. A decision framework near the end pulls the whole set into a single lookup you can reach for while debugging.

Agent design patterns are reusable architectural approaches for structuring how an AI agent reasons, uses tools, coordinates with other agents, and recovers from its own errors. Put simply, a pattern is a repeatable way of shaping an agent's control flow so that it produces reliable results under real conditions.

A pattern describes the shape of a solution rather than any particular library, so it stays independent of the framework you build in. The same Reflection pattern can be implemented in LangGraph, CrewAI, the OpenAI Agents SDK, or plain Python without changing what makes it Reflection.

A raw language model call, on its own, has three limitations that patterns exist to fix.

• No memory of its last action, so it cannot build on what it just did.
• No way to verify its own output, so a confident wrong answer passes straight through.
• No mechanism to act and adjust, so it cannot take a step, observe the result, and decide what to do next.

Supplying that missing structure is exactly what a pattern does. It turns a text generator into a system that can plan, act, check its own work, and hand it off to a specialist when it reaches the edge of its competence.

Agents vs. Workflows

The first design decision is whether you need an agent at all. An AI workflow runs language models and tools through predefined code paths that you control, while an agent hands the model authority over its own process and its own tool calls at runtime. The difference comes down to who decides what happens next.

• Use a workflow when you already know the sequence of operations. Its steps are fixed in advance, which makes it the more predictable and cheaper of the two.
• Use an agent when the path cannot be determined ahead of time and the model has to decide what to do from what it observes as it goes.

In practice, most production systems are workflows with a few agentic steps rather than fully autonomous agents. Treating autonomy as something you add only where the task truly demands it is what keeps them reliable.

The Two Families of Patterns

The patterns in circulation split into two families that grew out of two different communities. Understanding both is what lets you reach for the pattern a problem actually needs rather than the one you happen to know.

• Reasoning patterns describe how a single agent thinks. This family covers Reflection, Tool Use, ReAct, Planning, and Evaluator-Optimizer, and it comes out of the research and applied-AI community. These patterns answer how one agent produces a good result.
• Orchestration patterns describe how multiple agents coordinate. This family covers Sequential, Concurrent, Routing and Handoff, Group Chat, Magentic, and Custom Logic, and it comes largely from the cloud providers. These patterns answer how a team of agents divides its labor.

One pattern belongs to neither family exclusively. Human-in-the-Loop can sit inside a single agent's loop or between agents in an orchestration, so it spans both.

Reasoning and Single-Agent Patterns

These patterns govern the behavior of a single agent, and they serve as the building blocks for everything above them. A multi-agent system is ultimately assembled from individual agents that each rely on these patterns internally.

Reflection

Reflection gives an agent the ability to evaluate its own output before returning it. Instead of trusting the first response, the agent generates a draft, critiques that draft against explicit criteria, and revises based on its own feedback. The loop runs through generate, reflect, and revise, and it repeats until the output passes or a maximum number of iterations is reached.

def reflect_and_revise(prompt, generate, critique, max_iterations=3):
    draft = generate(prompt)
    for _ in range(max_iterations):
        feedback = critique(draft)
        if feedback.approved:
            return draft
        draft = generate(prompt, revision_feedback=feedback.notes)
    return draft

What it addresses is the plausible but flawed first draft that a single pass so often produces, the answer that reads well and happens to be wrong. Reflection reduces hallucination and deepens reasoning, and it justifies its added cost on tasks where accuracy carries more weight than speed. Feeding the critic an external signal, such as the output of a linter, a test run, or a database query, improves results far more than asking the model to critique itself in a vacuum.

The cost is the catch worth watching. Every reflection cycle adds at least two model calls, so it pays to cap the iterations and reserve the pattern for outputs where a mistake would be expensive to ship.

Tool Use

Tool Use lets an agent call external functions, APIs, and data sources so that it can read live information and take real actions. It is the foundational pattern of the set, because without it an agent can only produce text from what it already knows. With it, the agent can query a database, hit a pricing API, send an email, or write to a file.

tools = [get_customer_by_id, get_order_status, send_refund]

response = client.messages.create(
    model="claude-sonnet-5",
    tools=tools,
    messages=[{"role": "user", "content": "Where is order #4821?"}],
)

for block in response.content:
    if block.type == "tool_use":
        result = call_tool(block.name, block.input)
        # verify before the agent acts on it — never trust a tool result blindly
        if not is_safe(result):
            raise ToolResultError(f"Untrusted result from {block.name}")

The problem it addresses is the closed-book answer drawn entirely from training data that may be months out of date, with no ability to act on anything in the world beyond producing text. The Model Context Protocol has become the common standard for connecting agents to tools and data, which lets a tool be swapped without rewriting the agent that depends on it.

Reliability is where the pattern demands care, since every tool introduces a fresh failure surface. The practical response is to favor tools that are observable and straightforward to debug, and to treat the result of every tool call as something to verify before the agent acts on it.

ReAct

ReAct interleaves reasoning and acting in a single loop. The agent thinks about what to do, takes an action such as a tool call, observes the result, and then reasons again with that new information in hand. This cycle of thought, action, and observation repeats until the agent has gathered enough to answer.

def react_loop(question, tools, max_steps=6):
    scratchpad = []
    for _ in range(max_steps):
        thought, action = think(question, scratchpad)
        if action.name == "finish":
            return action.input
        observation = tools[action.name](action.input)
        scratchpad.append((thought, action, observation))
    raise StepLimitExceeded(question)

ReAct is the most common pattern in production precisely because it adapts to each observation as the work unfolds. It answers the brittleness that undermines fixed plans, which break the moment reality diverges from the assumptions baked into them. A ReAct loop absorbs that divergence by reconsidering its next move after every observation.

The runaway loop is the hazard to guard against, because a ReAct agent left without a step cap can cycle indefinitely and burn through credits before it returns anything, which makes a hard bound on iterations essential.

Planning

Planning has the agent decompose a complex goal into an ordered set of subtasks before execution begins, then work through them in sequence. It separates the thinking about what to do from the doing of it, which makes long-running, multi-step work transparent and controllable.

def run_plan(goal, planner, executor, evaluator):
    plan = planner.decompose(goal)
    for step in plan.steps:
        result = executor.run(step)
        verdict = evaluator.check(step, result)
        if not verdict.passed:
            plan = planner.replan(goal, plan, failed_step=step, reason=verdict.reason)
    return plan

It addresses the way an agent loses the thread on a task whose steps depend on one another, drifting off course somewhere in the middle. Producing an explicit plan first gives the system a structure it can follow, measure progress against, and revise when circumstances change. Planning pairs naturally with Reflection, where an evaluator reviews progress and returns the plan for revision when a step fails.

Rigidity is the price of the structure, since a plan fixed at the outset can go stale as the agent learns more about the task. Long-running planners answer this by building in a re-planning step, revisiting the plan as new information arrives instead of following the original one to a dead end.

Evaluator-Optimizer

Evaluator-Optimizer, also called the generator-critic pattern, splits the work between two roles. A generator produces output, and a separate evaluator scores it against defined criteria before either approving it or returning it with feedback for another pass. It is Reflection made explicit and structured, with the critic often given different instructions or even a different model than the generator.

def generate_and_score(task, generator, evaluator, max_rounds=3, min_score=0.9):
    output = generator.run(task)
    for _ in range(max_rounds):
        verdict = evaluator.score(task, output)
        if verdict.score >= min_score:
            return output
        output = generator.run(task, feedback=verdict.feedback)
    return output

It targets quality drift on outputs that must clear a strict bar, whether code that has to compile, a summary that has to be factually accurate, or content that has to conform to formatting rules. Separating the act of generation from the act of evaluation tends to surface errors that a single agent grading its own work quietly overlooks.

The trade-off mirrors Reflection's, adding calls, latency, and cost with each round, which makes it a sound investment wherever correctness is worth the overhead it demands.

Multi-Agent Orchestration Patterns

Once a task grows too large or too varied for one agent, the work is split across several specialized agents. Orchestration patterns describe how those agents are wired together, and they are the backbone of any multi-agent system that has to run reliably in production. This vocabulary comes largely from the cloud providers, and Google Cloud, Microsoft Azure, and AWS each publish their own version of it.

Sequential

In the sequential pattern, agents are arranged in a fixed linear pipeline, where each agent's output becomes the next agent's input. The order is decided at development time and does not change while the system runs. A content pipeline where a research agent gathers sources, a drafting agent writes, and an editing agent polishes is a textbook sequential flow.

Sequential orchestration reduces latency and cost compared with using a model to decide the order, because the structure is hardcoded and no orchestration reasoning is required. The price of that efficiency is flexibility, since the rigid pipeline cannot skip steps or adapt to conditions it did not anticipate.

It fits any case where the steps are known in advance and run in the same order every time.

Concurrent

The concurrent pattern, also called parallel or scatter-gather, runs multiple agents on the same input at the same time and then merges their outputs. Analyzing a contract for legal, financial, and compliance risk with three specialists at once, then combining their findings, is a natural fit for it.

Its purpose is to eliminate the wasted time of processing independent subtasks one after another. Where the subtasks carry no dependency on one another, running them together cuts wall-clock time sharply, at the cost of a spike in resource use and token consumption as several agents invoke the model in the same moment.

It suits work whose subtasks are genuinely independent and where latency is worth spending resources to reduce.

Routing and Handoff

Routing sends an incoming request to the right specialist. A dispatcher classifies the input and forwards it to the agent best equipped to handle it. Handoff extends this idea by letting an active agent transfer full control to another agent partway through a task, as when a triage agent passes a billing question to a billing specialist once the nature of the request becomes clear.

It answers the familiar weakness of the generalist that handles every kind of request with the same mediocre competence. Routing keeps each request with an agent equipped for it, and when the classification is deterministic and rule-based, a simple classifier suffices. A full handoff mechanism becomes necessary only where the right specialist reveals itself during the conversation, once the agent has learned enough to know it is out of its depth.

Handoff carries its own hazard in the bouncing loop, where control ping-pongs between agents without ever resolving the request, which is why a workable implementation caps the number of handoffs and logs each transfer for later inspection.

Group Chat

In the group chat pattern, several agents share a single conversation and contribute in turn, often coordinated by a manager agent that decides who speaks next. It suits problems that benefit from collaboration and debate, such as a design discussion where a product agent, an engineering agent, and a security agent each weigh in on the same proposal.

It addresses the blind spot that a single perspective inevitably carries, since several agents holding different roles will surface considerations one agent working alone would never raise. The cost is measured in tokens and in control, because an unmanaged conversation tends to drift, which is why a moderator agent or a turn limit is almost always part of a workable design.

Magentic

The magentic pattern, derived from Microsoft Research's Magentic-One system, is built for open-ended problems that have no predetermined plan. A manager agent maintains a task ledger and a progress ledger, directs worker agents such as a web browser, a coder, and a file reader, and re-plans dynamically when progress stalls. The plan is built and refined as part of the work itself rather than fixed at the start.

It exists for the task too open-ended for any fixed pipeline, where the approach itself has to be discovered in the course of the work. Its cost is unpredictability, since the manager continues iterating until it arrives at a viable plan, which leaves total spend hard to forecast and makes magentic the most expensive and most variable pattern to run.

Custom Logic

The custom logic pattern is the escape hatch for workflows that mix patterns and need fine-grained control. A refund flow might run a parallel eligibility check, then branch on the result into two entirely different downstream processes, one for approved refunds and one for store credit. That kind of conditional, mixed-pattern routing does not fit any single structured pattern, so it is written out as explicit logic.

Reserve it for workflows that genuinely resist the standard patterns and require direct control over the execution path. It belongs at the end of the decision process rather than the start, because a custom flow surrenders the predictability that the named patterns are designed to provide.

Human-in-the-Loop

Human-in-the-Loop inserts a human checkpoint into an agent's execution. It shows up as an observer in a group chat, a reviewer in an evaluator loop, or an approval gate placed before a sensitive action such as issuing a refund or sending an external email. It belongs to neither family exclusively, because the checkpoint can live inside a single agent's loop or between agents in an orchestration.

The two design questions worth settling early are where to place the gates and how strict to make each one. A mandatory gate makes the workflow synchronous at that step, so state has to be persisted at the checkpoint to resume without replaying prior work. A useful refinement is to scope gates to specific tool calls rather than whole agent outputs, so the system runs autonomously for low-risk actions and pauses only for operations that carry real consequences.

This matters most in enterprise and regulated systems, where an approval gate on a high-stakes action is often a compliance requirement rather than a convenience.

How the Major Providers Frame These Patterns

The three large cloud providers publish overlapping but differently named taxonomies, which is why the same concept turns up under several labels across the field. Knowing how they map onto one another helps a great deal when you move between their documentation. The differences are mostly in the naming rather than the underlying ideas.

• Google Cloud frames its patterns around the shape of the workflow, naming sequential, parallel, loop, review and critique, and a custom logic pattern for mixed flows.
• Microsoft Azure names five orchestration patterns, which are sequential, concurrent, group chat, handoff, and magentic.
• AWS documents an agentic pattern set through its prescriptive guidance, covering the reasoning patterns alongside multi-agent orchestration.

Underneath all three sits the reasoning-pattern vocabulary of Reflection, Tool Use, Planning, and Multi-Agent Collaboration, popularized in the applied-AI community, since every orchestrated agent uses those patterns internally.

The practical takeaway is that the labels differ while the underlying set stays small and stable. A parallel pattern and a concurrent pattern name the same construct, as do a review-and-critique pattern and an evaluator-optimizer pattern.

Choosing the Right Pattern

The reliable way to choose is to start from the failure you are seeing, or expect to see, and pick the pattern that addresses it. The table below works as a lookup while you debug.

The governing principle is to start with the simplest combination that addresses your core failure mode, then add patterns only when you have specific evidence that a simpler setup is falling short.

Every pattern you add carries a cost in latency, tokens, and complexity. Sequential and handoff patterns accumulate cost step by step, concurrent patterns raise peak resource use, and magentic remains the hardest to predict because the manager iterates until it settles on a plan.

The discipline the framework enforces is fitting the pattern to the problem in front of you and resisting the pull toward architecture more elaborate than the task warrants.

Symptom or need	Pattern to reach for
Agent answers from stale knowledge or cannot act	Tool Use
Output is a plausible but flawed first draft	Reflection
Rigid plans break when reality differs	ReAct
Complex goal with many dependent steps	Planning
Output must meet a strict quality bar	Evaluator-Optimizer
Fixed sequence of known steps	Sequential
Independent subtasks where latency matters	Concurrent
Different requests need different specialists	Routing and Handoff
Problem benefits from multiple perspectives	Group Chat
Open-ended problem with no fixed plan	Magentic
A sensitive or irreversible action	Human-in-the-Loop
Mixed patterns and conditional branching	Custom Logic

Combining Patterns in Production

Real systems stack patterns rather than relying on any one of them. A business intelligence reporting agent shows how several fit together, with each pattern handling one part of the job.

• Planning decomposes the quarterly analysis into an ordered set of subtasks.
• Tool Use pulls the underlying data from several sources.
• A multi-agent structure divides the work among an analyst, a visualization agent, and a summary writer.
• Reflection fact-checks the draft before it goes out.
• Human-in-the-Loop secures final sign-off from the client.

Five patterns operate here, each answering a distinct failure, composed into a single workflow whose reliability comes from the composition rather than from any individual piece. This is the shape most real agentic workflow automation takes, where several patterns stack to replace a manual process end to end. Holding a composite system like this together takes two things beyond the patterns themselves.

The first is shared state and memory, a place where agents read and write context so that a handoff does not lose everything the previous agent learned. The second is observability, the ability to trace which agent did what and why, without which a multi-agent system becomes nearly impossible to debug. Frameworks that persist state durably and expose the execution trace are worth their setup cost once more than two or three agents are involved.

Frequently Asked Questions

What are the four core agentic design patterns?

The four foundational patterns are Reflection, Tool Use, Planning, and Multi-Agent Collaboration. Most expanded lists add ReAct, Evaluator-Optimizer, and Human-in-the-Loop to reach a set of seven.

What is the difference between an agent and a workflow?

The dividing line is who decides the next step. In a workflow the developer fixes the path in code, while in an agent the model decides at runtime based on what it observes. A quick test is to ask whether you can draw the full flowchart before the system runs. If you can, you have a workflow, and you should generally prefer it for the predictability it gives you.

Are agentic design patterns and agent design patterns the same thing?

Yes. The variation is only in phrasing, and it exists because the reasoning-pattern vocabulary and the cloud-provider orchestration vocabulary grew up in separate communities before converging on the same underlying set.

Which pattern should I start with?

Start with Tool Use in almost every case, since an agent that cannot read live data or take action is barely an agent at all. From there a single ReAct loop handles most tasks, and you layer on further patterns only when a specific failure forces the question.

What patterns do Google, Microsoft, and AWS use?

The labels differ, but the set overlaps heavily. Microsoft names sequential, concurrent, group chat, handoff, and magentic. Google frames its patterns around workflow shape, including sequential, parallel, loop, and review and critique. AWS documents both the reasoning patterns and multi-agent orchestration in its prescriptive guidance.

Is there a book on agent design patterns?

Yes. Antonio Gulli's book Agentic Design Patterns is a widely referenced treatment of the subject, and several providers publish downloadable PDF guides that cover the same patterns.