A small company has one person doing sales, accounts, support and hiring. It works — until it doesn't, and they hire specialists. Agents hit the same wall: one agent with twenty tools and a two-thousand-token instruction block starts making sloppy choices. The fix is the same — specialists with a coordinator. And so is the catch: coordination costs something, and a team of four is not automatically better than one good person.
Why split an agent at all
Two forces degrade a single overloaded agent. Tool confusion: with twenty tools, several look plausible for any given step, and the model picks wrongly more often. Instruction dilution: a prompt covering research, analysis, writing and reviewing gives each job a fraction of the model's attention — and costs those tokens on every single step.
Specialists fix both: a researcher gets search tools and a research prompt; a writer gets no tools and a style prompt. Each is focused, cheaper per step, and easier to test in isolation.
The supervisor pattern
A supervisor (orchestrator) receives the goal, splits it into subtasks, routes each to the right specialist, and assembles the results — exactly how a team lead works. It's the most common multi-agent topology because control stays centralized: one place decides who does what, which keeps the system debuggable.
In LangGraph terms this is just a graph where the supervisor node routes via conditional edges to worker subgraphs, sharing state (lesson 5). In CrewAI it's expressed as roles and tasks. Same idea, different syntax.
Other topologies worth naming
Sequential pipeline: agent A's output is agent B's input — research → write → edit. Simple, predictable, and honestly often a workflow with LLM steps rather than a true multi-agent system. Debate / critic: one agent proposes, another challenges, improving quality on judgment-heavy tasks at the cost of double the calls. Hierarchical: supervisors of supervisors for large decompositions — powerful, and the hardest to debug. Peer-to-peer: agents message each other freely; flexible, unpredictable, and rarely what you want in production.
Wait — my writer keeps inventing facts the researcher never found
This is the defining failure of multi-agent systems, and the diagnosis is almost always the same: a lossy hand-off. The researcher passed a prose summary; the writer received no sources, so when it needed a supporting detail it filled the gap from the model's own knowledge.
The fix is a data contract between agents, not better prompts inside them. The researcher must emit structured findings — each claim with its source and a supporting quote — and the writer's prompt must forbid claims that aren't in that structure. Then the reviewer checks each claim against the findings list rather than "reviewing" vaguely.
Multi-agent quality is decided by what travels between agents, not by how clever each one is. Structured, sourced hand-offs beat prose summaries every time.
The costs nobody mentions in the demo
Compounding errors. Mistakes propagate rather than average out: a researcher's slightly wrong summary becomes the writer's premise becomes the reviewer's baseline. Four agents at 90% each is not a 90% system.
Latency and cost multiply. Each agent runs its own loop with its own reasoning tokens. A four-agent system can easily be five times the cost and three times the wall-clock of one good agent.
Debugging spans trajectories. With one agent you read one trace. With four you read four, plus the hand-offs between them, and the bug is usually in a hand-off — the least-instrumented part.
When one agent wins
Ask one question: do the sub-tasks need genuinely different tools and instructions? Research (search tools) and writing (no tools, style rules) do. Order lookup, refunds and FAQs for the same customer don't — they share context, and splitting them fragments it while adding hand-off risk.
Multi-agent is a scaling tool, not a default architecture. Start with one well-scoped agent; split when a specific overload problem shows up in your evaluations, not because the diagram looks impressive.
Selection-round radar: "Explain multi-agent systems" wants the supervisor pattern plus one alternative topology. The follow-up — "when would you use one agent instead?" — is where marks are won: different tools and instructions justify splitting; shared context and simple scope don't. Mention compounding errors and cost, and you've covered the whole question.
Agent-to-agent protocols
Everything above assumes agents you built, inside one system. The emerging question is how independently built agents — different teams, different companies — discover each other's capabilities and exchange tasks. That's what A2A-style protocols aim to standardize.
It's the same instinct as MCP, one level up: MCP standardizes agent↔tool connections; A2A standardizes agent↔agent ones. Both exist to replace N×M custom integrations with one interface. At placement level, knowing that sentence and the distinction is enough (the MCP course covers its side properly).
Common mistakes
- Splitting by topic rather than by tools-and-instructions.
- Prose hand-offs, so downstream agents invent the details they weren't given.
- Assuming more agents means higher quality — errors compound.
- No instrumentation on hand-offs, where most bugs actually live.
- Building a hierarchy before proving a single agent is insufficient.
- Calling a fixed research→write→edit pipeline "multi-agent" when it's a workflow.
Quick recap
| Concept | One-liner |
|---|---|
| Why split | tool confusion and instruction dilution in one overloaded agent |
| Supervisor | coordinator splits the goal, routes to specialists, assembles results |
| Other topologies | sequential, debate/critic, hierarchical, peer-to-peer |
| Hand-offs | structured, sourced data contracts — never prose summaries |
| Costs | compounding errors, multiplied latency and cost, harder debugging |
| Split when | sub-tasks need different tools AND different instructions |
| A2A | standardizing agent↔agent tasks, as MCP does for agent↔tools |
Practice Zone — PYQs from real selection rounds
Six MCQs and two tasks — decide split-or-not for four systems, then fix a hand-off that's producing invented claims.
The supervisor (orchestrator) pattern means:
Asked in
Why split one agent into several specialists?
Asked in
What's the biggest practical risk of multi-agent systems?
Asked in
How do agents in a multi-agent system typically share information?
Asked in
Which task genuinely benefits from a multi-agent design?
Asked in
What is A2A (agent-to-agent) communication meant to standardize?
Asked in
Hands-on tasks:
For each system, say whether you'd use one agent or several, and why: 1) A coding assistant that fixes failing tests. 2) A company research report generator. 3) A customer support agent handling orders, refunds and FAQs. 4) A pipeline turning meeting recordings into minutes and action items.
Asked in
In a research→write→review system, the writer keeps producing unsupported claims. Diagnose the hand-off problem and fix it.
Asked in
FAQ
Can different agents use different models?
Yes, and it's a common cost optimization: a strong model for the supervisor and any reasoning-heavy specialist, cheaper models for extraction, formatting or summarizing. Just measure — a weak worker can quietly poison the whole chain.
How do agents avoid duplicating work?
Through shared state and clear task boundaries: the supervisor assigns disjoint subtasks and records what's done, so workers don't re-search the same thing. Free-form peer-to-peer chatter is exactly where duplication and loops appear.
Is CrewAI multi-agent and LangGraph single-agent?
No — both support multi-agent. CrewAI's abstraction is role-based crews, which makes teams quick to express; LangGraph models everything as graphs, giving finer control over routing and state (lesson 8).
Next lesson: choosing between the frameworks — Lesson 8: LangGraph vs CrewAI vs AutoGen →