Why This Matters

As AI applications become more complex, expecting one model to handle every task becomes inefficient. Consider a business request: "Prepare next week's executive project review." Completing this requires retrieving project data, reading meeting notes, checking budgets, reviewing risks, generating charts, writing the presentation and verifying company policies.

Instead of asking one AI to do everything, multiple specialized agents can work together. Each agent focuses on its expertise.

Everyday Analogy

Imagine building a house. One person could attempt every task. Or a team of specialists could work together: architect, electrician, plumber, carpenter and painter. Each contributes expertise. The finished house is completed faster and with higher quality.

Multi-Agent AI works the same way.

What Is an AI Agent?

An AI agent is an intelligent software component capable of understanding goals, making decisions, using tools, planning tasks and producing outputs. An agent performs work independently within defined boundaries.

What Is a Multi-Agent System?

A Multi-Agent System consists of multiple agents working toward a shared objective. Example: Research Agent → Planning Agent → Writing Agent → Review Agent → Publishing Agent. Each agent performs a specific responsibility.

Why Use Multiple Agents?

Advantages include specialization, parallel execution, better scalability, improved maintainability, reduced complexity and better fault isolation. Large enterprise workflows become easier to manage. Anthropic's own 2024 engineering write-up "Building Effective Agents" makes a pointed recommendation here: start with the simplest possible architecture (a single well-prompted agent, or even a single LLM call with tools) and only introduce multiple agents when a single agent's context becomes unwieldy or its responsibilities genuinely don't compose. Multi-agent systems trade simplicity for capability, and that trade is not always worth making.

Single Agent vs Multi-Agent

A single agent handles everything through one AI. Advantages: simple architecture and easy deployment. Limitations: large prompts, limited specialization and harder to scale. A single agent juggling "research the topic, write the draft, and critique your own work" tends to blur all three roles into one undifferentiated pass; it never truly adopts the adversarial stance a dedicated critic would.

A multi-agent system uses a coordinator that delegates to specialized agents and combines their results. Advantages: modular, scalable, easier maintenance and higher quality, at the cost of more moving parts to monitor and more tokens spent on inter-agent communication.

Dimension	Single agent	Multi-agent system
Context size per call	Grows with every added responsibility	Stays small per agent (AI-020)
Latency	One model call (plus tool calls)	Higher — coordination and hand-offs add round trips, though parallel branches offset some of this
Cost per request	Lower — one model, one context	Higher — multiple model calls, sometimes multiple models at different price points
Quality on complex, multi-step tasks	Degrades as responsibilities pile up in one prompt	Improves — genuine separation of concerns, especially for critique
Debuggability	One trace to read	Requires per-agent tracing and a way to see the whole conversation between agents
Best fit	Narrow, well-defined tasks	Tasks that decompose into genuinely distinct roles (research vs. writing vs. review)

Coordinator Agent

Responsible for understanding requests, delegating work, combining results and managing workflow. Acts as the project manager.

Research Agent

Responsibilities: search documents, retrieve knowledge, gather evidence and find references.

Planning Agent

Creates plans, strategies, task breakdowns and priorities.

Analysis Agent

Responsible for data analysis, trend detection, calculations and comparisons.

Writing Agent

Creates reports, emails, documentation and summaries.

Review Agent

Verifies accuracy, completeness, policy compliance and formatting.

Tool Agent

Uses MCP servers, APIs, databases and business applications. Acts as the integration specialist.

Multi-Agent Workflow

User Request → Coordinator Agent → Research Agent / Planning Agent / Analysis Agent (parallel) → Writing Agent → Review Agent → Final Response.

Multiple agents may execute simultaneously.

Sequential Collaboration

Agent A → Agent B → Agent C. Useful when later work depends on earlier results.

Parallel Collaboration

Agent A / Agent B / Agent C running simultaneously → Coordinator merges results. Useful when tasks are independent.

Hierarchical Architecture

Manager Agent → Specialist Agents → Final Decision. Common in enterprise systems.

Swarm Architecture

Multiple agents communicate directly. Suitable for distributed problem solving. More flexible but harder to coordinate.

Agent Memory

Agents may use short-term memory (current workflow), long-term memory (previous conversations), shared memory (information accessible by every agent) and private memory (agent-specific knowledge). Memory enables better collaboration.

Communication Between Agents

Agents exchange tasks, results, context, plans, feedback and status updates. Clear communication improves coordination.

Conflict Resolution

Sometimes agents disagree. Example: Research Agent recommends Option A. Analysis Agent recommends Option B. Coordinator Agent resolves the conflict and makes a final decision. The coordinator ensures consistent outcomes.

Human-in-the-Loop

Enterprise systems often require human approval. Example: Legal Agent generates a contract → Human Lawyer reviews → Approval → Customer. Humans remain responsible for critical decisions.

