This document provides guidance to help you choose a design pattern for your agentic AI system.Agent design patterns are commonarchitectural approaches to build agentic applications. An agent design patternoffers a distinct framework for organizing a system's components, integrating themodel, and orchestrating a single agent or multiple agents to accomplish aworkflow.

AI agents are effective for applications that solve open-ended problems, which might requireautonomous decision-making and complex multi-step workflow management. Agentsexcel at solving problems in real-time by using external data and they excel at automatingknowledge-intensive tasks. AI agents are suitable when you need AI to completegoal-focused tasks with some degree of autonomy. For other use cases, you canuse assistive and generative AI applications. To learn about the differencesbetween AI agents and non-agentic AI applications, seeWhat is the difference between AI agents, AI assistants, and bots?

This guide assumes that you have a foundational knowledge of agentic AI systemsand how their architecture differs from that of non-agentic systems, such asthose that use direct model reasoning orretrieval-augmented generation (RAG).

For a summary of the agent pattern guidance, see thecompare design patterns section later in this document.

Overview of the design process

The following are the high-level steps to choose a design pattern for your agentic AI system. These steps are described in detail later in this document.

1. Define your requirements: Assess the characteristics of your workload, including task complexity,latency and performance expectations, cost budget, and the need forhuman involvement.
2. Review the common agent design patterns:Learn about the common design patterns in this guide, which include bothsingle-agent systems and multi-agent systems.
3. Select a pattern:Select the appropriatedesign pattern based on your workload characteristics.

This process isn't a one-time decision. You should periodically revisit thesesteps to refine your architecture as your workload characteristics change, yourrequirements evolve, or new Google Cloud features become available.

Define your requirements

The questions that follow aren't exhaustive checklists for planning. Use thesequestions as a starting point to identify the primary goal of your agenticsystem and to select the best design pattern.

• Task characteristics: Can your task be completed in predefinedworkflow steps or is the task open-ended? Does your task need to use an AI model toorchestrate the workflow?
• Latency and performance: Do you need to prioritize fast or interactiveresponses at the cost of accuracy or high-quality responses? Or can yourapplication tolerate a delay to achieve a more accurate or thorough result?
• Cost: What is your budget for inference costs? Can yousupport patterns that require multiple calls to the model for a single request?
• Human involvement: Does your task involve high-stakes decisions,safety-critical operations, or subjective approvals that require human judgment?

If your workload is predictable or highly structured, or if it can be executed with asingle call to an AI model, it can be more cost effective to explore non-agenticsolutions for your task. For example, you might not need an agentic workflow fortasks like summarizing a document, translating text, or classifying customerfeedback. For information about choosing architecture components for generativeAI applications that don't require an agentic infrastructure, seeChoose models and infrastructure for your generative AI application.

The following sections describe common agent design patterns for building areliable and effective agentic AI system.

Single-agent system

Asingle-agent system uses an AI model, a defined set of tools, and a comprehensivesystem prompt to autonomously handle a user request or to complete a specific task.In this fundamental pattern, the agent relies on the model's reasoningcapabilities to interpret a user's request, plan a sequence of steps, and decidewhich tools to use from a defined set. The system prompt shapes the agent'sbehavior by defining its core task, persona, and operations,and the specific conditions for using each tool.

The following diagram shows a high-level view of a single agent pattern:

A single-agent system is ideal for tasks that require multiple steps and accessto external data. For example, a customer support agent must query a database tofind an order status, or a research assistant needs to call APIs to summarizerecent news. A non-agentic system can't perform these tasks because it can'tautonomously use tools or execute a multi-step plan to synthesize a finalanswer.

If you're early in your agent development, we recommend that you start with a single agent.When you start your agent development with a single-agent system, you canfocus on refining the core logic, prompt, and tool definitions of your agentbefore adding more complex architectural components.

A single agent's performance can be less effective when it uses more tools andwhen tasks increase in complexity. You might observe this as increased latency, incorrecttool selection or use, or a failure to complete the task. You can often mitigatethese issues by refining the agent's reasoning process with techniques like theReason and Act (ReAct) pattern.However, if your workflow requires an agent to manage several distinctresponsibilities, these techniques might not be sufficient. For these cases,consider amulti-agent system,which can improve resilience and performance by delegating specific skills tospecialized agents.

