Multi-agent system

A multi-agent system is an architecture in which two or more AI agents, each with its own role, tools, and instructions, coordinate to complete a task that a single agent handles poorly on its own. A triage agent might route work to specialist agents, a planner agent might break a goal into steps for an executor agent to carry out, or a critic agent might review the output of a writer agent before it ships. What distinguishes this from a single agent using several tools is that each participant has its own system prompt, its own scope, and often its own underlying model.

Multi-agent designs trade added complexity for added capability. They show up once a task grows past what a single, well-scoped agent can reliably manage — spanning multiple domains, requiring different safety rules at different steps, or benefiting from cheaper, faster models for simple work and more capable models for hard work. The pattern has become common enough in production AI systems that most serious agent frameworks now assume multi-agent coordination as a first-class capability rather than an advanced edge case.

Why use multiple agents instead of one

A single-agent design works well when a task fits comfortably inside one context window and calls a limited, coherent set of tools. It starts to break down under a few specific pressures.

The task may span multiple distinct domains — billing, shipping, and technical support, for instance — each of which benefits from its own instructions and guardrails rather than one sprawling prompt trying to cover all three.

Different steps of a workflow may need different system prompts or safety constraints that do not compose cleanly into a single prompt, and the total context a task requires may simply exceed what one model call can hold reliably.

There is also often a real cost argument for using a cheap, fast model for triage and a slower, more capable reasoning model only for the steps that actually need it.

Common multi-agent patterns

Orchestrator plus specialists. One manager agent routes incoming work to specialist agents — returns, shipping, account access — and combines their outputs into a single response.

Planner plus executor. A planner agent decomposes a goal into discrete steps, and an executor agent carries out each step in turn, a structure closely related to a broader agentic workflow.

Debate. Two or more agents argue different sides of an ambiguous question, and a separate judge agent picks a winner, which is useful for reducing hallucinations on questions without a clean single answer.

Critic and generator. One agent produces an answer, a second agent critiques it, and the loop repeats until the output clears a quality threshold — the same underlying logic used in LLM-as-a-judge evaluation, applied inline during generation rather than after the fact.

Blackboard. Agents read from and write to a shared workspace instead of messaging each other directly, which loosens coupling but makes the overall flow harder to trace.

How agents in a multi-agent system talk to each other

Direct messaging is the simplest approach: agents pass structured messages, usually JSON, to one another, typically mediated by an orchestrator that decides who talks to whom next.

Tool calls are the most common pattern in production, where one agent is exposed to another simply as a callable tool, which keeps the interface between agents narrow and well-defined.

Shared memory is a third option, where every agent reads and writes a common state store rather than passing messages point to point. It is powerful for complex, long-running tasks but noticeably harder to reason about, since any agent can affect state that any other agent depends on.

Where multi-agent systems break down

The most common mistake is over-engineering from day one. Teams that start with five agents before establishing whether a single, well-designed agent could handle the task usually end up debugging coordination problems instead of improving the actual task performance. The better default is to start with one agent and add specialists only once a specific limitation forces the issue.

Coordination itself has a real cost: every agent-to-agent handoff is another model call, and the latency and expense compound quickly as the number of agents grows. Debuggability suffers too — tracing why a final answer was wrong across five agents and their intermediate messages is considerably harder than tracing it through a single agent's reasoning.

Reliability compounds in the wrong direction as well: if each agent in a five-step chain is 90% reliable on its own, the overall chain succeeds only around 59% of the time, which is a sharp reminder that adding agents adds failure points, not just capability.

Where multi-agent systems fit in an AI stack

A production customer-experience deployment often looks like several specialists working behind one conversational interface: a triage step classifies the request, a retrieval step runs agentic search against the knowledge base, a policy check confirms whether the requested action is allowed under the customer's contract, and an action step executes the resolution through backend tool calls, with a final review step checking the response before it reaches the customer.

The customer experiences all of this as one seamless agent, even though several specialists collaborated behind the scenes. The software layer that actually runs this coordination — routing, memory, message passing, observability — is AI agent orchestration; the multi-agent system is the architectural pattern, and orchestration is the infrastructure that makes it operable at production scale and volume.