Multi-Agent Systems and Collaboration · Multi-Agent Systems Engineering

There is a moment in scaling a single agent when adding more capability makes it worse. The system prompt grows to two thousand words covering research, writing, fact-checking, and formatting; twelve tools crowd the context; and the model, asked to be a researcher and an editor and a critic simultaneously, does all three at a mediocre level and confuses their goals. You have built a committee inside one prompt, and it has the decision-making quality of a committee. The instinct that fixes it is the oldest one in organizational history: divide the labor.

A multi-agent system is several specialized agents — each with its own focused prompt, tools, and role — cooperating on a task none would handle well alone. A researcher that only researches, a writer that only writes, a critic that only critiques: each is simpler, more testable, and better at its one job than the generalist was at all of them. You already know how to build each individual agent — that was the business of Agent Frameworks in Depth. This course is about what happens when you connect them, and its central thesis fits in one sentence: multi-agent is a scaling decision, not an aesthetic. Done right, it buys you parallelism, context isolation, and specialization. Done wrong, it multiplies cost and compounds errors.

The numbers are not subtle. When Anthropic published the engineering account of its multi-agent research system in 2025 — still the canonical case study, and one this course returns to repeatedly — it reported that a single agent uses roughly 4x the tokens of a chat interaction, and a multi-agent system roughly 15x. The same system beat a single-agent baseline by 90.2% on internal research evals. Both numbers are true at once, and that tension — dramatic capability gains priced in dramatic token multiples — is what this lesson introduces: what multi-agent systems are, a first working example, and the promise and peril every later lesson develops.

1. Why More Agents, Not a Bigger Prompt

Five forces justify splitting one agent into several. Each is a real engineering property, not a metaphor — and each will get a full treatment later in the course:

Force	What it buys
Focus	A single-role prompt and a small tool set outperform a kitchen-sink prompt with twelve tools — less to confuse the model, fewer ways to blend goals
Separation of concerns	Each agent is independently testable and swappable; you can improve the writer without touching the researcher
Context isolation	Each agent gets a clean window. A subagent that never saw the parent's 150K-token transcript cannot be anchored by it, and its own work does not crowd the parent's window
Diverse perspectives	A critic that did not write the draft catches what the author is blind to — the same independence that makes LLM-as-judge evaluation work
Parallelism	Independent subtasks run at once — three researchers on three sub-questions finish in roughly one researcher's wall-clock time

Notice what is absent from the table: "it feels more like a team", "the demo looks impressive". Those are the reasons most over-built systems get built. When a force genuinely applies, multi-agent earns its 15x; when none does, you are paying the multiple for an org chart.

2. The Collaboration Patterns, at a Glance

Three topologies cover most production systems, and they mirror how humans organize. Lesson 3 catalogs seven; these are the ones you will actually ship first:

Supervisor (orchestrator-workers) — a coordinator agent owns the goal and delegates subtasks to specialists, collecting and synthesizing their results. The manager model. Most controllable, easiest to debug, the right default.
Pipeline (sequential) — output of one agent is input to the next: researcher → writer → editor. The assembly line. Simple when the task has a natural order.
Debate (peer) — agents with different stances argue toward a better answer than any would reach alone, sometimes with a judge to call it. The panel. Powerful for judgment calls, expensive, hardest to control.

Every one of these is assembled from parts you already own: each node is an ordinary agent — a model, a system prompt, some tools, a loop — and the topology is just the code that routes work between them. Debugging therefore decomposes into two familiar questions: is each agent correct in isolation, and is the routing between them faithful?

3. Building a Supervisor System

Concretely, and deliberately framework-free so the mechanism is visible. A supervisor plus three specialists — researcher, writer, critic — assembled from plain API calls:

python

import anthropic

client = anthropic.Anthropic()

def agent(role_system: str, task: str,
          model: str = "claude-opus-5") -> str:
    response = client.messages.create(
        model=model, max_tokens=1024,
        system=role_system,
        messages=[{"role": "user", "content": task}],
    )
    return "".join(b.text for b in response.content if b.type == "text")

# --- specialists: each does ONE thing well ---------------------------
def researcher(topic: str) -> str:
    return agent(
        "You are a research analyst. Given a topic, list the 4-5 key "
        "facts and considerations concisely as bullet points. Be "
        "specific; flag anything uncertain.",
        "Research: " + topic)

def writer(topic: str, research: str) -> str:
    return agent(
        "You are a technical writer. Turn research notes into a clear, "
        "tight 150-word explainer. Use only what the notes support.",
        "Topic: " + topic + "\n\nResearch notes:\n" + research)

def critic(draft: str) -> str:
    return agent(
        "You are an editor. Point out the single weakest sentence and "
        "one factual claim that should be verified. Two lines max.",
        "Draft:\n" + draft)

# --- supervisor: owns the goal, delegates, synthesizes ---------------
def supervise(topic: str) -> dict:
    notes = researcher(topic)                 # delegate research
    draft = writer(topic, notes)              # delegate writing
    review = critic(draft)                    # delegate critique
    return {"research": notes, "draft": draft, "critique": review}

