ConceptIntermediate 22 min· Agents · 14 of 19

Multi-agent systems and when to avoid them

Multiple agents can split work, but they cost more, lose context and fail in harder-to-debug ways. Learn the main patterns, build a drafter and reviewer, and use a decision ladder to choose the simplest design that works.

After learning agents, the next idea people reach for is "let's use many agents": a researcher, a writer, a critic, a manager. Sometimes this is the right design. More often it is slower, costlier and harder to debug than one agent or a plain pipeline. This lesson shows the patterns and, more importantly, helps you decide.

You should know the agent loop from *AI agents: tools, loops and planning*.

What multi-agent means

A multi-agent system uses several model-driven components, each with its own instructions, and often its own tools, that cooperate on one task. In practice an "agent" here is often just a model call with a different system prompt, sometimes with its own loop.

Analogy: a restaurant kitchen has a head chef, a grill cook and a pastry cook. That helps when the kitchen is busy and the jobs are different. For a single cup of tea, three cooks would only bump into each other.

Common patterns

Pattern	How it works	Example
Orchestrator and workers	A lead agent splits the task, sends sub-tasks to workers, and combines the results	Research: lead splits a question into 4 topics, 4 workers research in parallel
Pipeline (hand-off)	Agent A's output is Agent B's input, in a fixed order	Drafter writes, reviewer checks, formatter outputs JSON
Critic loop	One agent produces, another critiques, repeat until approved or a limit	Code writer and code reviewer
Router	A small agent picks which specialist handles the request	Support bot sends billing questions and technical questions to different agents
Debate or voting	Several agents answer independently and the answers are compared	Hard questions where you want a second opinion

A small example: drafter and reviewer

This is the simplest useful multi-agent pattern. Two separate model calls, each with its own narrow instructions: one writes a reply to a customer complaint, one checks the reply against rules and answers in JSON. There is no framework, just a function that calls the model twice.

two_agents.py

from google import genai
from google.genai import types

client = genai.Client()
MODEL = "gemini-flash-latest"


def ask(system, text, json_output=False):
    """One focused model call with its own instructions and no shared history."""
    config = types.GenerateContentConfig(
        system_instruction=system,
        response_mime_type="application/json" if json_output else None,
    )
    return client.models.generate_content(model=MODEL, contents=text, config=config).text


def write_reply(complaint):
    # Worker 1: a drafter that only writes
    draft = ask(
        "You write short, polite replies for Brew & Bean, a coffee shop. Under 80 words. "
        "Do not promise refunds or discounts.",
        f"Customer complaint:\n{complaint}",
    )
    # Worker 2: a reviewer that only checks, and must answer in JSON
    review = ask(
        "You review customer replies. Check: polite, no promised refund or discount, "
        "no invented facts. Return JSON: {\"ok\": true or false, \"problems\": [strings]}.",
        f"Complaint:\n{complaint}\n\nDraft reply:\n{draft}",
        json_output=True,
    )
    return draft, review


if __name__ == "__main__":
    draft, review = write_reply("My cappuccino was cold and I waited 25 minutes.")
    print("DRAFT:\n" + draft)
    print("\nREVIEW:\n" + review)

A drafter and a reviewer as two focused calls. Needs google-genai and GEMINI_API_KEY.

Why does a separate reviewer help? The model that wrote a draft tends to approve its own work. A second call with a different job ("find problems") and a checklist looks at the text fresh. The JSON output lets your code act on the result: if ok is false, send the problems back to the drafter and try again, up to a limit.

Critic loop with a limit (add to two_agents.py)

import json

MAX_ROUNDS = 3


def write_checked_reply(complaint):
    draft, review = write_reply(complaint)
    for _ in range(MAX_ROUNDS - 1):
        result = json.loads(review)
        if result["ok"]:
            return draft
        # send the reviewer's problems back to the drafter
        draft = ask(
            "You write short, polite replies for Brew & Bean. Under 80 words. "
            "Do not promise refunds or discounts.",
            f"Complaint:\n{complaint}\n\nYour last draft:\n{draft}\n\n"
            f"Fix these problems:\n{result['problems']}",
        )
        review = ask(
            "You review customer replies. Return JSON: {\"ok\": true or false, \"problems\": [strings]}.",
            f"Complaint:\n{complaint}\n\nDraft reply:\n{draft}",
            json_output=True,
        )
    return draft  # after the last round, return the best draft anyway

The round limit is essential. Without it, two agents can disagree forever and you pay for every round.

The costs nobody mentions

What you pay for extra agents

