Why should we use Agentic patterns?

Monolithic AI agents do not scale effectively and often create significant system bottlenecks, much like monolithic software applications. Relying on a single, all-in-one agent to handle complex instructions turns it into a "Jack of all trades, master of none." As the agent's responsibilities and instruction complexity increase, its adherence to specific rules degrades, error rates compound, and "hallucinations" increase. Furthermore, single agents increase debugging costs—if the agent fails, developers are forced to tear down the entire prompt to locate the bug.

Multi-agent patterns matter because they solve these issues through decentralisation and specialisation. By implementing these patterns, developers can:

• Build the AI equivalent of a microservices architecture: Assign individual agents highly specific roles (such as a Parser, Critic, or Dispatcher) rather than relying on one generalist.
• Improve modularity and testing: Create systems that are inherently more testable, reliable, and significantly easier to debug.
• Overcome performance limits: Break through the limits that naturally occur when relying on a single entity to execute complex workflows.

7 Core Patterns

1. Sequential Pipeline Pattern

Let’s start with the bread and butter of agent workflows. Think of this pattern as a classic assembly line where Agent A finishes a task and hands the baton directly to Agent B. It is linear, deterministic, and refreshingly easy to debug because you always know exactly where the data came from. In ADK, the SequentialAgent primitive handles the orchestration for you. The secret sauce here is state management: simply use the output_key to write to the shared session.state so the next agent in the chain knows exactly where to pick up the work.

Real-world example: This is your go-to architecture for data processing pipelines. For processing raw documents, a Parser Agent turns a raw PDF into text, an Extractor Agent pulls out structured data, and a Summarizer Agent generates the final synopsis.

//Step 1: Parse the PDF
parser = LlmAgent(
    name="ParserAgent",
    instruction="Parse raw PDF and extract text.",
    tools=[PDFParser],
    output_key="raw_text"
)

//Step 2: Extract structured data
extractor = LlmAgent(
    name="ExtractorAgent",
    instruction="Extract structured data from {raw_text}.",
    tools=[RegexExtractor],
    output_key="structured_data"
)

//Step 3: Summarize
summarizer = LlmAgent(
    name="SummarizerAgent",
    instruction="Generate summary from {structured_data}.",
    tools=[SummaryEngine]
)

//Orchestrate the Assembly Line
pipeline = SequentialAgent(
    name="PDFProcessingPipeline",
    sub_agents=[parser, extractor, summarizer]
)

2. Coordinator/Dispatcher Pattern

Sometimes you don't need a chain; you need a decision maker. In this pattern, a central, intelligent agent acts as a dispatcher. It analyzes the user's intent and routes the request to a specialist agent best suited for the job. This relies on LLM-driven delegation. You simply define a parent CoordinatorAgent and provide a list of specialist sub_agents. The ADK's AutoFlow mechanism takes care of the rest, transferring execution based on the descriptions you provide for the children.

Real-world example: This is ideal for complex customer service bots where you might need to send a user to a "Billing" specialist for invoice issues versus a "Tech Support" specialist for troubleshooting.

billing_specialist = LlmAgent(
    name="BillingSpecialist",
    description="Handles billing inquiries and invoices.",
    tools=[BillingSystemDB]
)

tech_support = LlmAgent(
    name="TechSupportSpecialist",
    description="Troubleshoots technical issues.",
    tools=[DiagnosticTool]
)

// The Coordinator (Dispatcher)
coordinator = LlmAgent(
    name="CoordinatorAgent",
    instruction="Analyze user intent. Route billing issues to BillingSpecialist and bugs to TechSupportSpecialist.",
    sub_agents=[billing_specialist, tech_support]
)

3. Parallel Fan-Out/Gather Pattern

Speed matters. If you have tasks that don't depend on each other, why run them one by one? In this pattern, multiple agents execute tasks simultaneously to reduce latency or gain diverse perspectives. Their outputs are then aggregated by a final "synthesizer" agent. The ParallelAgent in ADK should be used to run sub-agents simultaneously. Be aware that although these agents operate in separate execution threads, they share the session state. To prevent race conditions, make sure each agent writes its data to a unique key.

