Multi-agent systems: when several AIs work together

A multi-agent system gives a single mission to several specialised AI agents, coordinated by a conductor or by handoff rules. Done well, it covers more ground and holds up better on complex tasks; done badly, it multiplies both the bill and the errors, which is why you should understand its patterns before you pick a framework.

Why several agents rather than one

A single AI agent runs in a loop: it thinks, calls a tool, reads the result and starts again. That loop quickly hits its limits as the task grows. The context window fills up with intermediate results, the instructions turn into a catch-all and the model loses the thread.

A multi-agent system tackles this through division of labour. Each agent gets a narrow role, short instructions and only the tools it needs. Three benefits follow:

• Specialisation: a “research” agent and a “writing” agent do not need the same system prompt or the same tools.
• Parallelism: several sub-agents explore different leads at the same time, each in its own context.
• Cross-checking: one agent can review and critique another’s work.

Orchestration: who decides what

Orchestration describes how work flows between agents: who splits the task, who calls whom and who assembles the result. In its December 2024 guide “Building effective agents”, Anthropic first separates two families:

• workflows, where the path is written in advance by the developer;
• agents, where the model decides its own steps and tools.

Real multi-agent systems often mix the two. The same guide describes five recurring patterns, which show up under various names in every framework.

Pattern	How it works	When to use it
Chaining	Each step processes the previous step’s output	Linear task, split known in advance
Routing	A first call classifies the request and sends it to the right specialist	Mixed requests, such as customer support
Parallelisation	Several agents handle chunks or vote	Independent sub-tasks, need for several opinions
Orchestrator-workers	A central agent splits the work on the fly and delegates	Task whose sub-tasks are not known in advance
Evaluator-optimiser	One agent produces, another critiques, and the loop repeats	Clear quality criteria, iterations that help

The orchestrator-workers pattern sits at the heart of most multi-agent systems. It depends on good task decomposition: if the orchestrator splits badly, sub-agents duplicate work or leave gaps. The planning section of our article how an AI agent makes decisions explains this mechanism.

Check yourself You need to sort customer requests into three categories and answer each with a dedicated agent. Which pattern should you use?

Routing. A first call classifies the request (billing, technical, sales) and then sends it to the matching specialist agent. There is no need for an orchestrator to split the task on the fly, since the categories are known in advance.

Three concrete architectures

Beyond the patterns, three topologies dominate in practice.

The supervisor

A central agent receives the request, chooses which sub-agent to call, reads its answer and decides what comes next. This is the “supervisor” model documented by LangGraph and the architecture of Anthropic’s research system, where a lead agent launches sub-agents in parallel and then synthesises. The upside is a single point of control. The downside is that the orchestrator becomes a bottleneck and its own context window fills up.

The handoff

There is no permanent boss: one agent hands over to another when the conversation leaves its domain. The OpenAI Agents SDK calls these handoffs, and Microsoft Agent Framework offers an equivalent mode. This model suits conversational assistants where the user talks to one agent at a time.

The group chat

Several agents talk in a shared thread, with a mechanism that picks who speaks next. Popularised by AutoGen, whose research paper dates from August 2023, this model now lives on in Microsoft Agent Framework’s “group chat” mode. It is powerful for debate and critique, but harder to make predictable.

A step-by-step example

Imagine a competitive analysis: “Profile my company’s five main competitors and their offers.” With a supervisor, the run looks like this:

1. The orchestrator writes a plan and launches five sub-agents, one per competitor, with the same format instructions.
2. Each sub-agent searches, reads and summarises in its own context window, without seeing the others’ work.
3. The sub-agents send back a short summary, not every page they read.
4. An evaluator agent checks that each profile cites its sources and follows the format.
5. The orchestrator assembles everything and flags contradictions.

The gain comes from step 2: five searches in parallel, five clean contexts. The risk comes from step 3: if a summary leaves out a key fact, the orchestrator will never know.

The A2A protocol: getting agents from different vendors to talk

As long as all the agents live in the same program, the framework handles their communication. The problem changes when one company’s agent has to hand a task to an agent built by another company with a different tool. That is the job of the A2A protocol (Agent2Agent).

The key point is opacity: the remote agent stays a black box. You see what it can do and what it returns, not its prompt or its tools. A2A therefore complements MCP, which connects an agent to tools and data; our explainer on the Model Context Protocol covers that other half of the puzzle.

Multi-agent frameworks in 2026

You do not have to code everything yourself. The main open-source frameworks offer ready-made building blocks, each with its own philosophy:

• CrewAI thinks in role-based teams (Crews) for autonomy, and in Flows when you want to keep control of the sequence.
• LangGraph models the application as a graph of nodes, edges and state, with durable execution, memory and human approval.
• OpenAI Agents SDK, Swarm’s successor, is built on three ideas: agents, handoffs and guardrails.
• Google ADK combines sequential, parallel and loop agents with model-driven routing, and supports A2A.
• Microsoft Agent Framework, which succeeded AutoGen and Semantic Kernel and reached version 1.0 on 2 April 2026, offers graph workflows: sequential, parallel, handoff and group chat.

Tool	Type	License	MCP	Multi-agent	Level
CrewAI	Code	MIT	Yes	Yes	Intermediate
LangGraph	Code	MIT	Yes	Yes	Advanced
OpenAI Agents SDK	Code	MIT	Yes	Yes	Intermediate
Google Agent Development Kit (ADK)	Code	Apache-2.0	Yes	Yes	Intermediate
Microsoft Agent Framework	Code	MIT	Yes	Yes	Intermediate
CAMEL	Code	Apache-2.0	Yes	Yes	Advanced

To filter by language, licence or MCP support, use our framework comparison tool.

Pitfalls to know before you start

• Cost: each agent burns its own tokens, and the exchanges between agents add up. Measure before you roll it out.
• Error propagation: a sub-agent’s wrong assumption is picked up by the orchestrator, which presents it with confidence.
• Loops: two agents passing the ball back and forth with no stopping rule burn budget without progress. Set a maximum number of iterations.
• Coordination: poorly briefed sub-agents run the same search twice. Delegation instructions should state the goal, the output format and the limits.
• Evaluation: testing a multi-agent system means assessing both the final result and the intermediate steps. Our article on the limits of AI agents looks at these difficulties.

One simple rule acts as a safeguard: start with a single, well-equipped agent, and only split the work when you hit a specific limit (a saturated context, tasks that can run in parallel, the need for a reviewer).