When One Agent Is Not Enough
Reaching for a (MAS) is usually vanity. Your single agent starts to struggle, and the reflex is to split it into a team of specialists with impressive names: a planner, a researcher, a critic, a writer. Five agents feels like more engineering than one. It is almost always the wrong move.
A team of agents is not a stronger agent. It is a distributed system, and distributed systems fail in ways a single process never does. Before you build one, you should be able to say out loud why one agent could not do the job. Most people cannot, because it could.
The Swarm You See in Demos Rarely Ships
That is the objection everyone reaches for: the impressive demos run on a swarm of agents talking to each other, so a serious system must too.
Look closer at what actually shipped. In most of those systems the swarm is a diagram in a talk, not the thing serving users. And where a real team of agents does run in production, it exists because the builders hit a wall with one agent and had the evidence to prove it. They did not start with five because five sounded more serious. They started with one, pushed it until it broke, and only then split the work.
An is not the goal. It is what you are left with after a single agent, given good tools and a solid architecture, genuinely cannot cope. That happens far less than the diagrams suggest.
What a Single Agent Can Actually Carry
One agent with a loop, a set of tools, and enough context handles more than people expect. It can research, plan, call ten different APIs, check its own work, and retry. The context window is large. The tool list can be long. A good single agent is a generalist that gets a lot done.
You reach the edge in a few honest cases. The task splits into parts that could run at the same time, and you are paying for the wait. Different parts need genuinely different system prompts, tools, or permissions that conflict inside one agent. The tool list has grown so long the model picks the wrong tool. Or one context window can no longer hold everything the job needs to know at once.
Those are real reasons. "It would look more sophisticated" is not one of them.
Supervisor and Workers
The most useful pattern is the plainest. One owns the goal and breaks it into pieces. Several each own one piece, with their own prompt and their own narrow tools. The supervisor hands out work, collects results, and decides what happens next. This is the , and it maps to how a team lead works: hold the goal, split the work, judge the output.
The workers do not talk to each other. They report up. That single rule kills most of the chaos, because every decision routes through one place instead of a free-for-all where any agent can interrupt any other.
Handoff, Delegation, and Negotiation
When work moves between agents, three things are happening, and it helps to name them.
is the supervisor assigning a task down to a worker: you, do this, here is what you need. is passing control sideways, one agent finishing and giving the conversation to another, the way a support bot hands you to billing. is agents settling who does what when it is not fixed in advance, and it is where multi-agent systems get expensive and unpredictable. is the polite word for all of it working.
Every handoff is a place where context gets dropped. The receiving agent only knows what the sender chose to pass along. Miss a detail in the handoff and the next agent confidently does the wrong thing, with no error to catch it. The more handoffs, the more of these silent gaps you carry.
The Plumbing That Connects Them
is the structure that decides who runs when and how results flow. A few shapes cover most of what you will build.
| Pattern | Shape | Use it when |
|---|---|---|
| Map-reduce | Fan the same task across many workers, then merge | The work splits into parallel chunks, like summarising 200 files |
| Hierarchical | A tree: supervisor over sub-supervisors over workers | The problem has natural layers of responsibility |
| Event-driven | Agents react to messages on a shared bus, no central boss | Loosely coupled parts that fire when something happens |
is the honest win: real parallel work, one merge at the end, easy to reason about. add layers of supervisors when one supervisor has too many workers to track. drop the central controller entirely and react to messages on a shared , which is flexible and, without care, impossible to debug because no single place knows the whole story.
Underneath all of them is : agents communicate by sending structured messages, not by sharing memory. And there is a fork worth knowing. fixes the steps in code, and the model only fills in each step. lets a model decide the steps at runtime. The first is predictable and boring. The second is flexible and hard to trust. Prefer the boring one until it genuinely cannot do the job.
The Tax Nobody Prices In
Here is what the diagrams leave out. Every agent you add is another model that can misread its instructions, another context window to keep in sync, another handoff that can drop a detail, another call you pay for and wait on. Five agents in a chain do not divide the failure rate by five. They stack it.
That is the coordination overhead, and it is a tax on every request, not a one-time setup cost. A single agent that is right 95% of the time is a good agent. Chain five of those with naive handoffs and your end-to-end success can fall below 80%, because they multiply. Nobody puts that number in the architecture diagram, and it is the number that decides whether the system works.
Earn It, Don't Reach for It
So the rule is simple. Build the single agent first. Give it good tools and real context. Push it until you have specific, written evidence of where it breaks, parts that must run in parallel, permissions that conflict, a tool list the model can no longer navigate. Only then add a second agent, and add it grudgingly.
Multi-agent is not the advanced move that proves you are serious. It is the architecture you fall back to when one agent has genuinely run out of room, and you pay a coordination tax for the privilege. The impressive systems did not start there. They earned their way to it, one exhausted agent at a time. Do the same, and most of the time you will find you never needed the swarm at all.
One agent or five, the moment it can act on the real world it can be attacked, tricked, or talked into doing damage. The next rung is about bounding what an agent is allowed to do at all.