The placement of the human gate matters as much as its existence. Gate too early (before any agent work happens) and you lose the efficiency multi-agent systems are supposed to provide. Gate too late (only after the final customer-facing output) and a human reviewing a fully-formed report has to either trust it wholesale or redo the analysis themselves, since there's no efficient middle ground for catching a research agent's bad source three steps upstream. The newsroom pipeline in this lesson places its gate after the critic agent has already caught unsupported claims, so the human editor is reviewing something already vetted, not a raw first draft. That ordering is itself a design decision worth defending explicitly in any architecture review.

Choosing a Coordination Topology

Topology	How agents communicate	Coordination overhead	When it breaks down
Centralized (coordinator hub)	All agents talk only to the coordinator	Low — one place to add logging, retries, and policy	Coordinator becomes a bottleneck as agent count grows past roughly 5-8
Hierarchical	Manager delegates to sub-managers, who delegate to specialists	Moderate — scales better than centralized for large agent counts	Adds latency layers; a request can cross 3+ hops before reaching the specialist that actually does the work
Swarm / peer-to-peer	Agents message each other directly	High — no single place to enforce policy or trace a request	Hard to debug, hard to guarantee any global property (like "never exceed budget X") holds

Most production enterprise systems described publicly, such as Klarna's support pipeline or GitHub's multi-agent coding assistants, use centralized or shallow hierarchical topologies, not swarms, precisely because centralized coordination makes logging, cost control, and human hand-off tractable. Swarm architectures show up more in research settings where flexibility matters more than auditability.

A Runnable Multi-Agent Skeleton

Below is a simplified but realistic three-agent pipeline (researcher, writer, critic) implemented with plain Python functions standing in for LLM calls. It shows the core pattern: each agent has a narrow interface (defined inputs and outputs), the critic can send work back to the writer, and there's a hard iteration limit so a disagreement loop can't run forever.

from dataclasses import dataclass, field


@dataclass
class ResearchNote:
    claim: str
    source: str


@dataclass
class AgentTrace:
    steps: list = field(default_factory=list)

    def log(self, agent: str, action: str):
        self.steps.append(f"[{agent}] {action}")


def researcher_agent(topic: str, trace: AgentTrace) -> list[ResearchNote]:
    # Stand-in for an LLM call with web-search/RAG tools (see AI-016, AI-018).
    trace.log("researcher", f"gathered 3 notes on '{topic}'")
    return [
        ResearchNote("Q3 revenue grew 12% YoY", "internal-finance-report.pdf"),
        ResearchNote("Customer churn dropped to 4.1%", "cs-dashboard-export.csv"),
        ResearchNote("New APAC region launched in July", "board-minutes-q3.pdf"),
    ]


def writer_agent(notes: list[ResearchNote], trace: AgentTrace) -> str:
    # The writer may ONLY use provided notes — a deliberate grounding
    # constraint that prevents fabrication (see AI-060).
    draft_lines = [f"- {n.claim} (source: {n.source})" for n in notes]
    trace.log("writer", f"drafted report from {len(notes)} notes")
    return "Quarterly Report Draft:\n" + "\n".join(draft_lines)


def critic_agent(draft: str, notes: list[ResearchNote], trace: AgentTrace) -> tuple[bool, list[str]]:
    # Checks every claim in the draft traces back to a source note.
    issues = []
    for line in draft.splitlines():
        if line.startswith("- ") and "(source:" not in line:
            issues.append(f"Unsupported claim: {line}")
    passed = len(issues) == 0
    trace.log("critic", "passed" if passed else f"found {len(issues)} issue(s)")
    return passed, issues


def run_newsroom_pipeline(topic: str, max_revisions: int = 2) -> tuple[str, AgentTrace]:
    trace = AgentTrace()
    notes = researcher_agent(topic, trace)
    draft = writer_agent(notes, trace)

    for revision in range(max_revisions):
        passed, issues = critic_agent(draft, notes, trace)
        if passed:
            trace.log("coordinator", "released to human editor")
            return draft, trace
        trace.log("coordinator", f"revision {revision + 1}: sending back to writer")
        draft = writer_agent(notes, trace)  # writer retries using the same grounded notes

    trace.log("coordinator", "max revisions reached — escalating to human editor")
    return draft, trace


if __name__ == "__main__":
    final_draft, trace = run_newsroom_pipeline("Q3 executive summary")
    print(final_draft)
    print("\n".join(trace.steps))

The key design decisions worth noticing: the writer's function signature only accepts notes, not a free-form "do research yourself" instruction; that's the grounding constraint enforced in code, not just in a prompt. The critic returns structured issues rather than a prose opinion, so the coordinator logic can act on it programmatically. And max_revisions prevents an infinite writer-critic ping-pong, escalating to a human instead of looping forever: the multi-agent equivalent of the retry-limit pattern from AI-031.

Failure Modes in Multi-Agent Systems