Cost	Why it happens
Money and time	Each agent is at least one model call. A 3-agent pipeline with 2 review rounds is 6 or more calls, in sequence
Lost context	Agents only know what you pass them. Important details get dropped at every hand-off
Compounding errors	If each stage is 90 percent reliable, five stages in a row are only about 59 percent reliable (0.9 x 0.9 x 0.9 x 0.9 x 0.9)
Hard debugging	A bad final answer could come from any agent or any hand-off. You need logs for all of them
Conflicts	Agents that act in parallel can contradict each other or edit the same thing
More attack surface	Text passed between agents can carry injected instructions from one agent to the next

The 59 percent figure is arithmetic on an illustrative 90 percent, not a measured statistic. The point is real, though: reliability multiplies, so more stages need more checking.

When multi-agent actually helps

Good reasons

The task splits into independent parts that can run in parallel (researching 5 competitors).
Different parts need different tools, permissions or instructions that would confuse one prompt (a read-only researcher and a writer).
One context would get too long for a single model call, so workers each handle a slice and return a summary.
You need an independent check (a reviewer with a checklist) and you can measure that it improves results.
You have evidence, from your own evals, that the multi-agent version is better than the simple one.

Bad reasons

"It sounds more advanced."
The steps are fixed and known: use a plain pipeline in code.
One agent with a clear prompt and good tools already works.
The task is short and cheap, and latency matters.
You cannot yet log and replay a run of a single agent.

A decision ladder

Climb only as high as needed

1Try a single prompt. Improve the prompt and examples.
2Add retrieval or tools (RAG, function calling).
3If the steps are fixed, write a workflow in code with one model call per stage.
4If the path depends on what is found, use one agent with tools and limits.
5Only if measurements show a limit, try multiple agents. Keep the first version to two or three.

Making multi-agent systems safer

Checklist

Give each agent the minimum tools. A reviewer should have none.
Pass structured data (JSON with a schema) between agents, not free text, and validate it.
Set limits per agent and for the whole run: steps, tokens, time and rounds.
Log every message between agents with a run id, so a bad run can be replayed.
Put a human approval step before any real-world action (sending, paying, deleting).
Evaluate the whole system on a test set, and compare against the single-agent baseline (see *Evaluating AI apps (evals)*).

You will meet frameworks for this (for example LangGraph, CrewAI, the OpenAI Agents SDK and Google's Agent Development Kit). They save time on plumbing, but they are all the same ideas: calls, tools, loops and hand-offs. Learn the ideas first with plain code, as in this track, and choosing a framework later is easy. Check each framework's own documentation for its current API, as they change quickly.

How this comes up in interviews

Be ready to answer

"When would you use multiple agents?" Independent parallel sub-tasks, different permissions or tools, context limits, or a measurable gain from an independent reviewer.
"What are the downsides?" Cost, latency, lost context, compounding errors, harder debugging, more attack surface.
"How would you evaluate it?" Compare against a single-agent or workflow baseline on a test set for quality, cost and latency.
A strong answer says you would start simple and add agents only when measurements justify it.

Try it: Measure the reviewer

Write 10 complaints. Run write_reply on each. Count how many drafts the reviewer marks ok: false, and read those drafts to decide whether the reviewer was right. Then count how many calls and how many seconds the two-agent version takes compared with a single call that includes the reviewer's checklist in its prompt.

Try it: Design on paper

A client wants an AI that takes a topic, researches 5 sources, writes a 500-word article and checks every fact. Draw the system two ways: as one agent with tools, and as a multi-agent design. List for each the number of model calls, the main risks and how you would test it. Which would you build first and why?

Key takeaways

Multi-agent means several model-driven components with their own instructions or tools. Often an agent is just a differently prompted call.
Common patterns: orchestrator and workers, pipeline, critic loop, router, voting.
Extra agents add cost, latency, lost context, compounding errors and debugging pain, and each hand-off is an injection risk.
Use them for independent parallel work, different permissions, long contexts or a measurable quality gain. Not because it sounds advanced.
Climb a ladder: prompt, then tools and RAG, then workflow, then one agent, then multiple agents. Always limit rounds and compare with a simple baseline.

Check yourself

Finishing the quiz marks the lesson as done.

1. Which situation is the strongest case for multiple agents?

2. A pipeline has 4 stages, each about 90 percent reliable. Roughly how reliable is the whole chain, if errors are independent?

3. Why give the reviewer agent its own call and checklist instead of asking the drafter to 'check your work'?

4. Two agents keep disagreeing and the run never finishes. Which control would have prevented the cost?

5. What should you do before adopting a multi-agent design?

Saved on this device. Create a free account to keep it on every device.

Project: build a research agent Evaluating AI apps (evals)

Practise this with Sam

A real mock interview, out loud, with an honest scorecard. Free to start.

Start free