In short
A multi-agent system is a software architecture in which several specialised AI agents work together on a task: a coordinating agent breaks the goal down into subtasks and delegates them to worker agents, each of which has a narrowly defined mandate, its own tools and its own context window. Instead of a generalist who is supposed to be able to do everything, the result is a team of specialists, with the same advantages and the same coordination problems that human teams know too.
The term itself is older than the current AI boom. Multi-agent systems have been a research field of distributed artificial intelligence in their own right since the 1980s. What is new is that the individual agents are now powered by large language models and can therefore take on tasks that cannot be cast into fixed rules in advance: research, classification, text work, decisions with context.
How a multi-agent system is structured
The pattern that has prevailed in practice is called orchestrator-worker (sometimes also the supervisor pattern or lead agent architecture). It cleanly separates two roles: planning and execution.
The orchestrator
The orchestrator is the project manager of the system. It receives the actual task, develops a strategy, breaks it down into subtasks and formulates a precise brief for each worker: goal, permitted tools, expected output format, limits. It then collects the results, evaluates them, identifies gaps and decides whether further work steps are needed or the overall result is complete.
The quality of the overall system depends disproportionately on this role. An orchestrator that hands out vague briefs ("do some research on the market") produces workers that duplicate work, contradict each other or come to nothing. A good orchestrator prompt describes delegation as precisely as a good manager does.
The worker agents
Each worker is an independent agent with a narrow mandate: a researcher, a data checker, a copywriter, a code reviewer. Three properties are decisive. First, each worker has its own context window: it only sees what is relevant to its subtask and is not distracted by the baggage of the overall project. Second, it has only the tools it needs: the agent that reads invoices cannot transfer money. Third, workers work in parallel where the subtasks are independent, which is one of the biggest performance levers of the pattern.
Communication and tool connection
For the agents to be able to work with real systems, they need standardised interfaces. The Model Context Protocol (MCP) has established itself as an open standard for connecting tools and data sources; CRM, ERP or merchandise management systems provide their functions as MCP servers, and every agent in the system can use them. For communication between agents from different vendors, the Agent2Agent protocol (A2A) was also presented in 2025; Google initiated it and handed it over to the Linux Foundation in the same year. Both standards address the same problem: agent systems should not be tied to one provider.
Multi-agent or single agent: when the set-up pays off
A multi-agent system is not an end in itself. For many tasks, a single agent, or a deterministic workflow with no agent at all, is the better choice. The differences at a glance:
| Criterion | Single agent | Multi-agent system |
|---|---|---|
| Suitable tasks | Clearly defined individual tasks with few steps | Complex, decomposable tasks with parallelisable substeps |
| Context window | One window for everything, which quickly fills with baggage | Each worker has a fresh, focused window |
| Error isolation | An early error runs through the whole run | Errors stay in the worker; the orchestrator can delegate again |
| Token costs | Around four times a chat interaction | Around fifteen times a chat interaction |
| Latency | Sequential, but a shorter overall chain | Parallelisation speeds things up; coordination costs time |
| Debugging | One trace, manageable | Several traces; hardly manageable without clean logging |
The token figures come from Anthropic's measurements on its own production system and mark the central trade-off: multi-agent systems buy their higher performance with considerably higher computing effort. They are therefore only worthwhile for tasks whose result justifies this effort: research across many sources, complex analyses, tasks with genuine parallelism. For a simple ticket classification, a multi-agent set-up is over-engineering.
A real-world example: Anthropic's research system
The best-documented productive multi-agent system comes from Anthropic itself. Claude's research function works with an orchestrator (lead agent) that breaks down a research query and sets several sub-agents to work on sub-questions in parallel; each sub-agent independently searches sources, evaluates results and reports back to the orchestrator. In Anthropic's internal benchmark, this set-up (Claude Opus 4 as orchestrator, Sonnet 4 workers) outperformed a single agent with the identical top model by 90.2 per cent. The engineering team disclosed the architecture, the prompt principles and the cost calculation in a detailed engineering report, including the sobering figure that multi-agent runs consume around fifteen times the tokens of a chat interaction.
What is interesting about the report is how many of the success factors have nothing to do with the model: precise delegation prompts, clear task boundaries per sub-agent, tool descriptions that a machine cannot misunderstand, and elaborate tracing for troubleshooting. This matches practical experience from corporate projects: the bottleneck is rarely the model's intelligence and almost always the quality of the division of labour.
Why this is relevant for mid-sized companies
For mid-sized companies, the pattern is interesting for two reasons. First, it lowers the risk of individual agents: because each worker has only limited rights and a narrow mandate, the damage from a run that goes wrong is limited, a central building block of guardrails in agent systems. Second, it mirrors the organisation that it automates: a company that can describe its processes in terms of roles and responsibilities can translate this description almost literally into an agent architecture.
Typical areas of use in which the set-up pays off today:
- Research and market monitoring: parallel evaluation of many sources followed by synthesis.
- Checking quotes and tenders: one agent extracts requirements, one checks feasibility, one calculates.
- Support triage: classification, knowledge research and a draft reply as separate, verifiable steps.
- Data reconciliation between systems: extraction, validation and a write proposal as separate agents with separate rights.
Common misconceptions
"More agents = more intelligence." No. More agents initially just mean more coordination effort and higher costs. The gain in performance comes from parallelism and focused contexts, and only for tasks that can be meaningfully broken down. A task that is sequential and simple does not get better with five agents; it just becomes five times as expensive.
"Multi-agent systems are autonomous swarms." In corporate reality they are the opposite: strictly hierarchically orchestrated systems with defined handover points, a permission concept and human-in-the-loop approvals for everything irreversible. Freely interacting swarms of agents are a research topic, not a production pattern.
"The framework makes the architecture." Tools such as LangGraph, CrewAI, the Microsoft Agent Framework (which emerged from AutoGen) or the OpenAI Agents SDK take care of the wiring: state management, retries, handovers. The actual architectural work, namely tailoring the mandates and defining the success criteria, remains with the team. A badly tailored system remains bad in any framework.
Limits and open problems
Multi-agent systems inherit all the weaknesses of their individual parts and add their own. Errors are cumulative: a worker that takes a wrong turn early on delivers plausible-sounding nonsense to the orchestrator, which seeps into the final result. Non-determinism makes testing harder: the same brief can take different paths. And the attack surface grows: every agent that reads external content is a potential gateway for prompt injection, and in a multi-agent system a compromised partial answer can infect other agents. Production readiness therefore means: complete tracing of every delegation, checkpoints for resuming, and evaluation with real test cases before every change.
Then there is the economic limit: the factor of fifteen in token consumption is not a cosmetic flaw but the price of the pattern. Anyone who ignores it builds systems whose unit costs eat up the benefit. The sober order is therefore: first deterministic workflows for everything rule-based, then a single agent with a narrow mandate, and only when its task is demonstrably too large for one context window, a multi-agent set-up.
Outlook
Standardisation is progressing rapidly: MCP for tool connection has been with the Linux Foundation since the end of 2025, as has A2A for agent-to-agent communication. A future is thus emerging in which agents from different vendors work together in one system, with one provider's orchestrator delegating to another's specialist agents. At the same time, forecasts such as Gartner's (more than 40 per cent of agentic AI projects will be cancelled by the end of 2027) show that the architecture alone is no guarantee of success. The companies that are gaining experience today with small, narrowly cut systems and documenting their processes properly will be able to use the standards; the others will be presenting slides.
Frequently asked questions about multi-agent systems
What is the difference between a multi-agent system and a workflow?
A workflow (for example in n8n) follows a fixed path laid out by people: same input, same process. In a multi-agent system, the agents themselves decide which steps and tools they use. This makes them suitable for tasks without a fixed process and unsuitable for anything that can be mapped deterministically.
When is a multi-agent system worthwhile instead of a single agent?
When the task can be broken down into independent subtasks that can be processed in parallel, or when a single context window is demonstrably too small for the task. As a rule of thumb: first a workflow, then a single agent, then multi-agent, and at each step check whether the added value justifies the multiplied token consumption.
Which frameworks exist for multi-agent systems?
Widely used are LangGraph (LangChain), CrewAI, the Microsoft Agent Framework (successor to AutoGen) and the OpenAI Agents SDK. For tool connection, the Model Context Protocol is the cross-vendor standard; for communication between agents, the A2A protocol. The choice of framework is less decisive than the clean tailoring of the agents' mandates.
How expensive is a multi-agent system to run?
Anthropic's measurements put token consumption at around fifteen times that of a normal chat interaction (single agents: around four times). On top of that come costs for monitoring, evaluation and maintenance. A multi-agent system therefore only pays off for tasks whose completion is worth considerably more than these operating costs.
Are multi-agent systems safer than single agents?
Partly. Splitting into workers with minimal rights limits the damage from individual runs that go wrong, which is a real security gain. At the same time, the attack surface for prompt injection grows with every agent that reads external content. Security does not come from the pattern itself but from the permission concept, approval processes and complete logging.