Real-world example: This is ideal for something like Automated Code Review. Instead of running checks sequentially, you can spawn a "Security Auditor," a "Style Enforcer," and a "Performance Analyst" to review a Pull Request simultaneously. Once they finish, a "Synthesizer" agent combines their feedback into a single, cohesive review comment.

// Define parallel workers
security_scanner = LlmAgent(
    name="SecurityAuditor",
    instruction="Check for vulnerabilities like injection attacks.",
    output_key="security_report"
)

style_checker = LlmAgent(
    name="StyleEnforcer",
    instruction="Check for PEP8 compliance and formatting issues.",
    output_key="style_report"
)

complexity_analyzer = LlmAgent(
    name="PerformanceAnalyst",
    instruction="Analyze time complexity and resource usage.",
    output_key="performance_report"
)

// Fan-out (The Swarm)
parallel_reviews = ParallelAgent(
    name="CodeReviewSwarm",
    sub_agents=[security_scanner, style_checker, complexity_analyzer]
)

// Gather/Synthesize
pr_summarizer = LlmAgent(
    name="PRSummarizer",
    instruction="Create a consolidated Pull Request review using {security_report}, {style_report}, and {performance_report}."
)

// Wrap in a sequence
workflow = SequentialAgent(sub_agents=[parallel_reviews, pr_summarizer])

4. Hierarchical Decomposition

Sometimes a task is too big for one agent context window. High-level agents can break down complex goals into sub-tasks and delegate them. Unlike the routing pattern, the parent agent might delegate just part of a task and wait for the result to continue its own reasoning. You can treat a sub-agent as a tool here. By wrapping an agent in AgentTool, the parent agent can call it explicitly, effectively treating the sub-agent's entire workflow as a single function call.

Real-world example: Think of a high-level report writing system. A ReportWriter agent doesn't do the research itself; it delegates to a ResearchAssistant, which in turn manages WebSearch and Summarizer tools to gather information before passing it back up.

// Level 3: Tool Agents
web_searcher = LlmAgent(name="WebSearchAgent", description="Searches web for facts.")
summarizer = LlmAgent(name="SummarizerAgent", description="Condenses text.")

// Level 2: Coordinator Agent
research_assistant = LlmAgent(
    name="ResearchAssistant",
    description="Finds and summarizes info.",
    sub_agents=[web_searcher, summarizer]
)

// Level 1: Top-Level Agent
report_writer = LlmAgent(
    name="ReportWriter",
    instruction="Write a comprehensive report on AI trends. Use the ResearchAssistant to gather info.",
    tools=[AgentTool(research_assistant)]
)

5. Generator and Critic

Generating high-quality, reliable output often requires a second pair of eyes. In this pattern, you separate the creation of content from the validation of content. One agent acts as the Generator, producing a draft, while a second agent acts as the Critic, reviewing it against specific, hard-coded criteria or logical checks. To implement this in ADK, you separate concerns into two specific primitives: a SequentialAgent that manages the draft-and-review interaction, and a parent LoopAgent that enforces the quality gate and exit condition. If the review passes, the loop breaks, and the content is finalized. If it fails, specific feedback is routed back to the Generator to produce a compliant draft.

Real-world example: This is incredibly useful for code generation that needs syntax checking or content creation requiring compliance review. For example, a generator produces a draft of a SQL query, and a critic checks if it is valid SQL, routing error details back to fix it if it fails.

// The Generator
generator = LlmAgent(
    name="Generator",
    instruction="Generate a SQL query. If you receive {feedback}, fix the errors and generate again.",
    output_key="draft"
)

// The Critic
critic = LlmAgent(
    name="Critic",
    instruction="Check if {draft} is valid SQL. If correct, output 'PASS'. If not, output error details.",
    output_key="feedback"
)

// The Loop
loop = LoopAgent(
    name="ValidationLoop",
    sub_agents=[generator, critic],
    condition_key="feedback",
    exit_condition="PASS"
)

6. Iterative Refinement