Context leakage between agents. If the coordinator naively forwards the entire conversation history to every specialist, each agent's context balloons back up to single-agent size, erasing the main benefit (small, focused context per role, AI-020) while still paying the coordination overhead.
Infinite critique loops. Without a hard revision cap like max_revisions above, a strict critic and a writer that can't satisfy it will bounce work back and forth indefinitely, burning tokens and never reaching a human.
Coordinator becomes a bottleneck. If every inter-agent message must round-trip through the coordinator for approval, latency stacks up linearly with the number of agents. Sometimes it's faster to let specialist agents hand off directly for narrow, well-understood exchanges.
Duplicated work across agents. Two agents both independently fetch the same customer record or re-derive the same calculation because there's no shared memory layer, wasting both latency and cost.
Security boundary violations. A tool agent with database write access gets invoked by a "writing agent" prompt injected with instructions to also modify records. Without per-agent scoped permissions (AI-027), a compromised or confused agent can act outside its intended role.

Case study: multi-agent code review at scale

Cognition Labs' Devin and, more measurably, GitHub's Copilot Workspace and multi-agent coding assistants reported in 2024 that decomposing a single "fix this bug" request into a planner agent (breaks the task into file-level steps), an implementer agent (writes the diff), and a reviewer agent (runs tests and checks the diff against the plan) measurably reduced the rate of merged PRs that had to be reverted, compared to a single-pass agent attempting the same fix in one shot. The pattern mirrors the newsroom pipeline above almost exactly: a grounded producer role, a separate adversarial checker role, and a hard cap on retry loops before a human takes over. The common thread across every credible multi-agent production deployment, whether it's Klarna's escalation path (AI-031), coding-assistant review loops, or the newsroom pipeline here, is that the "second opinion" agent is what catches errors a single agent reliably misses when reviewing its own work, precisely because it starts from a fresh context rather than the same one that produced the mistake.

Enterprise Example

An AI project management platform receives: "Prepare the quarterly executive report." The Coordinator Agent delegates to Jira Agent, Finance Agent, Risk Agent and Writing Agent, then the Review Agent produces the final executive report. Each agent contributes its expertise.

Benefits

Multi-Agent Systems provide better organization, improved scalability, modular design, easier maintenance, faster execution, improved specialization and better reuse.

Challenges

They also introduce coordination complexity, communication overhead, state management, increased monitoring, debugging challenges and higher infrastructure requirements. Good orchestration minimizes these issues.

Best Practices

Keep agents specialized. Clearly define responsibilities. Avoid duplicated work. Minimize unnecessary communication. Log interactions. Monitor workflow performance. Design graceful failure handling.

Common Mistakes

Creating too many agents. Giving agents overlapping responsibilities. Ignoring coordination logic. Sharing excessive context. Forgetting security boundaries. Building agents without observability.

Hands-On Exercise

Design a multi-agent architecture for an AI travel assistant. Create agents for flights, hotels, weather, budget, itinerary and review. Explain how they collaborate.

Mini Project

Design a multi-agent enterprise assistant supporting HR, finance, engineering, sales and customer support. Define the coordinator agent, specialist agents, shared memory, MCP integrations and human approval. Draw the architecture, and specify a revision cap for any agent pair that can send work back to each other, following the pattern in the runnable skeleton above.

Worked Example: A Three-Agent Newsroom

A weekly market-report generator, run as a multi-agent system:

Researcher agent: searches sources, extracts facts with citations, and writes structured notes. Tools: web search, RAG over past reports (AI-016).
Writer agent: turns the notes into a 600-word draft in house style. It gets no search tools; it may only use the researcher's notes (a deliberate grounding constraint, AI-060).
Critic agent: checks the draft against the notes, flagging unsupported claims and scoring tone against a rubric (AI-022). Two failed checks send it back to the writer; a pass releases it to a human editor (AI-053).

Why three agents instead of one mega-prompt? Each context stays small and focused (AI-020), the critic genuinely catches the writer's errors (separation the single agent can't give itself), and each role can use a different model tier (AI-024): researcher on a cheap fast model, critic on a reasoning model (AI-063).

Try It Yourself

Run the pattern manually: in one chat, ask for a draft; in a fresh chat, paste the draft and ask "act as a strict fact-checker: list unsupported claims." The fresh-context critique is consistently sharper than asking the same chat to self-review. You've just felt why multi-agent separation works.
Design your own trio: for a task you do weekly, name three roles, what each may access, and what passes between them. Access control per role is where multi-agent design gets real (AI-027).

Key Takeaways

Multi-Agent Systems divide complex work into specialized responsibilities.
Coordinators manage collaboration.
Agents communicate through structured workflows.
Modular systems are easier to scale and maintain.
Multi-Agent architectures power many advanced enterprise AI platforms.

Multi-Agent Systems

Learning Objectives