Multi-agent systems

Amulti-agent system orchestrates multiple specialized agents to solve acomplex problem that a single agent can't easily manage. The core principle is todecompose a large objective into smaller sub-tasks and assign each sub-task to adedicated agent with a specific skill. These agents then interact throughcollaborative or hierarchical workflows to achieve the final goal. Multi-agentpatterns provide a modular design that can improve the scalability, reliability,and maintainability of the overall system compared to a single agent with amonolithic prompt.

In a multi-agent system, each agent requires a specific context to perform itstask effectively. Context can include documentation, historical preferences,relevant links, conversational history, or any operational constraints. Theprocess of managing this information flow is calledcontext engineering. Context engineering includes strategies such as isolatingcontext for a specific agent, persisting information across multiple steps, orcompressing large amounts of data to improve efficiency.

Building a multi-agent system requires additional evaluation, security,reliability, and cost considerations when compared to a single-agent system. Forexample, multi-agent systems must implement precise access controls for eachspecialized agent, design a robust orchestration system to ensure reliableinter-agent communication, and manage the increased operational costs from thecomputational overhead of running multiple agents. For an example referencearchitecture to build a multi-agent system, seeMulti-agent AI systems in Google Cloud.

Sequential pattern

Themulti-agent sequential pattern executes a series of specialized agents in a predefined, linear order where theoutput from one agent serves as the direct input for the next agent. Thispattern uses asequential workflow agent that operates on predefined logic without havingto consult an AI model for the orchestration of its subagents.

The following diagram shows a high-level view of a multi-agent sequentialpattern:

Use the sequential pattern for highly structured, repeatable processes wherethe sequence of operations doesn't change. For example, a data processingpipeline might use this pattern to first have a data extraction agent pull rawdata, then pass that data to a data cleaning agent for formatting, which in turnpasses the clean data to a data loading agent to save it in a database.

The sequential pattern can reduce latency and operational costs compared to apattern that uses an AI model to orchestrate task workflow. However, thisefficiency comes at the cost of flexibility. The rigid, predefined structure ofthe pipeline makes it difficult to adapt to dynamic conditions or to skipunnecessary steps, which can cause inefficient processing or lead to highercumulative latency if an unneeded step is slow.

Parallel pattern

Themulti-agent parallel pattern,also known as aconcurrent pattern, multiple specialized subagents perform a task or sub-tasks independently at the same time. The outputs of the subagents are then synthesized to produce the final consolidated response. Similar to asequential pattern, the parallel patternuses aparallel workflow agent to manage how and when the other agents runwithout having to consult an AI model to orchestrate its subagents.

The following diagram shows a high-level view of a multi-agent parallelpattern:

Use the parallel pattern when sub-tasks can be executed concurrently to reducelatency or gather diverse perspectives, such as gathering data from disparatesources or evaluating several options at once. For example, to analyze customerfeedback, a parallel agent might fan out a single feedback entry to fourspecialized agents at the same time: a sentiment analysis agent, a keyword extractionagent, a categorization agent, and an urgency detection agent. A final agentgathers these four outputs into a single, comprehensive analysis ofthat feedback.

The parallel pattern can reduce overall latency compared to a sequentialapproach because it can gather diverse information from multiple sources at the same time. However,this approach introduces trade-offs in cost and complexity. Running multipleagents in parallel can increase immediate resource utilization and tokenconsumption, which leads to higher operational costs. Furthermore, the gatherstep requires complex logic to synthesize potentially conflicting results, whichadds to the development and maintenance overhead of the system.

Loop pattern

Themulti-agent loop agent pattern repeatedly executes a sequence of specialized subagentsuntil a specific termination condition is met. This pattern uses aloop workflow agent that, like other workflow agents, operates on predefined logic withoutconsulting an AI model for orchestration. After all of the subagents completetheir tasks, the loop agent evaluates whether an exit condition is met. Thecondition can be a maximum number of iterations or a custom state. If theexit condition isn't met, then the loop agent starts the sequence of subagentsagain. You can implement a loop pattern where the exit condition is evaluated atany point in the flow. Use the loop pattern for tasks that requireiterative refinementor self-correction, such as generating content and having a critic agent reviewit until it meets a quality standard.