Great work rarely happens in a single draft. In this pattern, agents enter a cycle of generating, critiquing, and refining until the output meets a specific quality threshold. Unlike the Generator and Critic pattern, which focuses on correctness (Pass/Fail), this pattern focuses on qualitative improvement. This pattern is implemented using the LoopAgent. While you can set a hard limit using max_iterations, ADK also allows an agent to signal early completion by triggering escalate=True within its EventActions if the quality threshold is met early.

Real-world example: Just like a human writer needs to revise, polish, and edit, sometimes your agents need a few attempts to get an answer exactly right. A Generator creates a rough draft, a Critique Agent provides optimization notes, and a Refinement Agent polishes the output to be more efficient based on those notes.

// Generator
generator = LlmAgent(
    name="Generator",
    instruction="Generate an initial rough draft.",
    output_key="current_draft"
)

// Critique Agent
critic = LlmAgent(
    name="Critic",
    instruction="Review {current_draft}. List ways to optimize it for performance.",
    output_key="critique_notes"
)

// Refiner Agent
refiner = LlmAgent(
    name="Refiner",
    instruction="Read {current_draft} and {critique_notes}. Rewrite the draft to be more efficient.",
    output_key="current_draft"
)

// The Loop (Critique -> Refine)
loop = LoopAgent(
    name="RefinementLoop",
    max_iterations=3,
    sub_agents=[critic, refiner]
)

// Complete Workflow
workflow = SequentialAgent(sub_agents=[generator, loop])

7. Human-in-the-Loop

AI Agents are powerful, but sometimes you need a human in the driver's seat for critical decision-making. In this model, agents handle the groundwork, but a human must authorize high-stakes actions - specifically those that are irreversible or carry significant consequences. ADK allows you to implement this via custom tools. An agent can call an approval_tool which pauses execution or triggers an external system to request human intervention.

Real-world example: This includes executing financial transactions, deploying code to production, or taking action based on sensitive data, ensuring safety and accountability. A Transaction Agent processes routine work, but pauses execution to wait for a Human Reviewer when a high stakes check is triggered.

transaction_agent = LlmAgent(
    name="TransactionAgent",
    instruction="Handle routine processing. If high stakes, call ApprovalTool.",
    tools=[ApprovalTool]
)

approval_agent = LlmAgent(
    name="ApprovalToolAgent",
    instruction="Pause execution and request human input."
)

workflow = SequentialAgent(sub_agents=[transaction_agent, approval_agent])

Summary

• Decentralization and Specialization: Every pattern avoids the "monolithic" approach of relying on a single, all-in-one agent. Because single agents tasked with too much become a "Jack of all trades, master of none" subject to compounded errors and hallucinations, all these patterns assign highly specific roles (such as a parser, dispatcher, or critic) to individual agents.
• AI Microservices Architecture: All of the patterns are designed to help you build the AI equivalent of a microservices architecture, breaking complex workflows down into smaller, targeted tasks.
• Modularity and Reliability: By dividing up responsibilities, every pattern inherently creates a system that is more modular, testable, reliable, and significantly easier to debug than a single giant prompt.
• Shared State Management: Regardless of whether the agents operate in a linear chain, a parallel swarm, or a refinement loop, they all rely on passing data through a shared state. In the Google Agent Development Kit (ADK), they use session.state as a shared "whiteboard" and rely on descriptive output_key parameters so that downstream agents know exactly where to pick up the data.
• ADK Orchestration: All of the patterns are structured to be built using specific Google Agent Development Kit (ADK) primitives—such as the SequentialAgent, ParallelAgent, or LoopAgent—to handle the orchestration and hand-offs between the specialized agents.

Composite Pattern

Real-world enterprise applications rarely fit into a single box. You will likely combine these patterns to build production-grade applications.

Real-world example: A robust Customer Support system might use a Coordinator to route requests. If the user has a technical issue, that branch might trigger a Parallel search of documentation and user history. The final answer might then go through a Generator and Critic loop to ensure tone consistency before being sent to the user.

Reference

https://developers.googleblog.com/developers-guide-to-multi-agent-patterns-in-adk/