What Are Multi-Agent Systems? A 2026 Engineering Guide
Published September 17, 2026·12 min read
TL;DR
A multi-agent system (MAS) is an AI application where several LLM-driven agents — each with its own instructions, tools, and context — coordinate on a task one agent handles less reliably. Usually a lead or supervisor agent decomposes the goal, delegates to specialized workers (often in parallel), and synthesizes the results; agents communicate by passing messages, handing off control, or sharing state. The common architectures are orchestrator-worker, hierarchical, sequential, network/swarm, and the emerging blackboard pattern. Multi-agent designs win on broad, parallelizable, read-heavy work — Anthropic's research system beat a single agent by 90.2% on its internal eval — but they cost roughly 15× the tokens of a chat and are harder to debug, so most teams start single-agent and split only when the work genuinely parallelizes. This guide covers the architectures, the honest tradeoffs, communication protocols, failure modes, and framework support.
What is a multi-agent system?
A multi-agent system (MAS) is an AI application in which several LLM-driven agents — each with its own instructions, tools, and context window — coordinate to complete a task a single agent handles less reliably. Usually one agent orchestrates: a lead or supervisor agent decomposes the goal, delegates subtasks to specialized worker agents that often run in parallel, then synthesizes their outputs. Agents communicate by passing messages, handing off control, or reading and writing shared state. Multi-agent designs excel on broad, parallelizable work such as research across many sources — but they add token cost, latency, and coordination complexity, so most teams start single-agent and split only when the work justifies it.
Key facts
- A multi-agent system uses several coordinating agents, typically a supervisor that delegates to specialized workers; a single agent uses one continuous context.
- Anthropic's multi-agent research system beat single-agent Claude by 90.2% on its internal research eval — but the same team measured that multi-agent systems use ~15× more tokens than a chat (single agents already use ~4×).
- The main architectures: orchestrator-worker (supervisor), hierarchical, sequential/pipeline, network/swarm, and the emerging blackboard pattern.
- The consensus rule from practitioners (Cognition, LangChain): read-heavy work parallelizes well; writes should stay single-threaded through one coherent agent to avoid conflicting decisions.
- Cross-vendor agent communication is standardizing on the A2A (Agent2Agent) protocol — announced by Google (April 2025) and donated to the Linux Foundation (June 2025) — while MCP connects agents to tools and data.
- The honest default: start single-agent; go multi-agent when the task is broad, parallelizable, exceeds one context window, and valuable enough to absorb the cost.
How is a multi-agent system different from a single agent?
A single agent runs one loop with one continuous context: it reasons, calls tools, observes results, and repeats, all inside a single thread. A multi-agent system splits the work across several agents that each maintain their own context and coordinate — the promise being parallelism and specialization, the price being coordination.
The critical insight, and the reason multi-agent is not automatically better: context fragmentation. When you split a task across parallel agents, each one acts on incomplete information. Cognition frames it sharply — "actions carry implicit decisions, and conflicting decisions carry bad results." A single agent never has that problem because it holds the whole context; a multi-agent system has to engineer context-sharing to avoid agents working at cross-purposes.
Single agent vs multi-agent: which should you use?
| Dimension | Single agent | Multi-agent |
|---|---|---|
| Token cost | Baseline (agents already ~4× a chat) | ~15× a chat (Anthropic's measurement) |
| Latency | Bounded by one context | Parallel workers can cut wall-clock time, but add orchestration overhead |
| Complexity | Low — one prompt, one trace | High — coordination, shared state, error compounding |
| Debuggability | One linear trace | Harder — many interacting, non-deterministic traces |
| Reliability on shared-context work | Higher (continuous context) | Lower — "conflicting decisions carry bad results" |
| Best fit | Most tasks; write-heavy/coding work | Breadth-first, parallelizable, read-heavy exploration |
| When to choose | Default starting point | When task value justifies the cost and work parallelizes cleanly |
Start on the left. Move right only when a concrete need — parallel breadth, work that exceeds one context window — makes the cost worth it.
What are the common multi-agent architectures?
| Pattern | Use when | Main tradeoff |
|---|---|---|
| Orchestrator-worker / supervisor | A clear lead can decompose and delegate bounded subtasks | Supervisor is a bottleneck; extra routing calls |
| Supervisor (tool-calling) / manager | You want tight context control; the specialist shouldn't own the conversation | More engineering to expose agents as tools |
| Hierarchical | Many specialists; teams-of-teams scale | Latency and cost multiply per level |
| Sequential / pipeline | Deterministic, ordered stages (retrieve → summarize → format) | Rigid; no dynamic routing |
| Network / swarm (peer) | No clear hierarchy; dynamic, conversational routing | Hard to predict and debug; can loop |
| Blackboard (emerging) | Many independent contributors around shared state | Immature tooling; control logic is non-trivial |
What is the orchestrator-worker (supervisor) pattern?
The most common production pattern. A lead (supervisor) agent coordinates the process and delegates to specialized subagents; control returns to the supervisor after each worker finishes. Anthropic's research system is the canonical example: "a lead agent coordinates the process while delegating to specialized subagents that operate in parallel."
There are two variants. In the classic supervisor, the lead routes work and collects results. In the supervisor (tool-calling) or manager variant, each worker is exposed to the lead as a tool, and a tool-calling model picks which to invoke — LangChain now recommends this variant for most use cases because it gives tighter control over what context each agent sees. The OpenAI Agents SDK calls it the "manager" pattern: use it "when a specialist should help with a bounded subtask but should not take over the user-facing conversation."
What is a hierarchical multi-agent system?
Hierarchical systems add levels of supervision: a top supervisor manages other supervisors, each managing a team of workers — teams of teams. As LangGraph's docs put it, "you can create multi-level hierarchical systems by creating a supervisor that manages multiple supervisors." CrewAI's hierarchical process does this automatically by assigning a manager agent that delegates tasks and validates results before proceeding.
Hierarchy buys you scale — you can compose many specialists without one supervisor drowning in decisions — but every level multiplies latency and token cost. Add levels only when a flat supervisor genuinely can't manage the breadth.
What is the network or swarm pattern?
In a network (peer-to-peer) architecture there is no central controller: every agent can decide which agent to call next. It suits problems with "no clear hierarchy or specific order in which agents must be called." LangGraph's swarm implementation makes this concrete — agents transfer control directly to one another, and the system remembers which agent was last active, so the conversation resumes with the right specialist.
The OpenAI Agents SDK's handoffs pattern is the decentralized analog: a triage agent routes to a specialist, and that specialist "becomes the active agent for the rest of the turn." Swarms are flexible and conversational, but the lack of a controller makes them the hardest pattern to predict and debug — and the easiest to send into a loop.
What is the blackboard architecture (and is it production-ready)?
The blackboard is a 1980s AI pattern being revived for LLMs. Heterogeneous agents ("knowledge sources") read from and write to a shared structured workspace — the blackboard — where partial results, hypotheses, and constraints accumulate, while a control component decides who acts next. Recent research (arXiv preprints 2510.01285 and 2507.01701) reports relative gains of 13–57% over baselines on information-discovery tasks.
Treat this as emerging, not mainstream: the gains come from individual academic preprints, tooling is immature, and the control logic is non-trivial. It's worth knowing as a direction of travel, not a default you reach for in production today.
Dexity Intel · free newsletter
Liking this? Get the next one in your inbox.
JD-backed career reads, AI market signals, and field-tested tool guides — a few times a month. No fluff, no spam.
How do agents communicate and hand off tasks?
Two layers, and it's worth keeping them straight:
- Within a framework, agents coordinate through message passing and shared graph state (LangGraph) or explicit handoffs that transfer the conversation history to another agent (OpenAI Agents SDK: "the delegated agent receives the conversation history and takes over"). The practitioner rule from Cognition: "share context, and share full agent traces, not just individual messages" — a handoff that drops the trace loses the implicit decisions behind it.
- Across frameworks and vendors, communication is standardizing on the A2A (Agent2Agent) protocol — announced by Google in April 2025 and donated to the Linux Foundation in June 2025 — which uses HTTP, Server-Sent Events, and JSON-RPC, with "Agent Cards" that advertise each agent's capabilities. Distinguish A2A (agent-to-agent) from MCP (Model Context Protocol), which connects an agent to tools and data, not to other agents.
When do multi-agent systems fail?
The dominant failure mode is fragmented context producing conflicting decisions. Cognition's widely-cited critique, Don't Build Multi-Agents, gives a memorable example: one subagent renders a Super Mario–style background while another, working in parallel, builds a visually incompatible bird, and the parent agent can't cleanly reconcile them. Each subagent made a reasonable local choice; together they're incoherent.
The other failure modes follow from coordination: handoffs that drop full traces, compounding errors across steps (a wrong early result poisons everything downstream), and non-determinism that makes bugs hard to reproduce across many interacting agents. The takeaway isn't "never use multi-agent" — it's that multi-agent systems demand deliberate context engineering that single agents get for free.
Do multi-agent systems cost more?
Yes, materially. Anthropic measured that multi-agent systems use about 15× the tokens of a chat interaction, where single agents already use around 4×. That's the trade you're making: parallel subagents can dramatically cut wall-clock time on breadth-first research, but you pay for it in tokens and in debuggability.
Anthropic states the gating condition plainly: "multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance." If a task isn't valuable enough to justify roughly an order-of-magnitude more tokens, it shouldn't be multi-agent.
What frameworks support multi-agent systems?
| Framework | Multi-agent model |
|---|---|
| LangGraph | Graph of agents/nodes; prebuilt supervisor and swarm packages; network, hierarchical, and custom architectures |
| CrewAI | Role-based Crews with sequential or hierarchical (auto-manager) processes, plus event-driven Flows |
| OpenAI Agents SDK | Handoffs (decentralized) and agents-as-tools / manager; also code-orchestrated chaining |
| AutoGen / AG2 | Conversational multi-agent — GroupChat with speaker selection, RoundRobin, Swarm |
| Microsoft Agent Framework | Graph-based workflows uniting AutoGen orchestration + Semantic Kernel enterprise features; A2A + MCP native |
A naming note that trips people up: AutoGen began at Microsoft Research; the community fork AG2 continues that conversational line, while Microsoft's newer work has converged into the Microsoft Agent Framework (with Semantic Kernel and AutoGen now in maintenance). And two standards sit above all of them — A2A for cross-framework agent communication and MCP for tool access.
When should you actually build a multi-agent system?
Start single-agent. Reach for multi-agent when four things are true at once: the work is genuinely parallel (independent subtasks that don't depend on each other), it's breadth-first (exploring many directions, like research across sources), it exceeds one context window, and it's valuable enough to absorb roughly 15× the token cost and harder debugging.
The reconciliation that both camps — Anthropic (pro) and Cognition (skeptic) — actually agree on: let multiple agents read and explore in parallel, but keep writes single-threaded through one coherent agent. Parallel readers add intelligence cheaply; parallel writers create conflicts. That single rule prevents most multi-agent disasters.
Frequently asked questions
Is more agents always better?
No. Anthropic found multi-agent beat single-agent by 90.2% on research, but the same post warns multi-agent uses ~15× the tokens and is a poor fit when agents must share context or have many dependencies. Start single-agent.
What tasks suit multi-agent systems?
Breadth-first, parallelizable, read-heavy work — researching many independent sources, large-scale search and analysis — where the task's value justifies the extra cost.
Why do multi-agent systems fail?
Fragmented context. Parallel agents make conflicting implicit decisions ("conflicting decisions carry bad results," Cognition), and handoffs that drop full traces plus compounding errors make failures hard to debug.
Should writes be parallelized across agents?
Generally no. The emerging consensus (Cognition, LangChain) is to let multiple agents read and explore in parallel but keep writes single-threaded through one coherent agent to avoid conflicts.
How do agents from different vendors talk to each other?
Via the A2A (Agent2Agent) protocol — open, Linux Foundation–governed, using HTTP/JSON-RPC and "Agent Cards" — while MCP handles agent-to-tool connections.
Do I need a framework to build a multi-agent system?
Not necessarily, but frameworks earn their keep here more than for single agents — coordination, shared state, and handoffs are real work. LangGraph, CrewAI, the OpenAI Agents SDK, and AG2 all provide multi-agent primitives.
Related reading
- How to build an AI agent — the single-agent loop these systems are built from.
- AI agent frameworks compared — LangGraph vs CrewAI vs AutoGen vs OpenAI Agents SDK, and which does multi-agent best.
- How to evaluate AI agents — why multi-agent traces are harder to grade, and what to measure.
Build systems that survive coordination, not just demos
Multi-agent systems fail on the boring things — context sharing, handoffs, cost control, and evaluation — not on the clever parts. Dexity's Ship Production Code with AI course has you build and evaluate a real tool-using system end-to-end, so you learn where coordination actually breaks before it breaks in production — the judgment every AI-engineering interview and job tests.
Sources: multi-agent architectures and the pro/skeptic debate from Anthropic, How we built our multi-agent research system, Cognition, Don't Build Multi-Agents, and LangChain, How and when to build multi-agent systems; handoff/orchestration patterns from the OpenAI Agents SDK and LangGraph/CrewAI docs; the A2A protocol via the Linux Foundation. The 90.2%, 4×, and 15× figures are Anthropic's own measurements on its own system, not independent benchmarks; the blackboard pattern is an emerging research direction. US-only. · Dexity.com
Go from reading to doing · Dexity Course
Ship Production Code with AI
Most senior engineers have tried Cursor or Claude Code and ended up with larger PRs, more review cycles, and hidden technical debt. The problem isn't the tools — it's that nobody taught the system design and reasoning control behind them.