out = supervise("Why grouped-query attention reduces LLM serving cost")
print(out["draft"])
print("\n--- editor ---\n" + out["critique"])

Each specialist has a short, sharp prompt — the opposite of the two-thousand-word generalist — and the supervisor is just the code that routes work between them. Three structural details deserve attention. The writer receives the original topic alongside the research notes, not the notes alone — passing the goal at every hop is the cheapest insurance against drift, and Lesson 5 makes it a rule. The critic sees only the draft — its independence is the point. And nothing here is parallel yet: wall-clock time is the sum of three model calls, and parallelism must be earned by finding genuinely independent subtasks, Lesson 4's whole subject. In production the same topology becomes a graph in the framework you learned in Agent Frameworks in Depth — each agent a node, the supervisor a routing node, the whole thing checkpointed and observable. The shape survives the translation.

4. Watch the Economics: A Mock Pipeline You Can Run

You do not need an API key to see the coordination tax — you need a token ledger. The cell below rebuilds the supervisor pipeline with deterministic mock agents and counts every token that crosses an agent boundary (estimated at four characters per token, close enough for accounting). Run it and compare the pipeline's bill to a single generalist call on the same task.

pythoneditable · runnable

# The supervisor pipeline with MOCK agents: no network, real economics.
GOAL = "Explain why grouped-query attention reduces LLM serving cost."

