what is a multi-agent system? the definition, components, and where they break

a multi-agent system is several autonomous agents sharing one environment

A multi-agent system, or MAS, is a set of autonomous AI agents that share one environment. They coordinate to reach a goal that none of them could reach alone. Each agent sees part of that environment. It decides its own next action, it acts, and the other agents see the result. That is the whole definition. Everything else written about the topic is detail on three parts: the agents, the environment they share, and the coordination between them.

Before I call a system multi-agent, I check it against four properties:

1. Autonomy. Each agent picks its next action itself. A step that runs because a script reached line 40 is a function call, not an agent.
2. A local view. No agent sees everything. When one process has complete information and total control, that is a single agent with subroutines.
3. A shared environment. Actions happen somewhere the other agents can see: a codebase, a market, a warehouse floor, a shared record of facts.
4. Distributed control. Decisions get made in more than one place. A coordinator can exist, but it hands work out. It does not decide every move.

The term is much older than today's AI products. Multi-agent research goes back to 1980s distributed AI: negotiation protocols, auction mechanisms, robot teams. What changed is the agent itself. Large language models, or LLMs, made one capable agent cheap to build. Decades of coordination theory then became practical engineering in a few years. Google Cloud's glossary entry on multi-agent systems describes the same shift. The modern agent gets its reasoning from an LLM. The modern system gets its structure from an orchestration design somebody chose, rather than from free-form message passing.

multi-agent versus single-agent

A single-agent system is one entity with one context and one decision loop. A chess engine, a fraud detector, the coding assistant in an editor. For a narrow task with one clear owner, that design is simpler, cheaper, and easier to test. It is the right default.

A multi-agent system splits the same work across roles. The gain comes from that structure. Each agent in a team is no smarter than the single agent it replaces. A team gives you four things one agent cannot:

• Specialization. Each agent carries only the instructions and tools its role needs, so it spends no context on jobs it will never do.
• Independent review. A separate reviewer catches what the author cannot, because it does not share the author's assumptions.
• Parallelism. Independent subtasks run at the same time instead of waiting in one queue.
• Failure isolation. One agent failing does not automatically kill the whole run.

You pay for those four things. More tokens, more latency, and a class of coordination bugs that a single agent can never produce. Deciding when a team is worth that cost is a subject of its own. So is the question of which run patterns hold up. I wrote both up in multi-agent systems in practice. This page stays on the definition.

the components of a multi-agent system

The textbook says a multi-agent system has three parts. Running one in production convinced me it has five.

The three every glossary lists:

• Agents. The decision-making entities. Each has a role, a set of tools, a model that does its reasoning, and some freedom to act. An agent can be software, a robot, or a person. In current systems it is usually an LLM with a role and a set of tools.
• Environment. The shared space where the work happens. It can be physical, like a warehouse floor. It can also be virtual: a repository, a ticket tracker, and a server the agents work on. The environment is an indirect way to communicate. One agent changes it, another notices.
• Communication and coordination. The rules for how agents exchange information and settle who does what. Academic work standardized agent message languages such as FIPA ACL, a formal format for agent-to-agent messages. Current systems mostly pass structured messages under an orchestration layer that decides who runs, in what order, and with which inputs. How that layer works is its own subject, covered in AI agent orchestration.

The two that production adds:

• Shared state that outlives a run. Agents hand work to each other across hours or days. Without a durable, shared record of decisions and facts, every handoff loses context and the agents argue the same points again.
• An oversight layer. Agents acting on real accounts need permission limits and checkpoints where a person signs off. Academic definitions skip this. A simulated agent cannot spend money or push code to the main branch. A real one can.

what multi-agent systems are used for

In every serious use case the work splits into separate roles, and those roles hand work to each other.

