Up to this point in the course, we have focused on building single agents - one LLM with tools, memory, and a planning loop. That approach works remarkably well for many tasks. But as the scope of what you want to automate grows, a single agent starts to buckle under the weight. It gets slow. It gets confused. It tries to be an expert at everything and ends up being an expert at nothing.
Multi-agent systems solve this by splitting work across multiple specialized agents that coordinate to achieve a shared goal. Think of it like the difference between a solo freelancer and a well-organized team. The freelancer can do many things, but a team of specialists - each owning their domain - can tackle problems that no single person could handle alone.
In this lesson, you will learn when and why to use multiple agents, the main architectural patterns for organizing them, how agents communicate, and how to handle the coordination challenges that come with distributed systems.
A single agent with access to twenty tools, a massive system prompt, and instructions covering five different domains is like a new hire who was given five different job descriptions on their first day. They might technically be capable of doing each task, but juggling all of them leads to mistakes, slowdowns, and confusion.
Here are the concrete reasons to consider splitting into multiple agents:
| Problem with Single Agent | How Multi-Agent Helps |
|---|---|
| Prompt becomes enormous and hard to maintain | Each agent gets a focused, manageable prompt |
| Too many tools cause selection errors | Each agent only sees the tools relevant to its role |
| One failure crashes the whole workflow | Failures are isolated to one agent; others keep working |
| Hard to scale bottleneck steps | You can scale individual agents independently |
| Difficult to test and debug | Each agent can be tested in isolation |
| Single point of failure for safety | Different agents can have different permission levels |
Multi-agent systems are like a hospital. When you walk in with a medical issue, you do not get one doctor who does everything - takes your vitals, runs bloodwork, reads the X-ray, performs surgery, and handles your billing. Instead, you move through a system of specialists: a triage nurse assesses you, a physician diagnoses you, a radiologist reads your scans, a surgeon operates if needed, and an administrator handles insurance. Each person is an expert in their role, and they coordinate through shared records and handoff protocols.
An AI multi-agent system works the same way. Each agent is a specialist with a focused role, its own set of tools, and clear boundaries for what it handles and what it passes along.
Not every problem needs multiple agents. Here is a simple decision framework:
Stay with a single agent when:
Consider multi-agent when:
Imagine a corner shop run by one person. The owner greets you, finds your product, rings it up, handles returns, and restocks the shelves. For a small shop with a handful of customers, this works great. The owner knows everything and can do everything.
Now imagine that same person trying to run a department store alone. Thousands of customers, dozens of departments, complex inventory, specialized products. It would be chaos. Department stores work because they have specialized staff: someone in electronics, someone in clothing, cashiers, floor managers, a returns desk. Each person has a clear role and they coordinate through defined processes.
| Aspect | Single Agent (Corner Shop) | Multi-Agent (Department Store) |
|---|---|---|
| Complexity handling | Good for simple tasks | Built for complex workflows |
| Specialization | Jack of all trades | Expert in its domain |
| Failure impact | Everything goes down | Only affected agent is impacted |
| Development speed | Fast to prototype | Faster to iterate on individual parts |
| Coordination overhead | None | Requires explicit coordination logic |
| Cost per simple task | Lower | Higher (more LLM calls) |
There are four primary patterns for organizing multiple agents. Each has different strengths, and you will often combine them in real systems.
In a sequential architecture, agents are arranged in a pipeline. Agent A completes its work and hands off to Agent B, who hands off to Agent C, and so on. Each agent transforms or enriches the output before passing it along.
How it works:
[Agent A] --> [Agent B] --> [Agent C] --> Final Output
(Research) (Draft) (Review)
Analogy: Think of a car assembly line. One station welds the frame, the next installs the engine, the next paints the body. Each station does one thing well, and the car moves forward through the line.
When to use it:
Example: A content pipeline where a Research Agent gathers sources, a Writing Agent produces a draft, and an Editing Agent reviews for quality and accuracy.
Strengths:
Weaknesses:
In a hierarchical architecture, a supervisor agent (the “manager”) receives the overall task, breaks it into subtasks, and delegates each subtask to a specialized worker agent. The manager collects results, checks quality, and may re-delegate if work is not satisfactory.
How it works:
[Manager Agent]
/ | \
[Worker A] [Worker B] [Worker C]
(Search) (Calculate) (Draft)
Analogy: This is like a company org chart. The CEO does not write code or file taxes - they set direction and delegate to department heads, who in turn delegate to their teams. The CEO reviews the results and makes final decisions.
When to use it:
Example: A project management agent that receives “Plan the Q3 product launch” and delegates research to one agent, timeline creation to another, and risk assessment to a third.
Strengths:
Weaknesses:
In the Google Agent Development Kit (ADK), hierarchical patterns are well supported. You can define a parent agent that delegates to sub-agents, each with their own tools and instructions.
In a collaborative architecture, agents work together as equals. There is no boss. Agents share information, build on each other’s work, and converge toward a solution through communication.
How it works:
[Agent A] <--> [Agent B]
^ ^
| |
v v
[Agent C] <--> [Agent D]
Analogy: This is like a brainstorming session with a group of colleagues. Everyone contributes ideas, reacts to what others have said, and the group converges on a plan. Nobody is in charge - the best ideas rise to the top through discussion.
When to use it:
Example: A code review system where a Security Agent, a Performance Agent, and a Readability Agent each review the same code and share their findings, then collaborate to produce a unified review.
Strengths:
Weaknesses:
In a competitive architecture, multiple agents independently tackle the same problem, and a judge (another agent or a scoring function) selects the best output.
How it works:
[Agent A] --\
[Agent B] ----> [Judge] --> Best Output
[Agent C] --/
Analogy: This is like a design competition. Three architecture firms each submit a proposal for a new building. A panel of judges reviews all three and selects the best one. The competition produces better results than any single firm would have produced alone.
When to use it:
Example: Three different coding agents each write a solution to a programming problem. A Judge Agent runs tests, checks code quality, and selects the best implementation.
Strengths:
Weaknesses:
| Architecture | Flow | Best For | Coordination Complexity |
|---|---|---|---|
| Sequential | Linear pipeline | Ordered multi-stage tasks | Low |
| Hierarchical | Tree (manager + workers) | Dynamic task decomposition | Medium |
| Collaborative | Mesh (peer-to-peer) | Complex problems needing diverse input | High |
| Competitive | Parallel with judge | High-stakes decisions | Medium |
Agents need to talk to each other. How they communicate shapes the system’s behavior, debuggability, and performance. There are three main patterns:
Agents send messages directly to each other. Agent A knows about Agent B and sends it a request.
Agent A --"summarize this document"--> Agent B
Agent B --"here is the summary"--> Agent A
Pros: Simple, low latency, easy to trace. Cons: Tight coupling - Agent A must know about Agent B. Adding new agents requires updating existing ones.
All agents read from and write to a shared workspace (the “blackboard”). Agents check the blackboard for new information, do their work, and post results back.
[Blackboard / Shared State]
^ ^ ^
| | |
Agent A Agent B Agent C
Pros: Loose coupling - agents do not need to know about each other. Easy to add new agents. Good for collaborative architectures. Cons: Potential for conflicts when multiple agents write to the same area. Harder to trace causality (who changed what and why).
Agents publish events to a message bus. Other agents subscribe to events they care about and react accordingly.
Agent A --publishes "order_refund_requested"--> [Event Bus]
[Event Bus] --notifies--> Agent B (Payment)
[Event Bus] --notifies--> Agent C (Compliance)
Pros: Highly decoupled. Scales well. Familiar to engineers who have worked with microservices. Cons: More infrastructure to manage. Harder to debug. Eventual consistency challenges.
| Scenario | Recommended Pattern |
|---|---|
| Two agents with a clear request-response flow | Direct Messaging |
| Multiple agents building on shared context | Shared Blackboard |
| Microservice-style system with many agents | Event-Based |
| Simple prototype | Direct Messaging |
| Production system at scale | Event-Based |
In well-designed multi-agent systems, each agent has a clear role. Here are four common roles you will see across many architectures:
The Planner takes a high-level goal and breaks it down into a sequence of steps or subtasks. It decides what needs to happen and in what order.
Responsibilities:
Example: Given “Book a team offsite for next month,” the Planner might produce: (1) check team calendars, (2) find available venues, (3) compare prices, (4) book the best option, (5) send calendar invites.
The Retriever finds information from external sources - databases, APIs, documents, the web. It knows where data lives and how to get it.
Responsibilities:
The Executor takes actions in the real world. It calls APIs, writes files, sends emails, or makes database changes. It is the agent that “does things.”
Responsibilities:
The Evaluator checks the quality of work done by other agents. It verifies correctness, safety, and completeness.
Responsibilities:
Let us walk through a concrete multi-agent system for handling customer refunds at an e-commerce company. This example uses a hierarchical architecture with four specialized agents.
| Agent | Role | Tools | Permissions |
|---|---|---|---|
| Customer Agent | Planner + interface | Customer lookup, order history | Read customer data |
| Payment Agent | Executor | Refund API, payment gateway | Process refunds up to $500 |
| Compliance Agent | Evaluator | Policy database, fraud detection | Read-only access |
| Resolution Agent | Manager / Orchestrator | None (coordinates others) | Delegates to all agents |
Scenario: A customer writes in saying “I never received my order #12345 and I want a refund.”
Step 1: Resolution Agent receives the request
The Resolution Agent is the entry point. It reads the customer’s message and decides which agents need to be involved.
Resolution Agent thinks:
"This is a refund request for a missing order. I need to:
1. Verify the customer and order details
2. Check compliance with refund policy
3. Process the refund if approved"
Step 2: Resolution Agent delegates to Customer Agent
The Resolution Agent asks the Customer Agent to look up the customer and order.
Resolution Agent -> Customer Agent:
"Look up order #12345 and provide the order details,
delivery status, and customer history."
The Customer Agent queries the order database, finds that order #12345 was marked “shipped” but tracking shows it was never delivered. It returns this information to the Resolution Agent.
Step 3: Resolution Agent delegates to Compliance Agent
With the order details in hand, the Resolution Agent asks the Compliance Agent to check if a refund is appropriate.
Resolution Agent -> Compliance Agent:
"Order #12345, $89.99, shipped but never delivered.
Customer has 2 prior refund requests in the last year.
Is a refund appropriate per our policy?"
The Compliance Agent checks the refund policy, verifies this is not a pattern of fraud, and responds that the refund is approved - the customer is within policy limits and the delivery failure is confirmed by the carrier.
Step 4: Resolution Agent delegates to Payment Agent
With compliance approval, the Resolution Agent instructs the Payment Agent to process the refund.
Resolution Agent -> Payment Agent:
"Process a refund of $89.99 to the original payment
method for order #12345. Compliance approved."
The Payment Agent calls the payment gateway API, processes the refund, and returns a confirmation with the refund transaction ID.
Step 5: Resolution Agent responds to the customer
The Resolution Agent compiles the results and generates a customer-facing response confirming the refund.
The Google Agent Development Kit (ADK) provides built-in support for multi-agent patterns. You can define agents as classes with their own instructions, tools, and sub-agents. The ADK handles message passing between agents and provides tracing for debugging.
For workflow agents that follow predictable patterns (like our sequential compliance check), ADK offers workflow agents with built-in sequential, parallel, and loop constructs.
Multi-agent systems are distributed systems, and distributed systems have failure modes that single-agent systems do not. Here are the most common coordination challenges and how to handle them:
What it is: Two or more agents are waiting for each other to finish, so nothing progresses.
Example: Agent A waits for Agent B’s output before proceeding. Agent B waits for Agent A’s output before proceeding. Neither can move forward.
How to prevent it:
What it is: Agent A delegates to Agent B, which delegates back to Agent A, creating an infinite loop.
Example: A Planner Agent asks a Research Agent for information. The Research Agent decides it needs more context and asks the Planner Agent to clarify. The Planner Agent, not having new information, asks the Research Agent again. Loop forever.
How to prevent it:
What it is: Two agents independently take contradictory actions on the same resource.
Example: A Pricing Agent sets a product price to $49.99 based on competitive analysis. Simultaneously, a Promotions Agent sets the same product price to $29.99 for a flash sale. The final price depends on which agent wrote last.
How to prevent it:
What it is: Multiple agents compete for limited resources (API rate limits, token budgets, database connections).
Example: Ten agents all try to call the same external API simultaneously, hitting the rate limit and causing failures for all of them.
How to prevent it:
What it is: Agents have different views of the world because shared state updates have not propagated to everyone.
Example: The Customer Agent checks inventory and tells the customer an item is in stock. Meanwhile, the Fulfillment Agent just sold the last unit. The customer gets a confirmation for an item that is no longer available.
How to prevent it:
Based on the patterns and challenges above, here are the key principles to follow:
Begin with a single agent. Add more agents only when you hit clear limitations. Premature decomposition into multiple agents adds complexity without benefit.
Each agent should have a well-defined scope, its own tools, and clear rules for what it handles and what it passes to others. Vague boundaries lead to duplication and conflicts.
Assume any agent can fail at any time. Use timeouts, retries, circuit breakers, and fallbacks. A well-designed multi-agent system degrades gracefully rather than collapsing entirely.
Log every message between agents. You will need these logs to debug issues. If you cannot trace the full path of a request through your system, you cannot fix it when it breaks.
Each agent should have the minimum permissions it needs. The Payment Agent should not be able to read customer emails. The Customer Agent should not be able to process refunds. This limits the blast radius when an agent misbehaves.
For high-stakes decisions, include a human-in-the-loop step. Agents are good at handling routine cases. Humans should handle exceptions, edge cases, and decisions with significant consequences.
Design a multi-agent system for one of the following scenarios. For your chosen scenario, define:
Scenario A: Automated Code Review A system that reviews pull requests for code quality, security vulnerabilities, performance issues, and style compliance.
Scenario B: Travel Booking Assistant A system that helps users plan and book travel - flights, hotels, car rentals, and activities - while staying within a budget.
Scenario C: Content Moderation Pipeline A system that reviews user-generated content for policy violations, spam, misinformation, and harmful content before publishing.