what is a multi-agent system? definition and components

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.

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. The agent itself changed. Large language models, or LLMs, made one capable agent cheap to build, and decades of coordination theory became practical engineering in a few years. Google Cloud's glossary entry on multi-agent systems describes the same shift. It says an LLM now does each agent's reasoning, and that a modern system runs on orchestration, with an orchestrator or a predefined graph calling the agents in sequence.

multi-agent versus single-agent

A single-agent system is one entity with one context and one decision loop, such as a chess engine, a fraud detector or the coding assistant in an editor. For a narrow task with one clear owner, that design is simpler and cheaper to test. I start there by 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. A team burns more tokens, adds latency, and opens a class of coordination bugs that a single agent can never produce. I wrote up when a team is worth that cost, and which run patterns hold up, in multi-agent systems in practice.

the components of a multi-agent system

A multi-agent system has three fundamental elements in Google Cloud's glossary: agents, the environment and the interaction mechanisms between them. Running one in production convinced me it has five.

Google Cloud's three, in my own words:

• 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. Agent communication languages such as FIPA ACL and KQML, both named in Google Cloud's entry, gave agent-to-agent messages a formal format. Current systems pass structured messages under an orchestration layer that decides who runs, in what order, and with which inputs. AI agent orchestration is my write-up of how that layer breaks in production.

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. Google Cloud's three elements leave it out. A simulated agent never needed one, since it cannot spend money or push code to the main branch. A real one can.

what multi-agent systems are used for

Multi-agent systems fit work that already splits into separate roles handing work to each other, and I count five fields where that holds today.

• 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

Six failure modes come with every multi-agent system, as surely as the four benefits do.

• 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.

I still build with them. I put most of my engineering hours into the coordination layer, because that is where these six failures happen.

the three ways to build one

Every multi-agent system sits in one of three build tiers, and the right tier 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. You get the most control and carry the 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, and you still do the system design.
3. Managed agent teams. These platforms ship the agents, the coordination, the shared state and the oversight layer already built. Your work is hiring agents and drawing the structure, rather than writing orchestration code. Aldena sits in this tier.

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 ships all five components of a multi-agent system as product parts, which makes it a concrete example I can point at.

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

For agents, the roster has eleven prebuilt agents, each named for its job, with Requirements, Code Review and Bug Fix among them. Each one runs on the model you pick for it, with its own reasoning effort from low up to max.

Coordination runs through an org chart that you draw on a canvas, one line from each agent to its manager. 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. An agent can hand out at most 3 pieces of work per turn, and a chain of hand-offs stops at 10 deep.

The shared state is agent memory, in two layers. Project memory holds up to 100 entries that every agent in the project reads, and each agent keeps up to 50 entries of private memory that only it reads. Both outlive the conversation that wrote them.

Oversight is human in the loop. Every tool runs under an allow, ask, or deny policy, and a run pauses on the exact call it wants to make until a person answers. Finished work also leaves the project through a gate. The Delivery agent opens a pull request against the default branch and stops there, and no agent merges its own work. The Backlog Planning agent creates tickets in Jira or Linear only after an explicit go-ahead.

I arrived at this design by running agents against real repositories and real accounts. Agents, an environment and coordination got me a demo. Shared state and oversight were the two parts I had to add before I trusted the team with a real repository.

the test to keep

The quickest test for a multi-agent system is to count the places where a decision gets made, then hold each one to the four properties. 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. I run this count on every agent demo I watch, before I read its feature list.