One agent with twelve tools versus three specialists with four tools each — which wins? The honest answer in 2025: usually the single agent, until your task crosses domains that genuinely need different system prompts, different tools, or parallel execution. This lesson covers when multi-agent earns its complexity tax, and the orchestration patterns (CrewAI, AutoGen, LangGraph) that make it work.
Learning Objectives
After this lesson, you will be able to:
Understand why teams of specialized AI agents often outperform one generalist agent -- just like how a startup team beats a one-person shop on complex projects
Describe five multi-agent architectures (manager-worker, pipeline, debate, swarm, marketplace) and know when to pick each one
Trace how agents talk to each other through message passing, shared whiteboards, and event buses
Understand MCP (Model Context Protocol) as the universal standard for connecting agents to tools -- like USB-C for AI
Understand A2A (Agent-to-Agent protocol) as the emerging standard for agents collaborating across companies and systems
Know when a multi-agent system is worth the extra complexity versus when a single agent is simpler and better
This lesson is where things get really exciting. Instead of one AI doing everything, you are building teams of AI specialists that collaborate. It is like going from a solo project to running a company -- more coordination, but dramatically more capability.
Try it! Try this thought experiment: pick a complex task like "create a marketing plan for a new app." Write down the 3-4 specialist roles you would need (e.g., Market Researcher, Copywriter, Designer, Analyst). For each, write what tools they would need and what they would hand off to the next specialist. You just designed a multi-agent system on paper.
So far, we have been talking about a single agent in a loop. That works beautifully for many tasks. But some problems are too large, too complex, or too multifaceted for one agent. When that happens, you bring in a team.
Three forces push you toward multi-agent architectures:
Specialization. A single agent with 50 tools and a massive system prompt tends to underperform. The prompt is too complex. The tool selection accuracy drops. The agent tries to be everything and excels at nothing. But an agent with 5 tools and a focused prompt excels. Multi-agent systems let you create specialists: a "code agent" that only writes code, a "search agent" that only retrieves information, a "review agent" that only critiques. Each agent is simpler, more reliable, and easier to test individually.
Parallel execution. A single agent processes sequentially -- one thought, one action at a time. Multiple agents can work simultaneously. While the researcher searches three different databases in parallel, the writer can start drafting from already-available information. This reduces wall-clock time dramatically for complex tasks. A research task that takes a single agent 10 minutes of sequential work might take a team of 3 agents 4 minutes running in parallel.
Diversity of thought. A single agent has one perspective. Multiple agents can approach the same problem from different angles, debate their conclusions, and converge on a more robust answer. This is the AI equivalent of "two heads are better than one." A "devil's advocate" agent forced to argue the opposite position often catches flaws that a single agent would miss.
What Do You Think?
You are choosing between a single agent with 20 tools and a 4-agent team where each specialist has 5 tools. Which gives you the better baseline accuracy in 2025, all else equal?
Before we dive into the detailed architectures, here is a quick mental model for five core patterns with concrete examples:
Manager-Worker: A CEO assigns tasks, workers execute. For example, a research agent manages 3 web-scraper agents -- it tells each scraper which site to search, collects their findings, and synthesizes a final report. The manager maintains the big picture while workers focus on execution.
Pipeline: The output of one agent feeds into the next, assembly-line style. For example: a researcher agent gathers raw facts, a writer agent drafts an article from those facts, an editor agent polishes the prose and fact-checks claims, and a publisher agent formats and posts the final piece. Each agent transforms the work product before passing it along.
Debate: Two agents argue opposing positions, and a third agent judges. For example, in a pro/con analysis of a business strategy, Agent A argues for the strategy, Agent B argues against it, and an arbiter agent evaluates both arguments and renders a balanced decision. This adversarial structure catches blind spots that a single agent would miss.
Swarm: Many identical agents work in parallel on sub-problems. For example, 10 search agents each query a different database simultaneously -- one searches academic papers, another searches patents, another searches news archives. Their results are merged by a coordinator. Speed scales linearly with the number of agents.
Marketplace: Agents bid for tasks based on capability and availability. For example, when a document needs translation, multiple translation agents bid based on their language expertise and current workload. The French-specialist agent bids high for a French document; the generalist bids lower. The system routes the task to the best bidder. This pattern enables dynamic, efficient allocation without a centralized manager.
Agents are arranged in a chain. Agent A's output becomes Agent B's input, which becomes Agent C's input. Each agent transforms the work product before passing it on.
Example: Research Agent gathers raw data. Summary Agent distills key findings. Writer Agent produces the final report. Each agent has a clear, focused role.
Best for: Tasks with clear, linear stages where each stage transforms the output of the previous one. Content pipelines, data processing, ETL workflows, and multi-step analysis.
Tradeoff: Simple and predictable, but the pipeline is only as fast as its slowest agent. A failure in the middle blocks everything downstream.
A dispatcher sends the same task (or different subtasks) to multiple agents simultaneously, then a merge agent gathers and combines their results.
Example: A question is sent to three search agents, each querying a different database (academic papers, news articles, Wikipedia). Their results are combined and deduplicated by a merge agent that produces a unified answer.
Best for: Tasks where independent subtasks can run concurrently. Multi-source research, parallel code generation across multiple files, and redundancy for reliability (send the same query to three agents and take the best answer).
Tradeoff: Fast (all agents work in parallel), but the merge step is hard. Combining diverse, potentially conflicting outputs requires careful logic.
A manager agent decomposes the task and delegates subtasks to worker agents. Workers report back, and the manager synthesizes results and decides next steps. The manager maintains the big picture while workers focus on details.
Example: Project Manager Agent breaks "Build a landing page" into three subtasks. Writer Agent creates copy. Designer Agent generates layout suggestions. Coder Agent implements HTML/CSS. The manager reviews outputs, identifies gaps, and requests revisions.
Best for: Complex, multi-skill tasks where a coordinator needs to maintain the big picture. This is the most common production pattern because it scales naturally and mirrors how human teams work.
Tradeoff: The manager is a single point of failure. If it misunderstands the task or delegates poorly, the whole team suffers.
Multiple agents argue different positions on the same question. They see each other's arguments and can respond. After several rounds, they converge (or a judge agent decides).
Example: Three agents assess whether a business strategy is sound. Agent A argues for, Agent B argues against, Agent C identifies nuances. After 3 rounds of debate, a judge agent synthesizes the best arguments into a balanced recommendation.
Best for: Decision-making, risk assessment, code review, and any task where exploring multiple perspectives improves output quality. Especially valuable when the cost of a wrong decision is high.
Tradeoff: Expensive (multiple rounds of LLM calls per agent) and slow. Only justified when the task genuinely benefits from adversarial analysis.
Agents are peers with no fixed hierarchy. They discover each other, negotiate tasks, and collaborate dynamically. Any agent can delegate to any other agent.
Example: A swarm of coding agents where any agent can ask another for help. One agent writes a function, realizes it needs a utility that another agent specializes in, and requests it directly -- no manager involved.
Best for: Emergent, unpredictable tasks where the workflow cannot be predetermined. Research exploration, creative brainstorming, and complex system debugging where the path forward only becomes clear during execution.
Tradeoff: Hardest to debug and predict. Communication overhead can spiral. Best reserved for research and experimental settings.
What Do You Think?
In a debate-pattern multi-agent system, two researchers argue opposing positions and a judge synthesizes. Compared to a single best-of-N call from the same model, the debate pattern tends to...
Try it: Step through multi-agent patternsInteractive
Loading visualization...
Select an architecture above and step through the message-passing flow. Watch how agents delegate, collaborate, and combine results. Compare the hierarchical manager-worker pattern with the pipeline, fan-out, and debate patterns to see the tradeoffs in action.
A manager agent receives: "Write a comprehensive Q3 sales performance report." This is too complex for a single agent -- it requires data gathering, analysis, writing skill, and quality review.
The manager creates a plan and assigns subtasks: "Researcher: pull Q3 sales data from the database and gather industry benchmarks. Writer: stand by for incoming data." The manager maintains a task board tracking each agent's status.
The researcher agent queries the sales database, pulls competitor benchmarks from web search, and calculates quarter-over-quarter trends. It returns structured data: revenue by region, top products, growth rates, and comparison metrics.
The manager forwards the research to the writer agent: "Draft a report covering revenue trends, top products, regional breakdown, and comparison to Q2." The writer produces a 3-page draft with charts and tables described.
The manager sends the draft to the critic agent: "Review for factual accuracy, logical consistency, and clarity. Flag any claims not supported by the data." The critic identifies two unsupported claims, a math error in the regional totals, and suggests restructuring the conclusion.
The writer revises based on the critic's feedback, fixing the math error and removing unsupported claims. The manager reviews the final version, confirms all feedback was addressed, and delivers the polished report. Three specialized agents produced a result that none could have achieved alone.
A product manager says: "Analyze our competitor's new pricing page and write a memo with strategic recommendations." This task requires research skills, analytical skills, and writing skills -- three different specializations that benefit from dedicated agents.
The orchestrator agent receives the request and decomposes it into subtasks: (1) Research the competitor's pricing page and extract key data, (2) Analyze the pricing strategy and compare to ours, (3) Write a strategic memo with recommendations. It assigns each subtask to the best-suited specialist agent.
The orchestrator dispatches tasks in parallel where possible: "Research Agent: scrape and analyze the competitor pricing page. Code Agent: build a comparison spreadsheet of their tiers vs. ours." The orchestrator tracks each agent's status and manages dependencies -- the writer cannot start until research is complete.
The research agent browses the competitor's pricing page, extracts tier names, prices, feature lists, and positioning language. It calls web_search for recent pricing change announcements and customer reactions. It returns structured data: three tiers ($29/$79/$199), key differentiators, and market positioning analysis.
The code agent receives the research data and builds a comparison matrix. It calculates: price-per-feature ratios, identifies gaps in our offering, and flags areas where we are overpriced or underpriced. It produces a structured analysis with quantified recommendations.
The writer agent receives both the research and analysis. It drafts a 2-page strategic memo: executive summary, competitive landscape, pricing comparison table, and three actionable recommendations. A separate reviewer agent checks for logical consistency and unsupported claims, requesting one revision.
The orchestrator collects the final memo, the raw research data (as appendix), and the comparison spreadsheet. It performs a final quality check: are all sections complete? Do the recommendations follow from the analysis? Is the memo formatted correctly?
The orchestrator delivers the complete package to the product manager: a polished strategic memo with data-backed recommendations, a comparison spreadsheet, and source links. Four specialized agents collaborated through the orchestrator to produce work that would have taken a single generalist agent much longer and at lower quality.
With five patterns to choose from, how do you decide? Use this decision framework:
How many distinct skills does the task require? If 1-2, use a single agent. If 3+, consider specialization.
Can subtasks run independently? If yes, use parallel fan-out. If they must be sequential, use a pipeline.
Is there a clear coordinator role? If yes, use hierarchical. If peers should collaborate, use mesh.
Does the task benefit from multiple perspectives? If yes, use debate. If not, skip the overhead.
Is the workflow predictable or emergent? Predictable workflows fit pipelines and hierarchies. Unpredictable workflows need mesh or swarm patterns.
Most production systems start with a hierarchical (manager-worker) pattern because it is the easiest to debug, test, and operate. You can always evolve toward more complex patterns as you learn where the bottlenecks and failure modes are.
Multi-agent systems need communication mechanisms. The three most common patterns:
Message passing. Agents send structured messages to each other, like internal emails. Each message has a sender, recipient, content, and type (request, response, feedback). This is explicit and traceable -- you can log every message and replay conversations. But it requires knowing who to send messages to, which means the system topology must be designed upfront.
Shared blackboard. All agents read from and write to a shared state -- a document, database, or memory store. Agents monitor the blackboard for changes relevant to them. The researcher writes data to the blackboard; the writer watches for new data and starts drafting. This is flexible and decoupled (agents do not need to know about each other) but can create coordination challenges when multiple agents write simultaneously.
Event bus. Agents publish events ("research_complete", "draft_ready", "review_failed") and subscribe to events they care about. This is the most scalable pattern -- adding a new agent just means subscribing to relevant events. But it is harder to debug because the communication flow is implicit and asynchronous.
In practice, production systems often combine patterns. A hierarchical system uses message passing between the manager and workers, with a shared blackboard for the work products.
Notice the structured format: clear sender/recipient, typed messages, included metadata about sources and confidence. This is not just good practice -- it is what makes debugging and tracing possible. When something goes wrong, you can follow the message chain to find where the breakdown occurred.
Model Context Protocol (MCP) is the standard protocol for connecting agents to tools.
Before MCP, every tool integration was custom. Want your agent to use a database? Write custom code. Want it to use a different database? Write different custom code. Want to switch from PostgreSQL to MySQL? Rewrite everything. MCP standardizes this. A tool server exposes capabilities via MCP, and any MCP-compatible agent can discover and use them without custom integration.
MCP uses JSON-RPC 2.0 as its message format and defines a client-server architecture:
MCP Client -- The agent side. It discovers available tools, sends tool call requests, and receives results. Any MCP-compatible LLM application (Claude, a custom agent, an IDE extension) can be a client.
MCP Server -- The tool side. It registers tools with their schemas, receives requests, executes tools, and returns results. A server might expose filesystem tools, database tools, API tools, or anything else.
Transport -- The communication layer between client and server. MCP supports stdio (local processes), HTTP with Server-Sent Events (remote servers), and direct HTTP (stateless requests).
The protocol standardizes four operations: (1) discover what tools exist via tools/list, (2) understand tool schemas, (3) call tools with tools/call, and (4) receive structured results. It decouples agents from tools the same way USB-C decouples devices from chargers -- plug in any compatible tool, and it just works.
Select a tool above and step through the JSON-RPC message flow. Notice how the client initiates a request, the server routes it to the appropriate tool, the tool executes and returns a result, and the response flows back through the protocol layers. Click on different tool examples (web_search, read_file, run_code) to see how MCP handles different types of tool calls.
If MCP connects agents to tools, A2A (Agent-to-Agent Protocol) connects agents to each other. A2A is an emerging protocol that enables agents to discover other agents, understand their capabilities, delegate tasks, and receive results -- even across different platforms and organizations.
A2A defines three key concepts:
Agent Card -- A machine-readable description of an agent's capabilities, like a resume. It includes what the agent can do, what inputs it accepts, and what outputs it produces. An image analysis agent might advertise: "I can analyze images, detect objects, extract text from photos, and describe visual content."
Task Negotiation -- How one agent requests help from another. Agent A says: "I need this image analyzed." Agent B evaluates whether it can handle the task, negotiates parameters, and either accepts or declines.
Result Exchange -- How the results are returned. Structured, standardized output that the requesting agent can parse and use, regardless of how the receiving agent produced it.
A2A is to multi-agent systems what HTTP is to the web: a common language that enables interoperability. An agent built with one framework can collaborate with an agent built with another, as long as both speak A2A.
MCP is for agent-to-tool communication. Your agent needs to call a function, query a database, or access a file. MCP standardizes how the agent discovers the tool, calls it, and receives results. Think of MCP as the protocol for an agent's hands -- how it interacts with the world.
A2A is for agent-to-agent communication. Your agent needs help from another agent -- a specialist with different capabilities. A2A standardizes how agents discover each other, negotiate tasks, and exchange results. Think of A2A as the protocol for an agent's social skills -- how it collaborates with peers.
In a multi-agent system, you typically use both: MCP for each agent's tool interactions, and A2A for inter-agent coordination. The researcher agent uses MCP to call search tools, and A2A to send its findings to the writer agent.
One of the most important capabilities for agents is Retrieval-Augmented Generation (RAG) -- the ability to ground responses in external knowledge. Instead of relying solely on training data (which is frozen in time and may lack specific domain knowledge), a RAG-equipped agent can search a knowledge base and include relevant documents in its context before generating a response.
RAG is not a multi-agent pattern by itself, but it is a critical building block for multi-agent systems. A researcher agent uses RAG to find relevant documents. A writer agent uses RAG to fact-check claims. A support agent uses RAG to find answers in the company knowledge base.
The RAG pipeline has two phases:
Indexing phase (offline): Documents are split into chunks, each chunk is embedded into a vector, and vectors are stored in a vector database (ChromaDB, Pinecone, FAISS, Weaviate). This happens once per knowledge base update.
Query phase (real-time): The user's question is embedded using the same model, the nearest document vectors are found via similarity search, and the retrieved chunks are included in the LLM's prompt as context. The LLM generates an answer grounded in the retrieved documents rather than relying on its training data alone.
Loading visualization...
Step through the RAG pipeline above to see how documents are chunked, embedded into vectors, stored in an index, and then retrieved based on semantic similarity to a user's question. Watch the embedding space visualization to see how the query vector finds the nearest document vectors.
What Do You Think?
Three agents debate an answer to a complex question. Do you get better or worse results than a single agent?
Research shows that multi-agent debate improves output quality for tasks requiring judgment, nuance, and reasoning -- like risk assessment, ethical analysis, and strategy recommendations. The adversarial structure forces consideration of counterarguments that a single agent would miss. For simple factual questions ("What is the capital of France?"), a single agent is faster, cheaper, and just as accurate. The overhead of coordination only pays off when the task complexity justifies it.
Introduces ChatDev, where multiple LLM agents assume different roles (CEO, CTO, programmer, tester) and collaborate through natural language conversation to develop complete software projects. A landmark demonstration that multi-agent role-playing can produce coherent, functional code from high-level descriptions.
pythonplayground.py · Pyodide
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
Tests · Create 3 specialist agents and a supervisor. Route 4 tasks to the correct workers based on skill. Verify all tasks complete. Add parallel execution for independent tasks.
Tests · Verify the pipeline runs three agents in sequence. Verify each agent's output includes its name. Add a fourth agent and verify the chain extends correctly.
#Real-World Example: Multi-Agent Systems in Production
ChatGPT's internal architecture uses multiple specialized models working together -- one for safety, one for helpfulness, one for formatting. When you send a message, it does not go to a single monolithic model. A safety classifier checks the input, a routing layer selects the appropriate model, the main model generates a response, another safety layer checks the output, and a formatting layer structures the final reply. This is a production multi-agent pipeline operating at massive scale, serving hundreds of millions of users. The same pattern powers most modern AI products -- what appears to be "one AI" is often a team of specialized agents collaborating behind the scenes.
Specialization, parallelism, and diversity motivate multi-agent systems. Just as companies divide work among specialists, multi-agent systems assign different roles (researcher, coder, reviewer) to agents with focused expertise
Five architectures cover most multi-agent patterns. Supervisor (one coordinator), pipeline (sequential handoffs), debate (agents argue to consensus), swarm (emergent coordination), and hierarchical (nested teams)
MCP standardizes agent-to-tool communication. The Model Context Protocol provides a uniform interface for connecting agents to tools and data sources, replacing custom integrations with a common standard
Multi-agent systems add complexity that must be justified. Only use multiple agents when a single agent demonstrably fails due to task complexity, context window limits, or the need for parallel execution; start simple and scale up
The field is evolving rapidly. Several trends are shaping where multi-agent systems are headed:
Standardization. MCP and A2A are still early, but they represent a shift toward interoperability. Just as RESTful APIs standardized web service communication, these protocols will standardize agent communication. This means agents built by different teams, using different frameworks, running on different infrastructure, will be able to collaborate seamlessly.
Agent marketplaces. Imagine an app store for agents. Need an image analysis agent? Browse the marketplace, check its agent card, and integrate it via A2A. Need a compliance checking agent? Subscribe to one rather than building it in-house. This is already emerging: MCP server registries let you discover and connect to tools, and A2A agent cards will enable the same for agents themselves.
Cost optimization. Today, multi-agent systems are expensive because every agent uses a frontier model. Future systems will mix model tiers: use a small, fast model for the router agent, a medium model for the researcher, and a frontier model only for the critic that needs maximum reasoning capability. This "model routing" within a team can reduce costs by 70-80% while maintaining quality.
Self-organizing teams. Current multi-agent systems have fixed architectures designed by humans. Future systems may dynamically form teams based on the task. The system analyzes the request, determines what skills are needed, recruits the right agents, and dissolves the team when the task is complete. This is the swarm pattern at scale.
Evaluation and safety. As agents become more autonomous, the need for robust evaluation grows. How do you test a system where the execution path is determined at runtime? How do you ensure safety when agents can delegate to other agents? These are open research questions that will define the field's trajectory.
The frameworks that matter for shipping multi-agent systems today:
LangGraph (LangChain, 2024). Agents as a typed state graph with explicit nodes (agents) and edges (handoffs). Cycles, checkpoints, and human-in-the-loop are first-class. The most-adopted multi-actor framework in production as of 2025.
OpenAI Swarm and Agents SDK (2024-2025). Minimal handoff-and-tools abstraction over the OpenAI API; the Agents SDK adds tracing, guardrails, and the Responses API. Good fit when you are already deep on OpenAI.
CrewAI (2024). Role-based teams (researcher, writer, critic) with explicit task assignment. Easiest mental model; weakest at custom control flow.
AutoGen v0.4+ (Microsoft, 2024-2025) — conversation-driven, with strong code execution and a v0.4 redesign around event-driven actors.
A2A (Google, 2024-2025) and MCP (Anthropic, 2024). The two emerging interoperability standards. MCP standardizes agent-to-tool (and is the dominant tool protocol in 2025); A2A standardizes agent-to-agent task delegation across organizations.
The frameworks differ less than they look. They all reduce to: who speaks next (turn-taking), who can call what (capability surfaces), and how state is shared (working memory, handoff payloads). Pick on the team's familiarity, not on benchmark claims.
You now understand how teams of specialized agents collaborate -- from sequential pipelines to hierarchical managers to adversarial debate. You have seen MCP for tool access and A2A for inter-agent communication. But how do you know if your agents are actually working well? Next up: Agent Evaluation, where we tackle the hardest question in agentic AI -- measuring quality when behavior is non-deterministic.