what is a multi-agent system?

the four properties that define one

A system qualifies when all four hold:

1. Autonomy. Each agent decides its own next action rather than executing a step someone else chose.
2. Local view. No agent has complete information about the whole system.
3. Shared environment. Their actions affect each other, through a codebase, a market, a physical floor, or a shared store of facts.
4. Decentralised control. There is no single process making every decision. A coordinator can exist, but it delegates rather than dictates every move.

Drop autonomy and you have a pipeline. Drop the shared environment and you have several unrelated agents. Both get marketed as multi-agent, and neither is.

how they coordinate

Three patterns cover almost everything built today:

• Hierarchical. A manager decomposes the goal and delegates to specialists, who may delegate further. Predictable, easy to debug, and the shape most business software lands on.
• Peer to peer. Agents negotiate directly, with contract-net style bidding for tasks. Flexible, harder to reason about.
• Blackboard. Agents read and write a shared store and pick up work when the state suits them. Loosely coupled, and easy to end up with two agents doing the same thing.

Most real systems are hierarchical with a shared store underneath, because that combination gives you delegation and shared context without the debugging cost of open negotiation.

why bother, and when not to

The case for several agents rather than one big one:

• Specialisation. A narrower prompt and tool set per agent means less context wasted on instructions it is not using.
• Independent review. A separate reviewer catches what the author cannot, because it is not working from the author's assumptions.
• Parallelism. Independent subtasks run at once.
• Isolation of failure. One agent going wrong does not necessarily take the whole run with it.

The case against, which is just as real: more tokens, more latency, and coordination bugs that do not exist with one agent. Agents lose context at handoffs, duplicate work, and deadlock waiting on each other. For a single well-specified task, one agent is cheaper and better, and choosing a team there is an expensive mistake.

how this works in aldena

Aldena is a hierarchical multi-agent system with a shared store, which is the combination above. You hire agents from eleven prebuilt roles into a room, then set who reports to whom in an org chart. Delegation runs down the reporting lines on its own rather than through orchestration code you wrote.

The handoff problem is handled by memory: every agent in a room reads up to 100 shared entries, so the reviewer knows the conventions the engineer was working to, and each agent keeps 50 private entries of its own working state.

Because it is a workplace rather than a log, you can watch the coordination happen live and stop it, which is the part that makes the failure modes above debuggable rather than mysterious. For worked examples, see what is an example of a multi-agent system.