• Software delivery. One agent writes the spec, another builds, another reviews the diff, another fixes the bugs the reviewer found. This is the domain I work in every day. It maps onto agent roles well, because human software teams already worked out where the role boundaries go.
• Customer operations. One agent triages the request. One pulls the relevant account and documentation. One drafts the response, and one decides whether a person needs to see it first.
• Logistics and supply chains. Agents representing suppliers, warehouses, and carriers negotiate stock levels and routing as conditions change.
• Trading and market simulation. Specialized agents watch different markets and risk limits. Large populations of agents also model behavior that no single equation describes.
• Robotics. Fleets of warehouse robots that coordinate paths and task claims are the oldest working example. They came long before LLMs.

where multi-agent systems break

The failure modes define multi-agent systems as much as the benefits do. A definition that leaves them out is incomplete.

• Coordination overhead. More agents means more messages, and a badly shaped team spends more tokens talking than working.
• Context loss at handoffs. Agent B does not know what agent A silently assumed. Errors build up quietly across steps.
• Emergent behavior. The interactions produce results nobody designed. There are too many paths through the system to test them all in advance.
• Debugging opacity. Tracing a bad output back through six agents and forty tool calls is painful. You need run-level visibility built in from the start.
• Cost. Every agent turn is model inference. A team that hands out work carelessly multiplies the bill along with the output.
• Security surface. Every agent with credentials is a place where a bad instruction or a compromised input can act on real systems.

None of these are reasons to avoid multi-agent systems. They are reasons to put your engineering effort into the coordination layer. That is where these failures happen.

the three ways to build one

The options sort into three tiers. Which tier is right depends on how much of the system you want to own.

1. Code-first frameworks. LangGraph, CrewAI, AutoGen and similar tools give you graph and role building blocks. The orchestration logic, the state, the deployment, and the debugging are yours. Most control, most upkeep. I compare the options in AI agent frameworks.
2. Cloud agent stacks. The big cloud providers, Google Cloud's agent tooling among them, host the models, the messaging, and the servers. They manage the infrastructure. You still do the system design.
3. Managed agent teams. Platforms where the agents, the coordination, the shared state, and the oversight layer are already built. Your work is hiring roles and drawing the structure, rather than writing orchestration code. This is the tier aldena sits in.

Whatever the tier, the design sequence is the same. Define the goal. Split it into roles. Pick the architecture. Give each role its tools. Decide where a person signs off. Then run it somewhere you can watch it.

how the five components map onto aldena

aldena is the definition above shipped as a product, so it works as a concrete example.

The environment is a room. A room is an isolated workspace. It has its own server, its own credentials, and its own connected integrations. The agents in one project can reach nothing outside it.

The agents come from a roster of prebuilt roles, analyst to reviewer to bug fixer. Each one runs on whatever model you pick for it.

Coordination is an org chart you draw on a canvas. An agent can hand work only to its direct reports, and report only to its own manager. The chart is the routing table, and it is also the architecture diagram. There are hard limits on how far work can spread. An agent can hand out only a few pieces of work per turn, and a chain can only run so deep before it stops.

The shared state is agent memory. It has two layers: a shared pool that every agent in the room can read, and a private set for each agent. Both outlive the conversation that wrote them.

The oversight layer is human in the loop. Every tool runs under an allow, ask, or deny policy. A run pauses on the exact call it wants to make until a person answers. Finished work also leaves the room through a gate. Code lands as an open pull request in GitHub or Bitbucket. Merging is a gated tool, and the role that opened the request is told to leave it for you. Backlogs reach Jira or Linear only after an explicit go-ahead. Documents go to Google Drive.

I arrived at this design by running agents against real repositories and real accounts. That is when the three parts the textbook names started to matter. The two parts it forgets started to matter at the same time.

the test to keep

When someone asks whether a thing is a multi-agent system, ignore the marketing and count the places a decision gets made. One place means a single agent, no matter how many prompts you stack on it. Several places sharing one environment, with results flowing between them, means a multi-agent system. The four properties at the top of this page are the checklist. The definition fits in one sentence. Making one work takes everything else on this page.