A multi-agent system is a system in which several agents, each with its own role, instructions or tools, work on a task by delegating, exchanging results or acting in parallel. It raises questions a single agent does not, such as which agent acted, under whose authority and with what shared state.
The idea is older than language models. Multi-agent systems have been a field of computer science for decades, studying how independent software agents cooperate, negotiate and compete; Michael Wooldridge’s textbook on the subject was first published in 2002. What changed with language models is how cheaply an agent can be made. A new specialist is now a prompt and a tool list, so systems with a planner, several researchers, a reviewer and an executor have become an ordinary design choice. Frameworks such as AutoGen, introduced in 2023, made conversations between agents a programming model of their own.
When several agents beat one
The case for multiple agents is parallelism and focus. Anthropic reported that its research system, a lead agent directing parallel subagents, outperformed a single agent by 90.2 percent on an internal research evaluation. The same account is frank about the price: multi-agent systems used about fifteen times the tokens of a chat interaction. They suited broad tasks that split into independent parts, and were a poor fit where agents need to share a great deal of context or depend closely on one another; Anthropic named most coding tasks as an example.
Cognition, the company behind the coding agent Devin, made the opposite case in a 2025 post titled “Don’t Build Multi-Agents”. Its argument is that actions carry implicit decisions, so two agents working from partial context make choices that conflict; its illustration is two subagents building parts of a game in mismatched styles. Cognition recommended a single agent with full context for most work, while describing its view as provisional.
Both accounts agree on the mechanism. A multi-agent system is only as good as what each agent knows about the others’ work. Research on failures points the same way: a study of 1,600 annotated traces across seven frameworks (Cemri et al., 2025) grouped multi-agent failures into system design issues, misalignment between agents, and weak task verification.
Who acted, under whose authority
The approved definition names a second set of questions, and they are the ones that matter once agents can change real systems.
Which agent acted. In many deployments, agents share a service account or an API key. The log of the system that was changed then says “the service account did this”, not “the deployment agent did this, delegated by the planner, on behalf of this user”. The chain that explains the action exists only inside the agents’ conversations, if anywhere.
Under whose authority. In a single agent, the one that decides and the one that acts are the same. In a multi-agent system they are often different: the planner decides that a deployment should happen, a deployment agent performs it, and the person who started the task authorized neither step directly. Authority passes along a chain of delegation, and every link is a place where it can widen.
With what shared state. Agents read each other’s outputs. One agent’s mistaken result becomes another’s input, which is why the OWASP Top 10 for Agentic Applications lists cascading failures and insecure communication between agents among its risks. Errors are inherited, so the evidence needed to explain them has to follow the chain too. A record that stops at each agent’s boundary cannot show where a cascade began.
One policy does not fit every agent
A research agent that reads widely and a deployment agent that writes to production carry very different risk. A single policy for the whole system is either too loose for the deployer or too tight for the researcher. The workable model is policy per agent: each agent identified, bound to the rules that fit its role, and recorded with the binding that applied, so a later review can tell which rules were in force for which action.
Where Sentience fits
Sentience Governor, the free, open-source runtime governance library, records agents individually where they are instrumented individually. Every event carries an agent identifier and its session, and policy resolution binds an agent identifier to a governance profile, once per session, recording which binding applied and the fingerprint of the profile on each governed event.
How agents get their identifiers depends on the integration. With the MCP client wrapper, the LangChain and LangGraph handler and the separate Pydantic AI package, the developer names each governed agent, so a researcher and a deployer given their own identifiers are evaluated under their own rules, against their declared scope, and the result is governance evidence of what each one attempted. In LangGraph, the nodes of one graph run under the identifier of the handler that governs the graph. In Claude Code, the identifier is derived from the session rather than named per agent, so policy follows the session, not each subagent’s role; launching a subagent is recorded as an action.
Governor’s record is local and per session. It does not trace a chain of delegation across agents, and it does not aggregate sessions across agents or machines. It records and flags, and does not stop agents from acting.
For teams running agent fleets, Sentience builds the next steps as a customer engagement: a unified view of activity across agents, as in the multi-agent runtime dashboard use case, and Sentience Runtime Enforcement to escalate or stop an individual agent’s action at the control points in your infrastructure, with evidence of every intervention.
Often confused with
A single agent with tools. One agent that calls many tools is not a multi-agent system. The distinction is several decision-makers, each with its own context and instructions.
A swarm. Swarm intelligence, a term from robotics research in 1989, describes many simple agents producing collective behavior with no leader. OpenAI later used “Swarm” as the name of an experimental, educational framework built on explicit handoffs between named agents, since replaced by its Agents SDK. The two meanings are close to opposites; most LLM multi-agent systems are coordinated, not emergent.
Agent orchestration. Orchestration is how work is coordinated. A multi-agent system is one in which the coordinated parts include several agents.
Where the concept stops
Describing a system as multi-agent says how the work is divided. It does not say which agent was responsible for a given effect, whether the authority each agent exercised matched its role, or whether a result passed between agents was correct. Those depend on identifying each agent, binding each to its own policy, and keeping evidence that follows the work across the agents that touched it.