The following diagram shows a high-level view of a multi-agent loop pattern:

The loop agent pattern provides a way to build complex, iterative workflows. Itenables agents to refine their own work and continue processing until a specificquality or state is achieved. However, this pattern's primary trade-off is therisk of an infinite loop. If the termination condition isn't correctly definedor if the subagents fail to produce the state that's required to stop, the loop can runindefinitely. This can lead to excessive operational costs, high resourceconsumption, and potential system hangs.

Review and critique pattern

Themulti-agent review and critique pattern, also known as thegenerator andcritic pattern, improves the quality and reliability of generated content byusing two specialized agents, typically in a sequential workflow. The review andcritique pattern is an implementation of theloop agent pattern.

In the review and critique pattern, a generator agent creates an initial output,such as a block of code or a summary of a document. Next, a critic agentevaluates this output against a predefined set of criteria, such as factualaccuracy, adherence to formatting rules, or safety guidelines. Based on theevaluation, the critic can approve the content, reject it, or return it to thegenerator with feedback for revision.

The following diagram shows a high-level view of a multi-agent review andcritique pattern:

This pattern is suitable for tasks where outputs must be highly accurate or mustconform to strict constraints before they're presented to a user or used in adownstream process. For example, in a code generation workflow, a generatoragent might write a function to fulfill a user's request. This generated code isthen passed to a critic agent that acts as a security auditor. The criticagent's job is to check the code against a set of constraints, such as scanningfor security vulnerabilities or verifying that it passes all of the unit tests,before the code is approved for use.

The reviewer and critique pattern can improve output quality, accuracy, andreliability because it adds a dedicated verification step. However, this qualityassurance comes at the direct cost of increased latency and operationalexpenses. The workflow requires at least one additional model call for thecritic's evaluation. If the process includes revision loops where content issent back for refinement, then both latency and costs accumulate with eachiteration.

Iterative refinement pattern

Theiterative refinement pattern uses a looping mechanism to progressivelyimprove an output over multiple cycles. The iterative refinement pattern is animplementation of theloop agent pattern.

In this pattern, one or more agents work within a loop to modify a resultthat's stored in the session state during each iteration. The process continues untilthe output meets a predefined quality threshold or it reaches a maximum number ofiterations, which prevents infinite loops.

The following diagram shows a high-level view of a multi-agent iterativerefinement pattern:

This pattern is suitable for complex generation tasks where the outputis difficult to achieve in a single step. Examples of such tasks include writing and debugging a pieceof code, developing a detailed multi-part plan, or drafting and revising along-form document. For example, in a creative writing workflow, an agent mightgenerate a draft of a blog post, critique the draft for flow and tone, and thenrewrite the draft based on that critique. This process repeats in a loop untilthe agent's work meets a predefined quality standard or until the repetition reachesa maximum number of iterations.

The iterative refinement pattern can produce highly complex or polished outputsthat would be difficult to achieve in a single step. However, the loopingmechanism directly increases latency and operational costs with each cycle. Thispattern also adds architectural complexity, because it requires carefully designedexit conditions—such as a quality evaluation or a maximum iteration limit—toprevent excessive costs or uncontrolled execution.

Coordinator pattern

Themulti-agent coordinator pattern uses a central agent, thecoordinator, todirect a workflow. The coordinator analyzes and decomposes a user's request intosub-tasks, and then it dispatches each sub-task to a specialized agent for execution.Each specialized agent is an expert in a specific function, such as querying a database or calling an API.

A distinction of the coordinator pattern is its use of an AI model to orchestrate and dynamically route tasks. By contrast, theparallel pattern relies on a hardcoded workflow to dispatch tasks for simultaneous execution without the need for AI model orchestration.

The following diagram shows a high-level view of a multi-agent coordinator pattern:

Use the coordinator pattern for automating structured business processes thatrequire adaptive routing. For example, a customer service agent can act as thecoordinator. The coordinator agent analyzes the request to determine whether it'san order status request, product return, or refund request. Based onthe type of request, the coordinator routes the task to the appropriate specializedagent.

The coordinator pattern offers flexibility compared to more rigid, predefinedworkflows. By using a model to route tasks, the coordinator can handle a widervariety of inputs and adapt the workflow at runtime. However, this approach alsointroduces trade-offs. Because the coordinator and each specialized agent relyon a model for reasoning, this pattern results in more model calls than asingle-agent system. Although the coordinator pattern can lead to higher-qualityreasoning, it also increases token throughput, operational costs, andoverall latency when compared to a single-agent system.

Hierarchical task decomposition pattern

Themulti-agent hierarchical task decomposition patternorganizes agents into a multi-level hierarchy to solve complex problems thatrequire extensive planning. The hierarchical task decomposition pattern is animplementation of thecoordinator pattern.A top-level parent, orroot, agent receives a complex task and it's responsiblefor decomposing the task into several smaller, manageable sub-tasks. The root agent delegateseach sub-task to a specialized subagent at a lower level. This process canrepeat through multiple layers, with agents that progressively decompose theirassigned tasks until the tasks are simple enough for a worker agent at the lowestlevel to execute directly.

The following diagram shows a high-level view of a multi-agent hierarchicaltask decomposition pattern:

Use the hierarchical task decomposition pattern for ambiguous, open-endedproblems that require multi-step reasoning, such as tasks that involve research,planning, and synthesis. For example, to complete a complex research project, acoordinator agent decomposes the high-level goal into multiple tasks such asgathering information, analyzing the findings, and synthesizing the finalreport. The coordinator agent then delegate those tasks to specializedsubagents, such as an agent for data gathering, an analysis agent, and anagent that writes reports, to execute or further decompose.

The hierarchical task decomposition pattern is ideal for solving highly complexand ambiguous problems because it systematically decomposes them intomanageable sub-tasks. This pattern can result in more comprehensive and higher-qualityresults than simpler patterns. However, this advanced capability introducessignificant trade-offs. The multi-level structure adds considerablearchitectural complexity, which makes the system more difficult to design, debug, andmaintain. The multiple layers of delegation and reasoning also result in a highnumber of model calls, which significantly increases both overall latency andoperational costs compared to other patterns.

Swarm pattern

Themulti-agent swarm pattern uses a collaborative, all-to-all communicationapproach. In this pattern, multiple specialized agents work together to iteratively refine asolution to a complex problem.

The following diagram shows a high-level view of a multi-agent swarm pattern:

The swarm pattern uses a dispatcher agent to route a user requestto a collaborative group of specialized agents. The dispatcher agent interpretsthe request and it determines which agent in the swarm is best suited to begin thetask. In this pattern, each agent can communicate with every other agent,which allows them to share findings, critique proposals, and build upon each other'swork to iteratively refine a solution. Any agent in the swarm can hand off thetask to another agent that it determines is better suited to handle the nextstep, or it can communicate the final response back to the user through thecoordinator agent.

A swarm typically lacks a central supervisor or coordinator agent to keep theprocess on track. The dispatcher agent doesn't orchestrate the agentic workflow,unlike thecoordinator pattern.Instead, the dispatcher agent facilitates communication between the swarmsubagents and the user. To ensure that the swarm eventually stops and returns aresult, you must define an explicit exit condition. Thiscondition is often a maximum number of iterations, a time limit, or theachievement of a specific goal, such as reaching a consensus.

Use the swarm pattern for ambiguous or highly complex problems that benefitfrom debate and iterative refinement. For example, designing a new product couldinvolve a market researcher agent, an engineering agent, and a financialmodeling agent. The agents would share initial ideas, debate the trade-offsbetween features and costs, and collectively converge on a final designspecification that balances all of the competing requirements.