def toks(text):                    # ~4 chars per token
    return max(1, len(text) // 4)

NOTES = ("- GQA shares one K/V head across a group of query heads\n"
         "- KV cache shrinks by the group factor (e.g. 8x)\n"
         "- Smaller cache = more concurrent sequences per GPU\n"
         "- Quality within ~1% of full multi-head attention\n"
         "- Used by Llama-2-70B onward; uncertain: exact serving gain")
DRAFT = ("Grouped-query attention (GQA) lets several query heads share "
         "a single key/value head. Because the KV cache stores one "
         "entry per K/V head per token, sharing shrinks the cache by "
         "the group factor - often 8x. The cache, not compute, is what "
         "limits how many requests a GPU can serve at once, so a "
         "smaller cache means more concurrent users per card and "
         "cheaper serving, at a quality cost measured near one percent.")
REVIEW = ("Weakest sentence: the last (two claims, one breath). "
          "Verify: the 'near one percent' quality figure.")

MOCK = {"researcher": NOTES, "writer": DRAFT, "critic": REVIEW}
ledger = []

def call(name, system, context):
    ledger.append((name, toks(system) + toks(context), toks(MOCK[name])))
    return MOCK[name]

# --- three-agent pipeline: context is RE-SENT at every hop -----------
r_sys = "You are a research analyst. List key facts as bullets."
w_sys = "You are a technical writer. Notes -> tight 150-word explainer."
c_sys = "You are an editor. Weakest sentence + one claim to verify."

notes  = call("researcher", r_sys, GOAL)
draft  = call("writer",     w_sys, GOAL + "\n" + notes)   # goal + notes
review = call("critic",     c_sys, draft)

pipe_in  = sum(i for _, i, _ in ledger)
pipe_out = sum(o for _, _, o in ledger)

# --- one generalist call on the same task ----------------------------
g_sys = ("You are researcher, writer and editor in one. Research the "
         "topic, write a 150-word explainer, then critique it.")
gen_in  = toks(g_sys) + toks(GOAL)
gen_out = toks(DRAFT) + toks(REVIEW)

print(f"{'agent':<12}{'in':>6}{'out':>6}")
for name, i, o in ledger:
    print(f"{name:<12}{i:>6}{o:>6}")
print("-" * 24)
print(f"{'pipeline':<12}{pipe_in:>6}{pipe_out:>6}")
print(f"{'generalist':<12}{gen_in:>6}{gen_out:>6}")
ratio = (pipe_in + pipe_out) / (gen_in + gen_out)
print(f"\npipeline / generalist total: {ratio:.1f}x")

# The supervisor pipeline with MOCK agents: no network, real economics.
GOAL = "Explain why grouped-query attention reduces LLM serving cost."

def toks(text):                    # ~4 chars per token
    return max(1, len(text) // 4)

NOTES = ("- GQA shares one K/V head across a group of query heads\n"
         "- KV cache shrinks by the group factor (e.g. 8x)\n"
         "- Smaller cache = more concurrent sequences per GPU\n"
         "- Quality within ~1% of full multi-head attention\n"
         "- Used by Llama-2-70B onward; uncertain: exact serving gain")
DRAFT = ("Grouped-query attention (GQA) lets several query heads share "
         "a single key/value head. Because the KV cache stores one "
         "entry per K/V head per token, sharing shrinks the cache by "
         "the group factor - often 8x. The cache, not compute, is what "
         "limits how many requests a GPU can serve at once, so a "
         "smaller cache means more concurrent users per card and "
         "cheaper serving, at a quality cost measured near one percent.")
REVIEW = ("Weakest sentence: the last (two claims, one breath). "
          "Verify: the 'near one percent' quality figure.")

MOCK = {"researcher": NOTES, "writer": DRAFT, "critic": REVIEW}
ledger = []

def call(name, system, context):
    ledger.append((name, toks(system) + toks(context), toks(MOCK[name])))
    return MOCK[name]

# --- three-agent pipeline: context is RE-SENT at every hop -----------
r_sys = "You are a research analyst. List key facts as bullets."
w_sys = "You are a technical writer. Notes -> tight 150-word explainer."
c_sys = "You are an editor. Weakest sentence + one claim to verify."

notes  = call("researcher", r_sys, GOAL)
draft  = call("writer",     w_sys, GOAL + "\n" + notes)   # goal + notes
review = call("critic",     c_sys, draft)

pipe_in  = sum(i for _, i, _ in ledger)
pipe_out = sum(o for _, _, o in ledger)

# --- one generalist call on the same task ----------------------------
g_sys = ("You are researcher, writer and editor in one. Research the "
         "topic, write a 150-word explainer, then critique it.")
gen_in  = toks(g_sys) + toks(GOAL)
gen_out = toks(DRAFT) + toks(REVIEW)

print(f"{'agent':<12}{'in':>6}{'out':>6}")
for name, i, o in ledger:
    print(f"{name:<12}{i:>6}{o:>6}")
print("-" * 24)
print(f"{'pipeline':<12}{pipe_in:>6}{pipe_out:>6}")
print(f"{'generalist':<12}{gen_in:>6}{gen_out:>6}")
ratio = (pipe_in + pipe_out) / (gen_in + gen_out)
print(f"\npipeline / generalist total: {ratio:.1f}x")

The pipeline costs roughly twice the generalist's tokens on this toy task — and the mock is charitable, since real agents carry tool schemas and accumulated history in every call. Notice where the money goes: the writer's input includes the researcher's entire output, re-sent and re-billed. Every arrow in a multi-agent diagram is a place where the same tokens get paid for again; multiply by longer contexts and more hops and the 15x figure stops being surprising. The question is never whether the tax exists — it is whether the quality delta pays it.

5. The Debate Pattern

When a decision benefits from adversarial scrutiny, have two agents take opposing stances and a third judge the exchange — independence catching errors a single reasoner would rationalize away:

python

def debate(question: str, rounds: int = 2) -> str:
    transcript = "Question: " + question + "\n"
    for i in range(rounds):
        pro = agent("You argue FOR the proposition. Make the strongest "
                    "case, concede nothing unearned.", transcript)
        transcript += "\n[FOR round " + str(i + 1) + "]: " + pro + "\n"
        con = agent("You argue AGAINST. Rebut the last point specifically.",
                    transcript)
        transcript += "\n[AGAINST round " + str(i + 1) + "]: " + con + "\n"
    verdict = agent("You are an impartial judge. Weigh the arguments and "
                    "give a reasoned conclusion. Note what each side got "
                    "right.", transcript)
    return verdict

Debate reliably surfaces considerations a single agent skips, but the transcript grows every round and every agent re-reads all of it — token cost quadratic in rounds, on top of the per-agent multiple — and it can amplify confident nonsense when neither side is grounded in retrieved facts. Reserve it for judgment calls where the cost of being wrong exceeds the cost of the argument, and cap the rounds.

6. Where Multi-Agent Systems Break

Multi-agent systems fail in ways single agents cannot, precisely at the seams between agents. The MAST taxonomy (from the 2025 study Why Do Multi-Agent LLM Systems Fail?, which analyzed over 150 traces across popular frameworks) found that inter-agent misalignment — agents miscommunicating, withholding, or ignoring each other — accounts for roughly a third of all failures. The recurring modes:

Telephone-game drift — each handoff is a lossy re-encoding; by the fourth agent the task has quietly mutated. Mitigation: pass the original goal alongside intermediate results at every hop, never just the last output.
Cost multiplication — N agents each carrying context is N times the token bill at minimum, and debate multiplies again by rounds. Budget the system, not just each agent — Lesson 6 builds the machinery.
Conflicting outputs — two agents assert incompatible things and nothing resolves it. Supervisor topologies handle this best: someone is explicitly in charge of reconciliation (Lesson 5 covers the strategies).
Error propagation — the researcher's hallucination becomes the writer's premise becomes the published claim. Five 90%-reliable steps chain to 59% end-to-end reliability; Lesson 2 does the math. A critic agent is partly a firewall against exactly this, which is why the pattern recurs.

The design principle underneath every mitigation echoes human organizations: clear roles, explicit handoffs, one owner of the goal. When you cannot name which agent owns reconciliation, you have found tomorrow's incident.

7. The Promise, the Peril, and the Road Ahead

Hold both halves of the evidence at once. The promise: Anthropic's research system — an Opus lead orchestrating parallel Sonnet subagents — beat the single-agent baseline by 90.2%, and token spend alone explained most of the variance: the architecture wins largely because it spends more tokens across parallel context windows. The peril: that same 15x bill lands on every query, including the trivial ones, unless you engineer it not to — and every added agent widens the failure surface the MAST taxonomy catalogs.