Multi-Agent Systems

What is a multi-agent system?

A multi-agent system (MAS) is a software architecture in which two or more semi-autonomous agents collaborate to accomplish a goal. In the context of large language models, each agent is typically an LLM equipped with a system prompt that defines its role, a set of tools it may call, and its own context window. Rather than asking one model to plan, search, reason, and write inside a single conversation, a multi-agent system decomposes the work and assigns pieces to specialized agents that operate, often in parallel, under a coordination scheme.

The concept predates LLMs. Multi-agent systems are a long-standing subfield of distributed artificial intelligence concerned with how independent computational entities negotiate, cooperate, and compete. What is new in the LLM era is that each agent can interpret natural-language instructions, reason over open-ended inputs, and decide its own next action, which makes loose, language-mediated coordination practical at scale.

An agent in this setting is more than a single prompt. It usually maintains state across multiple turns, calls external tools or APIs, and decides when its subtask is complete. A multi-agent system is the layer above that: the rules for who does what, in what order, and how results flow back together.

• An agent: one LLM instance with a role, tools, and a context window.
• A multi-agent system: multiple such agents plus a coordination pattern and a communication channel.
• Goal: higher reliability, specialization, or parallelism than a single agent can provide.

Single agent vs. multi-agent: why split the work

A single well-scoped agent is the correct default for most tasks. It is simpler to build, cheaper to run, and easier to debug, and it avoids the coordination overhead that multi-agent systems introduce. Splitting work across agents only pays off when the task has structure that a single context window handles poorly.

Three conditions tend to justify a multi-agent design. First, specialization: distinct subtasks benefit from different prompts, tools, or even different models, so a dedicated agent outperforms a generalist. Second, parallelism: independent subtasks can run concurrently, cutting wall-clock latency. Third, separation of generation and evaluation: a separate critic agent can catch errors that a model is unlikely to catch when grading its own output in the same context.

Anthropic reported that its Research feature, built as an orchestrator-worker multi-agent system with a lead agent on Claude Opus 4 and parallel subagents on Claude Sonnet 4, outperformed a single-agent Claude Opus 4 configuration by 90.2% on an internal research evaluation. The same engineering write-up cautions that multi-agent systems consume far more tokens than single-agent chats, reporting roughly 15 times the tokens of a chat interaction, so the gains must justify the cost.

• Default to one agent; reach for many only when structure demands it.
• Specialization, parallelism, and independent verification are the main reasons to split.
• Multi-agent systems trade higher token cost and complexity for reliability and speed.

Core roles: orchestrator, worker, planner, critic, and tool agents

Most multi-agent designs are assembled from a small vocabulary of roles. Agents are heterogeneous by function, and the same physical model can play different roles depending on its prompt.

The orchestrator (also called lead, supervisor, or coordinator) receives the top-level request, decides on a strategy, decomposes it into subtasks, dispatches them, and synthesizes the results. Worker agents execute a single scoped subtask and return a result; in many designs they are stateless and unaware of each other. A planner separates strategy from execution by producing an explicit plan that an executor then carries out, which helps with concurrent actions and resource allocation. A critic (or verifier or refiner) evaluates another agent's output and requests revisions, forming an iterative improvement loop. Tool agents wrap a specific capability, such as a search API, a code interpreter, or a database, behind a clean interface.

• Orchestrator: plans, decomposes, dispatches, and synthesizes.
• Worker: executes one scoped subtask, often statelessly.
• Planner and executor: explicitly separate strategy from action.
• Critic and verifier: evaluate and refine another agent's output.
• Tool agent: encapsulates a single external capability.

Coordination patterns: hierarchical, sequential, blackboard, and debate

A coordination pattern defines the topology of communication and control between agents. Four recur across production and research systems.

Hierarchical (orchestrator-worker, or supervisor) is the most common production topology: a central agent dispatches subtasks to workers and aggregates their results. It is the structure behind Anthropic's Research system, where a lead agent spins up several subagents in parallel, each with a self-contained task and a fresh context window. A sequential pipeline chains agents so that each one's output is the next one's input, which suits staged workflows such as research, then draft, then edit. The blackboard pattern, inherited from classical AI, has agents read from and write to a shared workspace rather than messaging each other directly, so contributions accumulate asynchronously. Multi-agent debate has several agents independently propose answers and then critique and revise across rounds until they converge; a 2023 study found this improved factuality and reasoning relative to a single pass.

• Hierarchical / orchestrator-worker: central control, parallel workers, easiest to reason about.
• Sequential pipeline: staged hand-offs, output of one agent feeds the next.
• Blackboard: agents share a common workspace instead of point-to-point messaging.
• Debate: independent proposals critiqued and revised over rounds to raise accuracy.

Communication and shared memory between agents

Agents coordinate through some combination of message passing and shared state. In message passing, an orchestrator sends each worker a self-contained task description and an expected output format, and the worker returns a structured result. Keeping the message self-contained matters: in Anthropic's design each subagent received its objective, an output format, and a fresh context window and did not know the other subagents existed, which prevents them from drifting on each other's partial reasoning.