The swarm pattern simulates a collaborative team of experts, therefore it canproduce exceptionally high-quality and creative solutions. However, it represents themost complex and costly multi-agent pattern to implement. The lack of an agentthat uses an AI model to orchestrate can introduce the risk of unproductive loopsor the failure to converge on a solution. You must therefore designsophisticated logic to manage the intricate inter-agent communication, controlthe iterative workflow, and handle the significant operational costs and latencythat are associated with running a dynamic, multi-turn conversation between multipleagents.

Reason and act (ReAct) pattern

TheReAct pattern is an approach that uses the AI model to frame its thought processes and actionsas a sequence of natural language interactions. In this pattern, the agent operates in an iterative loop of thought, action, andobservation until an exit condition is met.

• Thought: The model reasons about the task and it decides what to do next. The model evaluates all of the information that it's gathered in order to determine whether the user's request has been fully answered.
• Action: Based on its thought process, the model takes one of two actions:
  • If the task isn't complete, it selects a tool and then it forms a query to gather more information.
  • If the task is complete, it formulates the final answer to send to the user, which ends the loop.
• Observation: The model receives the output from the tool and it saves relevant information in its memory. Because the model saves relevant output, it can build on previous observations, which helps to prevent the model from repeating itself or losing context.

The iterative loop terminates whenthe agent finds a conclusive answer, reaches a preset maximum number ofiterations, or encounters an error that prevents it from continuing.This iterative loop lets the agent dynamically build a plan, gather evidence,and adjust its approach as it works toward a final answer.

The following diagram shows a high-level view of the ReAct pattern:

Use the ReAct pattern for complex, dynamic tasks that requirecontinuous planning and adaptation. For example, consider a robotics agent that must generate a path to transition from an initial state to a goal state:

• Thought: The model reasons about the optimal path to transition from its current state to the goal state. During the thought process, the model optimizes for metrics like time or energy.
• Action: The model executes the next step in its plan by moving along a calculated path segment.
• Observation: The model observes and saves the new state of the environment. The model saves its new position and any changes to the environment that it perceives.

This loop allows the agent toadhere to dynamic constraints, such as avoiding new obstacles or followingtraffic regulations, by constantly updating its plan based on new observations. The agent continues through its iterative loop until it reaches its goal or encounters an error.

A single ReAct agent can be simpler and more cost-effective to implement andmaintain than a complex multi-agent system. Model thinking provides a transcriptof the model's reasoning, which helps with debugging. However, this flexibilityintroduces trade-offs. The iterative, multi-step nature of the loop can lead tohigher end-to-end latency compared to a single query. Furthermore, the agent'seffectiveness is highly dependent on the quality of the AI model's reasoning.Therefore, an error or a misleading result from a tool in one observation step canpropagate and cause the final answer to be incorrect.

Human-in-the-loop pattern

The human-in-the-loop pattern integrates points for human intervention directly into an agent's workflow. At apredefined checkpoint, the agent pauses its execution and calls an externalsystem to wait for a person to review its work. This pattern lets a personapprove a decision, correct an error, or provide necessary input before theagent can continue.

The following diagram shows a high-level view of a human-in-the-loop pattern:

Use the human-in-the-loop pattern for tasks that require human oversight,subjective judgment, or final approval for critical actions. Such actions include approving alarge financial transaction, validating the summary of a sensitive document, orproviding subjective feedback on generated creative content. For example, anagent might be tasked with anonymizing a patient dataset for research. The agentwould automatically identify and redact all protected health information, but itwould pause at a final checkpoint. It would then wait for a human complianceofficer to manually validate the dataset and approve its release, which helps toensure that no sensitive data is exposed.

The human-in-the-loop pattern improves safety and reliability by insertinghuman judgment into critical decision points within the workflow. This patterncan add significant architectural complexity because it requires you to buildand maintain the external system for user interaction.

Custom logic pattern

The custom logic pattern provides the maximum flexibility in your workflowdesign. This approach lets you implement specific orchestration logic that usescode, such as conditional statements, to create complex workflows with multiplebranching paths.

The following diagram illustrates an example use of a custom logic pattern tocapture a refund process:

In the preceding diagram, the following is the agentic workflow for the examplecustomer refund agent:

1. The user sends a query to the customer refund agent that acts as acoordinator agent.
2. The coordinator's custom logic first invokes a parallel verifier agent,which simultaneously dispatches two subagents: the purchaser verifier agentand the refund eligibility agent.
3. After the results are gathered, the coordinator agent executes a tool tocheck whether the request is eligible for a refund.
   1. If the user is eligible, then the coordinator routes the taskto a refund processor agent, which calls theprocess_refund tool.
   2. If the user isn't eligible, then the coordinator routes thetask to a separate sequential flow, starting with the store creditagent and the process credit decision agent.
4. The result from whichever path is taken is sent to the final response agentto formulate the answer for the user.

The customer refund agent example requires a unique solution for itslogic-level orchestration, which goes beyond the structured approaches that otherpatterns offer. This workflow mixes patterns because it runs a parallel check,and then it executes a custom conditional branch that routes to two entirely differentdownstream processes. This type of complex, mixed-pattern workflow is the idealuse case for the custom logic pattern.

Use the custom logic pattern when you need fine-grained control over the agent'sexecution or when your workflow doesn't fit one of the other patterns that'sdescribed in this document. However, this approach increases development andmaintenance complexity. You are responsible for designing, implementing, anddebugging the entire orchestration flow, which requires more development effortand can be more error-prone than using a predefined pattern that is supported bya tool likeAgent Development Kit (ADK).

For information about custom agents and how to implement custom logic using ADK, seeCustom agents.

Compare design patterns

Choosing an agent pattern is a fundamental architectural decision. Each pattern offers different trade-offs in flexibility, complexity, and performance. To determine the appropriate pattern for your workload, consider the design patterns in the following sections.

Workflows that are deterministic

Workflow that are deterministic include tasks that are predictable and sequential, and that have a clearly defined workflow path from start to finish. The steps in your tasks are known in advance, and the process doesn't change much from one run to the next. The following are agent design patterns for workflows that are deterministic:

Workflows that require dynamic orchestration

Workflows that require dynamic orchestration include complex problems where the agents must determine the best way to proceed. The agentic AI system needs to dynamically plan, delegate, and coordinate tasks without a predefined script. The following are agent design patterns for workflows that require autonomous and dynamic orchestration:

Workflows that involve iteration

Workflows that involve iteration include tasks where the final output is achieved through cycles of refinement, feedback, and improvement. The following are agent design patterns for workflows that involve iteration:

Workflows that have special requirements

Workflows that have special requirements include tasks that don't follow the common agentic patterns. Your tasks can include unique business logic or they can require human judgment and intervention at critical points. Your agentic AI system is a custom-built machine designed for a single, specific purpose. The following are agent design patterns for workflows that have special requirements:

What's next

• Learn more about how to construct and managemulti-agent systems using ADK primitives.
• Learn how tohost AI apps and agents on Cloud Run.
• Learn more aboutAgentic Design Patterns: A Hands-On Guide to Building Intelligent Systems.
• Learn how tobuild an agent with ADK.
• Learn more about how to buildmulti-agent AI systems in Google Cloud.
• For more reference architectures, diagrams, and best practices, explore theCloud Architecture Center.

Contributors

Author:Samantha He | Technical Writer

Other contributors:

• Abdul Saleh | Software Engineer
• Amina Mansour | Head of Cloud Platform Evaluations Team
• Amit Maraj | Developer Relations Engineer
• Casey West | Architecture Advocate, Google Cloud
• Jack Wotherspoon | Developer Advocate
• Joe Fernandez | Staff Technical Writer
• Joe Shirey | Cloud Developer Relations Manager
• Karl Weinmeister | Director of Cloud Product Developer Relations
• Kumar Dhanagopal | Cross-Product Solution Developer
• Lisa Shen | Senior Outbound Product Manager, Google Cloud
• Mandy Grover | Head of Architecture Center
• Mark Lu | Technical Writer
• Megan O'Keefe | Developer Advocate
• Olivier Bourgeois | Developer Relations Engineer
• Shir Meir Lador | Developer Relations Engineering Manager
• Vlad Kolesnikov | Developer Relations Engineer