A single agent can carry a surprising amount of work before it buckles, and the instinct when it does is to split it into many — but a crowd of agents is not automatically smarter than one. The difference between a multi-agent system that compounds capability and one that compounds confusion lies almost entirely in how the work is divided and how the pieces talk to each other.
The single agent and its limits
A single agent — one model, running one loop, reading from one context window, reaching for one set of tools — is the right shape for the overwhelming majority of problems, and it is worth establishing that plainly before discussing how to go beyond it, because the most common error in this whole area is reaching for a crowd of agents where one would have served. A single agent is easier to reason about, cheaper to run, simpler to trace when it misbehaves, and far more predictable in what it will do next, and every one of those virtues is something you begin to surrender the moment you introduce a second agent. The bar for adding agents should therefore be high, cleared only when a single agent genuinely cannot carry the work, not merely when a diagram with several boxes looks more impressive than a diagram with one.
Still, a single agent does run into limits, and they are real rather than imagined. Its context window is finite, so a task that requires holding more material than fits will degrade as the window fills with history and the useful signal thins toward the bottom. Its attention is singular, so a job that demands two genuinely different modes of thought — the skeptical auditor and the fluent generator, say — forces one model to oscillate between them and tends to do neither as well as a mind dedicated to each. And its execution is sequential, so work that could in principle proceed in parallel instead unfolds one step after another, paying in wall-clock time for a serialism the problem never actually required.
The honest way to frame the move to many agents is that you make it not because many is better in the abstract but because one has hit a wall you can name and point to. When you cannot say which specific limit of the single agent you are escaping, you are almost certainly adding complexity you will regret. When you can — the context will not fit, the modes of thinking genuinely conflict, the subtasks are truly independent and the latency matters — then a second agent is not indulgence but engineering, and the rest of this article is about doing it deliberately rather than by reflex.
What a multi-agent system actually is
Strip away the mystique and a multi-agent system is just several model-driven loops that pass work and results between one another instead of one loop doing everything. Each agent is the same basic machine you already know — a model, a prompt that gives it a role, a set of tools, and a loop in which it reasons and acts — and what makes the system multi-agent is that these machines are wired together so that the output of one becomes the input of another, or so that one agent can summon another to handle a piece of the job. There is no new primitive here, only a new topology, and understanding the topology is most of understanding the system.
It helps to see that the agents are not peers floating in a shared mind; they are separate processes with separate contexts, and the only thing they share is whatever you explicitly arrange to pass between them. One agent cannot see another's reasoning unless that reasoning is handed over in a message, and it cannot use another's findings unless those findings are serialized and delivered. This separateness is the whole point — it is what lets each agent keep a clean, focused context — but it is also the source of every coordination problem the system will have, because anything two agents need to agree on has to travel explicitly across the gap between them.
The agents also do not have to be different models or even different prompts. A multi-agent system can be many instances of the same model running the same role over different slices of a problem, or it can be a heterogeneous cast of specialists each tuned for a distinct job. The architecture is defined by the wiring and the division of labor, not by the diversity of the participants, and some of the most effective multi-agent designs are nothing more than the same agent invoked many times in parallel over independent inputs, with a final step that gathers what they each found.
A multi-agent system introduces no new primitive — only a new topology. Each agent is the same model-and-loop you already know; what is new is the wiring between them, and the wiring is where the leverage and the trouble both live.
Figure 1. A single agent is the default; a multi-agent system trades clean isolated contexts and parallelism for coordination cost.
The orchestrator and the workers
The most common and most useful shape for a multi-agent system is the orchestrator-worker pattern, in which one agent owns the overall goal and decomposes it into pieces, while other agents take those pieces and carry them out. The orchestrator does not do the detailed work itself; its job is to understand the request, break it into subtasks, decide which worker should handle each, dispatch them, and then assemble the returns into a coherent whole. The workers do not see the big picture; each receives a scoped instruction, does the focused thing it was asked, and reports back. This division mirrors how a competent manager and a team of specialists actually function, and it is popular precisely because it maps onto an intuition everyone already has.
What makes this pattern powerful is that it lets each role keep a context shaped for its job. The orchestrator's context holds the goal, the plan, and the summarized results, uncluttered by the voluminous detail each worker waded through to produce its answer. Each worker's context holds only the narrow slice it needs, undistracted by the goals and intermediate states of the others. Neither has to hold everything, and that is exactly the relief a single overloaded agent could not give itself. The orchestrator stays strategic because it never drowns in detail; the workers stay sharp because they never have to hold the whole.
The subtlety is that the orchestrator's job — decomposition and assembly — is itself hard, and a multi-agent system is only as good as its orchestrator's judgment about how to cut the work and how to recombine it. A poor decomposition hands workers tasks that overlap, conflict, or leave gaps; a poor assembly takes good worker outputs and stitches them into an incoherent result. Much of the craft of building these systems is really the craft of making the orchestrator decompose well and synthesize faithfully, and it is worth investing the most design attention precisely there, because that is the agent whose mistakes propagate to everything downstream.
Figure 2. The orchestrator decomposes the goal into scoped subtasks and synthesizes the workers' clean summaries into a result.
When splitting helps, and when it doesn't
Splitting one agent into many helps in a small number of recognizable situations, and it is worth holding them clearly in mind so you can tell a real case from a fashionable one. The first is when the work decomposes into genuinely independent subtasks that can run at the same time, where parallelism turns a long sequential slog into a quick fan-out and gather. The second is when subtasks demand genuinely different expertise or modes of thinking, such that a specialist agent with a focused prompt and a narrow toolset will outperform a generalist juggling everything. The third is when the total context required exceeds what one window can hold cleanly, so distributing the material across several focused contexts preserves the signal that a single crowded context would lose.
Splitting does not help — and usually hurts — when the subtasks are tightly interdependent, each needing the others' partial results to proceed, because then the agents spend their effort passing state back and forth and you have paid coordination overhead to recreate, badly, what one agent's continuous context gave you for free. It does not help when the task is small enough for one agent to hold comfortably, where the extra agents add latency, cost, and failure surface in exchange for nothing. And it does not help when the decomposition is artificial, imposed because multi-agent sounds sophisticated rather than because the problem actually has independent seams, which produces a system that is harder to build, harder to debug, and no more capable than the single agent it replaced.
The test that cuts through the fashion is to ask whether the parts of the work are more independent than they are entangled. Where the seams are real — where you can hand someone a piece and they can do it without constantly checking in — multiple agents follow the grain of the problem and the system feels natural. Where the seams are forced — where every piece needs every other piece in flight — you are fighting the problem's structure, and the coordination cost will eat any benefit you imagined. Match the number of agents to the genuine independence in the work, and resist the pull to multiply them for the elegance of the diagram.
Decomposition: cutting the work at the joints
If the orchestrator's central act is decomposition, then learning to cut a task at its natural joints is the central skill, and it is more subtle than slicing a problem into equal parts. A good decomposition produces subtasks that are independent enough to run without constant cross-talk, scoped tightly enough that a worker can hold each in a clean context, and aligned with real boundaries in the work rather than arbitrary ones. A bad decomposition produces subtasks that look separate but are secretly coupled, so that workers reach conclusions that contradict each other or duplicate each other's effort, and the orchestrator inherits a pile of pieces that do not fit together.
The most reliable guide is to decompose along the lines the work already has rather than lines you impose for neatness. Research that spans several distinct questions cuts cleanly into one worker per question; a document with several independent sections cuts cleanly along the sections; a dataset that partitions into non-overlapping shards cuts cleanly along the shards. In each case the seam is in the problem, and cutting there gives you pieces that truly stand alone. When you find yourself slicing across a seam — splitting one tightly-bound reasoning chain across two agents so that each holds half a thought — that is the signal you are decomposing against the grain, and the result will be brittle.
It also pays to decompose to the right depth and no further, because decomposition is recursive and it is easy to over-fragment. Each level of splitting adds agents, messages, and assembly steps, and past a point the overhead of coordinating tiny pieces outweighs any benefit of their independence. The judgment is to split until each piece is something a single focused agent can do well in one clean context, and then to stop, resisting the urge to split further just because you can. A system of a few well-sized pieces beats a system of many slivers, for the same reason a few well-chosen tools beat a hundred near-duplicates.
Communication between agents
Because agents are separate processes with separate contexts, everything they need to share has to be communicated explicitly, and the design of that communication is where multi-agent systems quietly succeed or fail. When an orchestrator hands a worker a subtask, the instruction must carry enough context for the worker to do the job without seeing the whole — the goal of the piece, the constraints it must respect, the format the answer should take — and no more, because every extra token of context the worker does not need is a distraction from the focus that made the split worthwhile. The art is to give each agent precisely the slice of the world it needs and to draw the boundary of that slice deliberately.
The return journey is just as consequential. When a worker reports back, what it returns goes into the orchestrator's context and becomes material the orchestrator reasons over, which means a worker that dumps its entire working transcript back up the chain reintroduces exactly the clutter the decomposition was meant to avoid. A worker should return a clean, summarized result — the findings, not the slog of producing them — shaped so the orchestrator can act on it without re-deriving it. The discipline that makes orchestrator-worker systems scale is that each layer summarizes for the layer above, so the detail stays where it was needed and only the conclusions travel upward.
There is a real tension to manage here, because summarization loses information and sometimes the orchestrator needs a detail the worker discarded. Designing the communication well means deciding in advance what each agent owes the others — what must always be passed up, what can be summarized, what can be dropped — and making those contracts explicit rather than hoping each agent guesses right. When the contracts are clear, the system composes; each agent knows what it will receive and what it must return, and the whole behaves predictably. When they are vague, agents pass too much or too little, and the system's behavior becomes a function of accidents in how each one happened to phrase its handoff.
Each layer should summarize for the layer above it. The detail stays where it was needed; only the conclusions travel upward. That single discipline is what lets an orchestrator-worker system scale instead of drowning in its own transcripts.
Context isolation is the real motivation
It is tempting to think the point of multiple agents is parallelism or specialization, and those matter, but the deepest and most reliable reason to reach for many agents is context isolation — giving each piece of the work its own clean window so that no single context has to hold everything at once. A single agent tackling a sprawling task accumulates a long history of reasoning, tool calls, and intermediate results, and as that history grows it crowds the window, dilutes the model's attention, and degrades the quality of every subsequent step. Splitting the work across agents lets each one start fresh, reason in a context containing only what its piece requires, and finish before its window ever gets crowded.
This reframing explains why some multi-agent designs work so well even when they are not really about parallelism. A research task that sends each sub-question to its own agent is not primarily saving time; it is ensuring that the deep dive into question one does not pollute the context of question two, so each investigation stays sharp. The orchestrator then receives clean summaries rather than the union of every dive, and reasons over a tidy synthesis rather than a swamp. The benefit is fundamentally about keeping contexts clean, and once you see it that way you start reaching for extra agents specifically when a single context would otherwise get muddy.
Seen through this lens, the question of when to split has a sharp answer: split when keeping the work in one context would force that context to hold more than it can cleanly carry, and the pieces are independent enough that separating them does not require constant cross-context coordination. The agents are, in effect, a way of buying many clean windows where you only had one, and spending the coordination cost to keep each window focused. When that trade is worth it — when the cleanliness bought exceeds the coordination paid — multiple agents are the right call, and when it is not, a single agent with disciplined context management will serve you better.
Roles, specialization, and prompts
Each agent in a multi-agent system is defined first by its role, and the role lives in its prompt, so writing those role prompts well is as important as wiring the agents together. A worker told it is a careful fact-checker whose only job is to verify claims against sources will behave very differently from one told it is a fast drafter whose job is to produce a first pass quickly, even if both run the same model, and that difference is exactly what specialization buys you. The role prompt sets the agent's purpose, its standards, the tools it should use, and the boundaries it should respect, and a sharp role prompt produces an agent that does one thing with conviction rather than everything with hesitation.
Specialization pays off most when the roles genuinely pull in different directions, because that is precisely the conflict a single agent handles poorly. A generator that is rewarded for fluency and a critic that is rewarded for skepticism want opposite things, and asking one agent to be both at once tends to blunt each instinct against the other. Splitting them lets the generator generate freely and the critic critique sharply, with the tension between them resolved by the orchestrator rather than muddled inside one head. The same logic favors separating a planner from an executor, a researcher from a writer, a proposer from an approver — wherever the modes of thought genuinely conflict, giving each its own agent lets each be itself.
There is a discipline of not over-specializing, though, because a cast of too many narrow specialists becomes its own coordination burden, and the orchestrator spends its effort routing among roles that could have been combined. The right number of roles is the smallest set that captures the genuinely distinct modes the work requires, and a role earns its place only when it does something the others cannot do well. As with tools, a focused set of a few clear roles beats a sprawling cast of overlapping ones, because the orchestrator can route among a small set confidently and flounders among a large one.
The patterns worth knowing
A handful of multi-agent patterns recur across applications, and knowing them gives you a vocabulary for matching a structure to a problem rather than inventing one each time. The orchestrator-worker pattern, already described, is the workhorse: a coordinator decomposes and dispatches, workers execute and return, the coordinator synthesizes. It fits any task that decomposes into scoped subtasks, and it is where most teams should start. Its strength is the clean division of strategy from execution; its weakness is its reliance on the orchestrator's judgment, which becomes the single point through which all quality flows.
The pipeline pattern arranges agents in a sequence where each transforms the output of the last, like a factory line — one agent drafts, the next edits, the next formats, the next checks. It fits work that has natural stages that must happen in order, and its appeal is simplicity and predictability, since the flow is fixed and easy to trace. Its limit is that it is strictly sequential and only as fast as the sum of its stages, and a weakness anywhere in the line passes its flaws downstream, so each stage must be robust to the imperfect output of the one before it.
The debate or critic pattern pairs a producer with an adversary, one generating and the other challenging, iterating until the result survives scrutiny. It fits tasks where quality benefits from an explicit skeptic — reasoning that should be checked, drafts that should be challenged — and it works because the critic's job is structurally opposed to the producer's, surfacing flaws a single agent invested in its own output would gloss over. The blackboard pattern, by contrast, lets several agents read and write a shared workspace, contributing as they each have something to add, suited to open-ended problems with no fixed decomposition, at the cost of being harder to control and to reason about. Most real systems combine these rather than using any one in isolation, and the skill is choosing the combination that matches the shape of the work.
Figure 3. Three recurring shapes — pipeline, debate, and blackboard — that real systems mix rather than use in isolation.
Parallelism and the cost equation
One of the most concrete payoffs of multiple agents is parallelism — running independent subtasks at the same time rather than one after another — and when the work genuinely fans out, the latency win is large and immediate. A task that would take a single agent ten sequential steps can sometimes be done in the time of one step if those steps are independent and dispatched to ten workers at once, and for an interactive system where a user is waiting, that difference is the difference between usable and not. Where independence is real, parallelism is the clearest reason to go multi-agent, and it is worth structuring the decomposition specifically to expose it.
But parallelism changes the cost equation in a way that is easy to underestimate, because running many agents at once means paying for many contexts at once, and each of those contexts carries its own copy of whatever shared setup it needs. Ten workers each reading a long brief pay ten times for that brief, and the orchestrator that dispatched them and the synthesis that gathers them add their own cost on top. A multi-agent system can easily cost several times what a single agent would for the same task, and the latency it saves is bought with tokens it spends, so the trade is worth making only when the speed genuinely matters or the quality genuinely improves.
The way to keep the cost equation honest is to count the total work, not just the wall-clock time, and to add agents only where the parallel speedup or the quality gain justifies the multiplied spend. For a batch job that no one is waiting on, sequential single-agent execution is often the economical choice even when parallelism is possible, because there is no latency to save and every extra agent is pure added cost. For an interactive task where a person waits, paying more tokens to return an answer faster is frequently the right call. Knowing which regime you are in tells you whether parallelism is a bargain or an extravagance.
Shared state and memory across agents
Agents with separate contexts still often need to agree about shared facts, and how they reach that agreement is a design problem with no free answer. The simplest approach passes everything an agent needs through its instructions, so each one is self-contained and there is no shared store to keep consistent, which is clean but limits how much agents can build on each other and forces the same context to be passed repeatedly. The alternative gives agents access to a shared memory — a store they can read and write — so that what one learns another can use, which is powerful but reintroduces all the classic difficulties of shared mutable state: staleness, conflicts, and the question of who can trust what they read.
When agents do share a store, the discipline that keeps it sane is to be explicit about what lives there and who may change it, because a shared memory that any agent can overwrite at any time becomes a source of subtle, hard-to-trace bugs as one agent's write surprises another's read. Treating the shared store as a deliberate, structured interface rather than a free-for-all — clear about what each entry means, when it is valid, and which agent owns it — is what keeps the convenience of shared state from curdling into the chaos of uncoordinated writes. The same care you would give a database shared by several services applies to a memory shared by several agents.
For many systems the right answer is a hybrid: keep most context local to each agent, passed through scoped instructions, and reserve the shared store for the small set of facts that genuinely must be common across the system. This keeps the bulk of the work isolated and clean while still letting agents coordinate on the few things they truly must agree about, and it avoids both the rigidity of passing everything explicitly and the entanglement of sharing everything globally. As ever, the principle is to share the minimum that the work requires and to keep the rest local, because every shared fact is a coordination cost and every local one is free.
Error handling when the crowd misbehaves
A single agent that errs fails in one place you can find; a multi-agent system can fail in many places at once and in ways that interact, so its error handling must be designed rather than assumed. A worker can fail outright, returning nothing or an error, and the orchestrator must decide whether to retry it, route around it, or give up and report a partial result. A worker can also fail quietly, returning a confident but wrong answer that the orchestrator, lacking the worker's context, has no easy way to check, and that silent failure can poison the synthesis without ever announcing itself. Both kinds have to be anticipated, because in a system of several agents at least one of them going wrong is not the exception but the expectation.
The orchestrator's role in error handling is to treat worker outputs as claims to be assessed rather than truths to be trusted, especially where the cost of a wrong synthesis is high. Building in a check — a verification step, a sanity test, a cross-comparison of workers that should agree — gives the system a chance to catch a worker's silent failure before it propagates. Designing workers to report their own uncertainty, to say when they could not complete the task or were unsure of a result, gives the orchestrator the signal it needs to weigh their returns rather than blindly merging them. An orchestrator that cannot tell a confident worker from a correct one will average good and bad returns into mush.
There is also the failure mode of the system as a whole going off the rails — agents calling each other in loops, an orchestrator dispatching endlessly, a chain of handoffs that never converges — and guarding against it requires limits that no single agent's good behavior can guarantee. Caps on how many agents can be spawned, how deep the orchestration can recurse, and how long the whole system may run are the backstops that keep a misbehaving multi-agent system from consuming unbounded resources before anyone notices. The more autonomy you grant the agents to summon and direct one another, the more important these hard limits become, because the system's emergent behavior can surprise you in ways no individual agent's behavior would predict.
The coordination tax
Every benefit of multiple agents is bought with coordination, and coordination is not free — it is a tax levied on every handoff, every summary, every synthesis, and every message that crosses the gap between contexts. The tax shows up as tokens spent passing information that a single agent would have held for nothing, as latency added by the round-trips of dispatch and return, as the risk that something is lost or distorted in each translation between agents, and as the sheer complexity of a system with many moving parts instead of one. None of this is a reason to avoid multiple agents, but all of it is a reason to count the cost honestly and to add agents only when what they buy exceeds what they tax.
The tax grows with the number of agents and the chattiness of their communication, so the systems that stay efficient are the ones that minimize necessary communication rather than maximize agent count. Fewer, better-scoped agents that each do a substantial piece of work and hand back a clean summary pay less coordination tax than many tiny agents that each do a sliver and constantly check in. The design instinct that keeps the tax low is the same one that keeps a single agent's context clean: pass the minimum, summarize aggressively, and draw the boundaries between agents where the communication across them will be lightest.
It is worth stating the uncomfortable truth plainly: a multi-agent system is almost always more complex, more expensive, and harder to debug than the single agent it replaces, and it earns its keep only by doing something the single agent genuinely could not. When you find a multi-agent system performing no better than a single agent would have, the coordination tax has eaten the entire benefit, and the right move is to collapse it back into one agent. The goal is never to have many agents; the goal is to do the work well, and many agents are justified only when they are the way to do it well.
The goal is never to have many agents. The goal is to do the work well. Many agents are justified only when they are the way to do it well — and when they are not, the coordination tax has quietly eaten the entire benefit.
Figure 4. Many agents earn their keep only when what they buy exceeds the coordination they cost.
Evaluating a multi-agent system
A multi-agent system is harder to evaluate than a single agent because there are more places for it to go wrong and the failures interact, so the evaluation has to look at both the whole and the parts. At the level of the whole, the question is whether the system produces good final results across a representative range of real tasks, run repeatedly because the system's behavior has variance and a structure that works most of the time is not yet reliable. At the level of the parts, the question is which agent is responsible when the whole fails — whether the orchestrator decomposed badly, a worker executed poorly, or the synthesis stitched good pieces into a bad result — because the fix differs entirely depending on which it was.
Separating these levels is what turns a vague sense that the system underperforms into an actionable diagnosis. If the orchestrator is decomposing the task into the wrong pieces, no amount of worker quality will rescue the result, and the fix is in the orchestrator's prompt and plan. If the workers are each doing their pieces well but the synthesis is losing or distorting their contributions, the fix is in how results are summarized and combined. If individual workers are failing at their scoped tasks, the fix is in their prompts, tools, and the clarity of the instructions they receive. An evaluation that only reports whether the final answer was good leaves you guessing which of these broke, and guessing is expensive.
The practice that compounds over time is to build a suite of representative end-to-end tasks, score the system on them as a whole, and instrument each stage so that when the whole fails you can see which part did, then add every observed failure to the suite as a permanent test. When you later change a decomposition strategy, a worker prompt, or a synthesis step, you rerun the suite and learn whether the change helped without quietly breaking something else. This turns the tuning of a complex system from a series of hopeful adjustments into a measured practice, and it is the only thing that keeps a multi-agent system's reliability climbing rather than wobbling with every edit to one of its many parts.
Security and the expanded blast radius
Adding agents expands the surface that has to be secured, because each agent has its own tools, its own access, and its own exposure to whatever untrusted content it reads, and the system's blast radius is the union of all of them. A single agent's security you can reason about by looking at its tools; a multi-agent system's security requires reasoning about every agent's tools and, harder, about how an attack on one agent can propagate to the others through the messages they pass. An attacker who hijacks one agent through poisoned content it reads may be able to steer what that agent reports to the orchestrator, and through it influence the whole system, so the trust between agents is itself part of the attack surface.
The principle of least privilege applies with extra force here, because giving every agent broad capability multiplies the broad capability an attacker might capture, while scoping each agent tightly to exactly the tools its role requires contains the damage any one compromised agent can do. A worker that only needs to read should not be able to write; an agent that only summarizes should not have the tools to act on the world. The same discipline that limits a single agent's blast radius limits each agent's in a system, and because there are more of them, the discipline matters more, not less.
The communication between agents deserves the same suspicion as any other channel carrying potentially untrusted content, because a worker's output, which the orchestrator reads and acts on, can carry an injected instruction just as a web page can. An orchestrator that treats worker returns as commands rather than data can be manipulated by an attacker who compromised a worker, so the boundary between agents should be a place where outputs are treated as claims to be assessed, not instructions to be followed. The whole system holds only if each agent treats what it receives — whether from the outside world or from a sibling agent — as data to be judged rather than direction to be obeyed.
Observability across many agents
A single agent's behavior is hard enough to see; a multi-agent system's behavior is invisible unless you build the instrumentation to watch it, and without that visibility you cannot tell a healthy system from a sick one, let alone fix it. Every agent's inputs, outputs, tool calls, latencies, and costs are evidence, and so is the structure of who called whom and what was passed between them, because a multi-agent system's failures often live not in any one agent but in the handoffs between them. Capturing the full trace — the tree of agents, the messages along its edges, the cost and time at each node — is what lets you find the worker that always fails, the handoff that always loses information, the orchestration that recurses too deep.
The patterns that emerge from watching are where the real improvements come from, because they reveal the gap between the system you designed and the system you actually built. An orchestrator you expected to dispatch three workers might be spawning thirty; a worker you thought was central might go unused while another carries everything; a summarization step you assumed was lossless might be dropping exactly the detail the synthesis needed. These are not visible from the final output alone, and they are precisely the things that determine whether the system is efficient or wasteful, reliable or flaky, and following them is how you tune a multi-agent system toward how it really behaves rather than how you imagined it would.
The characteristic failure modes
Multi-agent systems fail in recognizable ways, and knowing the catalogue is most of the work of defending against it, because each failure has a known cause and a known countermeasure. The point is not to make failure impossible but to make the common failures diagnosable, recoverable, and rare.
The bad decomposition: the orchestrator cuts the task into pieces that overlap, conflict, or leave gaps, so even perfect workers cannot produce a coherent whole. Guard by investing in the orchestrator's planning and by cutting along the work's real seams rather than imposed ones.
The lossy synthesis: workers each return good results but the orchestrator combines them badly, dropping or distorting contributions. Guard by designing the summarize-and-combine step deliberately and checking that the synthesis preserves what the workers found.
The silent worker error: a worker returns a confident but wrong answer the orchestrator cannot easily check, poisoning the result. Guard by treating worker outputs as claims to assess, having workers report uncertainty, and cross-checking where stakes are high.
The coordination overrun: the agents spend more effort passing state than doing work, because the task was too interdependent to split. Guard by splitting only along genuine seams and collapsing back to one agent when the pieces will not stay independent.
The runaway spawn: an orchestrator dispatches endlessly or agents call each other in loops, consuming unbounded resources. Guard with hard caps on agent count, recursion depth, and total runtime that no single agent's good behavior can be trusted to enforce.
The propagated hijack: an attacker compromises one agent through untrusted content and steers the system through the messages it passes. Guard by least-privileging each agent and treating inter-agent messages as data to assess, not commands to obey.
The phantom benefit: the system performs no better than a single agent would have, but costs more and is harder to debug. Guard by measuring against a single-agent baseline and collapsing the system when the multi-agent version does not earn its complexity.
When not to use multiple agents
The most valuable judgment in this whole area is knowing when multiple agents are the wrong answer, because they add latency, cost, coordination, and failure surface, and paying all of that for a capability a single agent already had is the most common and most avoidable mistake. If a single agent can hold the task in one clean context and do it reliably, splitting it buys nothing but overhead and the satisfaction of a more elaborate diagram. If the subtasks are tightly interdependent, multiple agents recreate, expensively and badly, the continuous context a single agent had for free. If the task is small, the orchestration overhead dwarfs the work. In all these cases the single agent is not a limitation to overcome but the right tool, and reaching past it is a regression dressed as sophistication.
The honest framing is that multiple agents earn their complexity only when the work has genuine independence to exploit, genuine conflicts of mode to separate, or genuine context that will not fit in one window — and when none of those holds, a single well-designed agent with disciplined context management is the better system. Before building a multi-agent architecture, it is worth trying hard to make a single agent work, because that effort either succeeds, saving you enormous complexity, or fails in a specific way that tells you exactly which limit you are escaping and therefore exactly how the agents should be split. Starting from the single agent and splitting only under named pressure produces better systems than starting from a crowd and hoping it coheres.
Where this is going
The frontier of multi-agent systems is moving toward agents that coordinate more fluidly and with less hand-wiring, as shared protocols let agents discover and call one another across boundaries and as models grow better at deciding for themselves when to summon help and how to divide work. The orchestration that once had to be carefully scripted is increasingly something models can do dynamically, planning a decomposition on the fly and adjusting it as results come in, and the line between a single agent that calls sub-agents as tools and a multi-agent system proper keeps blurring as that capability matures. The patterns that took deliberate construction not long ago come together with less effort as the models carry more of the coordination themselves.
But the fundamentals hold regardless of the frontier. More agents still cost more, coordinate at a price, and fail in more places, and they still earn their keep only by doing something a single agent could not. A good multi-agent system still needs a decomposition cut along real seams, communication that passes the minimum and summarizes the rest, roles scoped to genuinely distinct work, errors that the orchestrator can catch and recover from, limits that contain runaway behavior, security that least-privileges each agent, and observability that makes the whole tree visible. None of these is made obsolete by better models; they are the craft that turns raw capability into a system that works.
The shape of the discipline
So if there is one thing to carry away, let it be that multiplying agents is not a goal but a trade — clean isolated contexts and parallel execution bought with coordination cost, added complexity, and a wider failure surface — and the discipline is making that trade only when it pays. The single agent is the default, not the fallback, and the move to many should follow a named limit rather than a fashionable instinct. When you do split, split along the work's real seams, give each agent a clean context and a sharp role, pass the minimum between them and summarize the rest, treat every handoff as a place where things can be lost or attacked, and measure the whole against the single agent it replaced so you can tell whether the complexity earned its place.
Build the system that way and the agents compound — each one doing a focused piece well, the orchestrator weaving their clean returns into a coherent whole, the structure following the grain of the work rather than fighting it. Build it carelessly and the agents merely multiply the confusion, each adding cost and failure while the coordination tax devours the benefit. The difference is not in the number of agents or the cleverness of the diagram; it is in whether the division of labor matches the real structure of the problem and whether the communication between the pieces is disciplined enough to keep what matters and drop what does not. Get that right, and a crowd of agents becomes something a single mind could not be. Get it wrong, and it becomes an expensive way to do what one agent would have done better alone.