Summary: Many agents working together: multi-agent systems

A multi-agent system is several specialized agents that coordinate, and the real question is fit, not ranking. Not “are multi-agent systems better than single agents?” but “does this task split into distinct enough jobs that specialists beat one well-designed generalist, and is that worth the coordination cost?” This lesson spends as much time on when not to split as on when to, because coordination is not free and many tasks are better served by one generalist. This summary is the scan-in-five-minutes version of the full lesson.

Core ideas

• A multi-agent system is several agents, each with its own role, instructions, and often its own focused tools, working on parts of a larger task. Usually a coordinator delegates pieces to specialists, or a pipeline hands off from one agent to the next. Each agent is still just a model in a loop with tools; what is new is that there are several and they must communicate.
• The advantages are real and come in three forms. Specialization (a focused agent with a small, well-described toolbox picks more reliably than an overloaded generalist, the tool-definition point at the system level), parallelism (independent sub-tasks run at once), and modularity (build, test, and replace each agent independently).
• The cost the brochures leave out is coordination. Communication overhead (context lost or distorted at every handoff), more failure points (N agents plus the connections between them), who-decides-what ambiguity (assigning work, resolving disagreement, knowing when done), and harder debugging plus more latency.
• The most common failure is a bad handoff, not a bad agent. Two agents that each understand the task perfectly can still fail at the seam between them. The system is only as reliable as its shakiest handoff.
• The real question is fit, not ranking. Multiple agents tend to win when the task genuinely splits into different specialties, when sub-tasks parallelize, or when one agent’s toolbox is so large it confuses itself. One generalist tends to win when the task is mostly sequential, when the pieces share too much context to hand off cleanly, or when it is small enough that any coordination is overhead.
• A practical path: start with one, split when you hit a wall. Build one generalist agent first and run it. Move to multiple agents only when you hit a concrete wall that splitting solves, not because the architecture diagram looks more impressive.
• Multi-agent is one shape of a compound system (models, retrievers, tools, and agents composed together). The same rule applies to all of them: each component buys capability and costs coordination, and good design spends that tradeoff on purpose.

What changes for you

Before this lesson, “multi-agent” sounded like the advanced way to build agents, the level you graduate to. Now you can see it for what it is: a specific tradeoff you take on purpose, not a destination. When you meet a multi-agent product, you can ask the sharper question: does this task actually split into distinct specialties, or is this one generalist’s job dressed up as a team? And you can name the bill the pitch usually hides, the coordination cost, so you can tell when several agents genuinely beat one well-designed generalist and when they just add seams to lose context across.