Multi-agent systems trade one hard problem for a coordination problem

What qualifies as a multi-agent system

A workflow does not become multi-agent merely because it makes several model calls. The useful distinction is whether multiple participants maintain separate roles, context, tools, goals, state, or authority and coordinate to produce an outcome.

One agent may generate a draft and a second may independently test claims. A supervisor may route tasks to specialists. Peers may share a blackboard or negotiate a plan. Several agents may search in parallel and a human may select among their evidence. These patterns create different information flows and failure modes.

The AutoGen paper helped popularize conversational multi-agent application patterns, while later surveys organize a growing field of coordination, communication, planning, memory, and evaluation approaches. [S1] [S2] [S3]

Why divide work among agents

Multiple agents are defensible when the separation itself creates value. The value should be stated before implementation and measured afterward.

• Specialization: distinct prompts, tools, data, or evaluation rubrics for different roles
• Independent challenge: a critic or verifier that does not share the same context or assumptions
• Parallelism: bounded work that can proceed independently and be merged later
• Information boundaries: different agents receive only the data and permissions required for their role
• Fault isolation: a failing component can be retried, replaced, or contained without restarting the entire process
• Organizational alignment: the workflow mirrors accountable human roles and decision rights

Common coordination topologies

Topology determines where authority, state, and failure concentrate. A team diagram should show messages, shared stores, tools, and decision points—not only agent names.

Supervisor and specialists

A central coordinator decomposes work, selects specialists, and combines results. This is easy to understand but concentrates authority and creates a supervisor bottleneck. The supervisor also needs enough evidence to detect when a specialist result is incomplete or misleading.

Pipeline or handoff

Each agent transforms an artifact and passes it to the next. The pattern fits stable stages, but early errors can become entrenched and later agents may lack the original evidence needed to challenge them.

Peer deliberation

Agents exchange proposals, critiques, or votes. This can improve coverage when perspectives are meaningfully independent. It can also create echo chambers, endless debate, and expensive convergence without a clear decision rule.

Blackboard or shared workspace

Agents read and write to a common state store. This supports asynchronous collaboration but requires provenance, access control, versioning, conflict resolution, and protection against poisoned shared memory.

Market, auction, or contract-net

Agents bid for work or resources based on capability and cost. These mechanisms can support dynamic allocation, but the utility function and incentives become part of the safety and quality boundary.

Coordination cost is a first-class metric

Adding agents introduces messages, context transfer, duplicate work, arbitration, latency, and more model calls. The team may produce more artifacts while making the final decision less clear.

A proper baseline compares the team with a strong single-agent or deterministic approach under the same cases. Measure quality, completeness, authorization behavior, cost, latency, reviewer effort, and recovery—not only whether the final answer looks sophisticated.

Recent research has cataloged multi-agent failure modes and found that teams can underperform their strongest member when coordination is weak or error is correlated. [S4] [S5]

Message contracts and shared state

Natural-language messages are flexible but ambiguous. For production work, messages should carry structured fields that make responsibility and evidence inspectable.

• Task identifier, goal, scope, deadline, and completion criteria
• Sender identity, role, authority, and relevant policy version
• Input evidence identifiers and data-classification boundary
• Proposed output type, confidence or uncertainty state, and unresolved questions
• Tool calls and side effects already completed
• Expected response, escalation path, and timeout behavior
• Trace and provenance links so the result can be reviewed later

Evaluation must include the team process

A team can produce a correct answer for the wrong reasons. It can also produce a poor answer even though one participant found the right evidence. Evaluation should therefore cover individual performance, communication, aggregation, conflict handling, and the final outcome.

SwarmBench and related benchmarks are useful because they examine coordination rather than treating each agent as an isolated question-answering model. Still, benchmark performance does not establish fitness for a particular enterprise workflow. [S6]

• Did task decomposition preserve the original objective?
• Were roles distinct enough to justify separate agents?
• Did agents share the right evidence without widening access?
• Were disagreements visible and resolved by a declared rule?
• Did the aggregator retain minority evidence or suppress it?
• Could the team stop when work was complete or evidence was insufficient?
• How did communication volume, cost, and latency change with team size?
• What happens when one agent is compromised, unavailable, or persistently wrong?

Human authority and organizational accountability

A multi-agent architecture can obscure ownership by distributing reasoning across components. The human operating model must remain simpler than the machine team. Name one accountable owner for the outcome, define who may change roles and prompts, and identify which decisions require independent human approval.

Do not use an internal vote among agents as a substitute for authority. A majority can be consistently wrong, share the same source defect, or converge through persuasive language rather than evidence. Quorum, consensus, and debate are computational mechanisms; they do not create legal, ethical, or operational accountability.

Security and reliability failure modes

Multi-agent systems expand the attack and failure surface. One compromised agent can send malicious instructions, poison shared memory, over-delegate authority, or trigger cascading tool use. A failing coordinator can strand in-progress work. A retry can repeat actions across more than one participant.

OWASP's agentic guidance includes multi-agent and cascading-risk concerns. The practical response is compartmentalization: narrow identities, signed or authenticated messages where appropriate, structured validation, trace correlation, rate and cost limits, circuit breakers, and a global stop mechanism. [S7] [S8]

When one agent is better

Prefer one agent or a deterministic workflow when the task has one clear owner, requires shared context throughout, has limited opportunity for independent parallelism, or cannot tolerate coordination ambiguity. A single agent with explicit tools, state, and evaluators is often easier to secure and test than a team of weakly differentiated personas.

Use multiple agents only after documenting the expected benefit, simpler baseline, coordination protocol, authority model, and evaluation plan. If those artifacts do not exist, the team is a demonstration rather than a production architecture.

Research boundary

This page is an engineering reference, not a universal recommendation for agent teams. Research results vary across tasks, models, prompts, topologies, and evaluation methods. Production use requires representative testing, security review, and human ownership for the specific workflow.