A multi-agent system is several agents that communicate toward a shared goal. As the survey frames it, this is not just many prompts: each agent has a role (a profile), a way of reasoning, its own memory, rules, and tools it can call. What you design is as much the environment and communication structure between agents as the agents themselves.

In practice you meet three core arrangements: a supervisor-worker structure (a manager agent splits the task across workers and collects results), specialist agents (each owning a phase or domain), and debate (several agents argue opposing views and a judge decides). This post takes each in turn.

This is the most common pattern. A supervisor takes the incoming task, splits it into subtasks, sends each piece to a suitable worker, then collects and merges the results. AutoGen formalizes this as "conversation programming": you define the agents and their roles, then program the conversation flow between them. At its simplest that's an assistant and a user-proxy; at its most complex, a group chat steered by a GroupChatManager.

The pattern works when the task decomposes into pieces that can run in parallel: gathering data from three sources, editing three independent files, answering three separately verifiable sub-questions. But note: AutoGen's own paper leaves it as an open question which agent topology and conversation pattern is optimal and most cost-effective for a given task. A multi-agent structure is not automatically better output; it is mostly orchestration infrastructure, not a quality guarantee.

The second pattern splits the task by role: each agent is the expert of a phase or domain. MetaGPT applies this to software; roles like Product Manager, Architect, and Engineer mimic human standard operating procedures (SOPs), and each role hands a structured intermediate output (an artifact) to the next. ChatDev similarly assigns design, coding, code review, and testing phases to separate agents.

The key idea: a specialist agent is valuable when it produces a concrete artifact and hands it off cleanly to the next role. MetaGPT argues that naive chains of agents amplify "cascading hallucinations" (an early agent's error spreads and grows downstream); its fix is required output formats instead of loose role-play chatter. The converse holds too: without guardrails, specialists drift. CAMEL reports exactly these pathologies: role flipping, repeating instructions, flaky replies, and infinite message loops.

The third pattern is different: agents don't divide labour, they oppose each other. Multi-Agent Debate starts from the fact that a single model, once confident in its answer, can't correct itself; the paper calls this "Degeneration-of-Thought." The fix is to introduce genuine external disagreement: two (or more) debaters argue opposing views and a judge watches the rounds and decides.

This helps on tasks where the answer is non-obvious and rote reasoning leads astray. The paper reports debate beating baselines on counter-intuitive arithmetic and commonsense translation, including a case where GPT-3.5-Turbo with MAD surpasses GPT-4 on the Common MT dataset. But two caveats: more debate rounds are not automatically better, so the system needs adaptive stopping; and the judge can be biased, especially when the agents and the judge are different models, raising judge-bias risk.

A supervisor-worker structure need not stop at one level: a worker can delegate its own subtasks to other agents. On paper this looks clean; in practice it blows up the coordination cost. Each level of delegation adds new model calls, new context to pass along, and new handoff points.

In the tree below, watch how the total number of agents (and therefore model calls) multiplies as delegation depth grows. The survey calls this "efficiency explosion": as scale grows, agents repeatedly call the model for memory extraction, planning, action, and communication. Layer on the "accumulative effect": because each round depends on the previous output, an early error grows along the chain. A deep delegation tree is both more expensive and more fragile.

The hidden bill of a multi-agent system is communication. The survey says plainly that fully-connected natural-language communication (every agent talking to every agent) is flexible but operationally expensive, and flags communication cost and runtime as evaluation concerns. In a single agent, "cost" is mostly the tokens of one loop; in a multi-agent system every message, handoff, and turn is a separate model call.

The chart below shows a simple fact: as agent count grows, the number of communication channels grows not linearly but close to quadratically. Three agents means three channels; six agents means fifteen. Each channel is a potential message, a misunderstanding, a synchronization point. This is exactly where "more agents = better" breaks: the marginal cost explodes before the marginal benefit arrives.

"Why Do Multi-Agent LLM Systems Fail?" studies exactly this, empirically. It hand-annotates 1,642 traces and groups 14 failure modes into three buckets: system design issues, inter-agent misalignment, and task verification gaps. Across the seven open-source multi-agent frameworks studied, reported failure rates run from 41% to 86.7%. These are not rare accidents; they are systematic breaking points.

The most frequent failures will feel familiar: step repetition, unclear termination (the system can't tell when to stop), disobeying the assigned role or task, reasoning-action mismatch, ignoring the given input, and incomplete or incorrect verification. What matters is that the paper's recommended fix is not "add more agents": clear role and task definitions, deliberate conversation-pattern design, modular agents, standardized communication protocols, and domain-appropriate multi-level verification. Improving ChatDev's role specs raised task success by 9.4%; adding high-level objective verification gained 15.6% on ProgramDev. Architecture and verification help, not agent count.

Honestly: on most tasks a single well-built agent beats a multi-agent system. The failure-taxonomy paper states plainly that gains over a single agent or simple baselines like best-of-N (try the same task a few times and keep the best) are often minimal. So before committing to an architecture, compare it against simple baselines: single agent, self-reflection, best-of-N, majority vote.

Practical rule: start from the minimum coordination topology and add an agent only for a clear separation. Which separation? Context separation (distinct contexts that won't fit one window), tool separation (work needing different authority and access), authority separation (who decides what), critique (when an independent critic genuinely adds value), or verification separation (when the producer and the checker must be different). If none of those apply, the extra agent is most likely just noise.

A multi-agent system is a tool, not a destination: it is powerful when the task naturally splits into roles, artifacts, phases, or competing views. When none of that holds, more agents just means more model calls, more latency, and more error that accumulates and grows.

So when choosing an architecture, don't ask "how many agents?" Ask "which separation earns an agent?" If there's no answer, a single well-built agent is already the best system you have.

1. S1Chen et al., A Survey on LLM-based Multi-Agent System, 2025
2. S2Wu et al., AutoGen, 2023
3. S3Li et al., CAMEL, NeurIPS 2023
4. S4Hong et al., MetaGPT, ICLR 2024
5. S5Qian et al., ChatDev, ACL 2024
6. S6Liang et al., Multi-Agent Debate, EMNLP 2024
7. S7Cemri et al., Why Do Multi-Agent LLM Systems Fail?, NeurIPS 2025