Shared memory is the alternative channel. Agents can write intermediate findings, plans, and citations to a common store such as a blackboard, a vector database, or a scratchpad file that other agents read later. This decouples producers from consumers and lets long-running systems persist state beyond a single context window. The trade-off is that shared memory can become a source of context drift if stale or low-quality entries accumulate.

A practical design decision is how much context each agent sees. Passing the full conversation to every agent maximizes information but inflates token cost and dilutes focus; passing minimal scoped context keeps agents sharp but risks omitting something they needed.

• Message passing: structured, self-contained tasks and results between agents.
• Shared memory: a blackboard, vector store, or scratchpad agents read and write.
• Context scoping is a core lever: more context aids coverage but raises cost and drift.

Common failure modes: error compounding, loops, cost blowup, and context drift

Multi-agent systems introduce failure modes that single agents do not have. A UC Berkeley study, Why Do Multi-Agent LLM Systems Fail?, analyzed more than 200 execution traces across seven popular frameworks and produced MAST, a taxonomy of 14 failure modes grouped into three categories: specification issues, inter-agent misalignment, and task verification. The authors found specification issues, which cover system architecture, prompt design, and state management, accounted for the largest share of failures at roughly 42%, underscoring that many problems originate in how the system is set up rather than in any single model call.

Error compounding is the headline risk: a mistake by an upstream agent propagates downstream because later agents trust their inputs. Loops occur when agents repeat completed steps or re-issue the same query without making progress, wasting tokens. Cost and latency blowup follows from the token-heavy nature of agent-to-agent exchanges, especially when full context is broadcast to every agent. Context drift arises when agents lose track of the original objective or act on stale shared state, and role ambiguity lets a worker overstep into decisions that belong to the orchestrator.

• Error compounding: upstream mistakes propagate through downstream agents.
• Loops and step repetition: agents redo work or repeat queries without progress.
• Cost and latency blowup: token-heavy coordination, worsened by broadcasting full context.
• Context drift and role ambiguity: agents lose the goal or exceed their assigned role.

Frameworks and protocols

Two layers of tooling support multi-agent systems: orchestration libraries that structure agents in code, and interoperability protocols that standardize how agents reach tools and each other.

Among orchestration libraries, LangGraph models agent interactions as nodes in a directed state graph, which suits branching and conditional workflows; CrewAI uses a role, goal, and backstory abstraction that maps cleanly onto team-like workflows; and AutoGen centers on conversational, message-driven collaboration between agents. Each encodes a different mental model: workflow graph, role assignment, or conversation.

On the protocol layer, Anthropic's Model Context Protocol (MCP), announced on November 25, 2024, standardizes how a single agent connects to tools and data sources (a vertical integration between an agent and its capabilities). Google's Agent2Agent (A2A) protocol, announced in April 2025, standardizes communication between separate agents (a horizontal integration), and Google describes it as complementary to MCP. In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI.

• LangGraph: state-graph orchestration for branching, conditional workflows.
• CrewAI: role-based abstraction for team-style task assignment.
• AutoGen: conversation-driven, message-based agent collaboration.
• MCP: an agent-to-tool standard, announced November 2024, now under the Linux Foundation.
• A2A: a Google agent-to-agent standard, announced April 2025, complementary to MCP.

When to use multi-agent vs. a single well-scoped agent

Choosing a multi-agent design is an engineering trade-off, not a default. Because agent-to-agent coordination multiplies token usage and adds points of failure, the simplest architecture that meets the requirement is usually the right one.

Favor a single, well-scoped agent when the task fits in one context window, the steps are tightly coupled and mostly sequential, latency and cost budgets are tight, or the workflow is easy to express as a linear tool-use loop. A single agent is also far easier to evaluate and debug, since there is one trace to inspect.

Favor a multi-agent system when subtasks are genuinely independent and can run in parallel, when distinct subtasks need different tools or specialized prompts, when an independent critic measurably raises quality over self-review, or when the problem naturally decomposes into a research-and-synthesis shape. The deciding question is whether the value gained from specialization, parallelism, or independent verification exceeds the added cost, latency, and operational complexity.

• Single agent: coupled steps, tight budgets, one context window, easy debugging.
• Multi-agent: independent parallel subtasks, specialized tooling, valuable independent review.
• Decide by whether the gains outweigh the extra tokens, latency, and failure surface.

Multi-agent systems and persistent memory

Persistent memory is what lets a multi-agent system operate beyond the limits of any single context window. An orchestrator can record its plan and a worker's findings to durable storage so the work survives context resets, long-running tasks, and resumed sessions, and so later agents can build on earlier results rather than rediscovering them.

Shared, retrievable memory also gives agents a common ground of facts to coordinate around, reducing duplicated effort and context drift. The same retrieval techniques that back agent memory, such as semantic search over a vector store, also power consumer AI memory tools that let a person store documents and recall them in plain language.

• Persistent memory lets agents share state across context resets and long tasks.
• A common retrievable store reduces duplicated work and context drift between agents.
• The same retrieval techniques power personal AI memory and second-brain apps.