Multi-Agent Systems

What is a multi-agent system?

A multi-agent system denotes an architecture in which several LLM-based agents work together to solve a task that a single agent cannot handle. Anthropic's own definition puts it concisely: "A multi-agent system consists of multiple agents (LLMs autonomously using tools in a loop) working together." The decisive point is the distinction: each agent has its own prompt, its own role, its own tool set, and – in the strict sense – its own context window.

This distinction is not academic in 2026. Vendor decks have diluted the term. A single agent with many tool integrations, marketed as "multi-agent" because the tools themselves are called "agents", is what one calls a marketing multi-agent. The prominently cited Klarna example ("AI does the work of 700 employees") is a single-agent deflection system in customer service – not a multi-agent system, even though it is often wrongly cited as one.

Genuine multi-agent exhibits at least one structural property: a lead/orchestrator agent that dynamically spawns sub-agents with their own context window; inter-agent messages that cross trust boundaries (such as Agentforce to SAP Joule via A2A); or a standalone process/role/model decomposition with non-trivial state sharing. Allianz Project Nemo, with its seven specialized agents, is a textbook example.

The honest reading in 2026: most productive "agents" are still a single, carefully constructed LLM with tools and a loop. That is not a defect – Anthropic itself stresses that the simplest pattern that solves the problem should win. The architectural question is therefore rarely "multi-agent yes/no", but rather "which pattern fits, and where does our state coupling lie?".

The orchestrator-worker pattern

The orchestrator-worker pattern (lead-sub-agent) is the canonical multi-agent case. A lead agent runs in extended-thinking or planning mode, decomposes the user request into discrete subtasks, and spawns sub-agents dynamically via a task tool. Each sub-agent has its own prompt, its own tool set, and – crucially – its own context window. The sub-agents return compressed results, which the lead synthesizes.

The reference case is the Anthropic Research Agent (Claude Research feature, June 2025): a lead built on Claude Opus 4, sub-agents built on Claude Sonnet 4. Anthropic's published internal evaluation showed +90.2% on research breadth versus the single-agent Opus 4 – at roughly 15× higher token cost (source: Anthropic, "How we built our multi-agent research system", 13.06.2025). Anthropic was explicit: this token expenditure pays off only for high-value, parallelizable, broadly scoped research tasks.

The pattern is deployed for broadly scoped, parallelizable problems with independent subtasks (research, market intelligence, multi-document review, broad triage). It should be avoided for tightly coupled write tasks (code generation across files) and for highly deterministic workflows that require reproducibility – a pipeline belongs there.

A central practical note from Anthropic's experiments: the lead must explicitly learn how to delegate. Each sub-agent needs a goal, an output format, source/tool guidance, and clear task boundaries. "Vague" delegations led to duplicated work and gaps in coverage.

Roles, handoffs, and coordination

Multi-agent systems thrive on clearly defined roles and clean handoffs. Beyond the pure orchestrator-worker structure, several coordination patterns exist that productive systems frequently combine:

The handoff semantics differ by stack. With the OpenAI Agents SDK, explicit handoffs end one agent's turn and start the next, with the conversation history passed along. AutoGen uses group chat with turn-taking. LangGraph passes a typed state object through nodes and checkpoints it durably. With the Anthropic Claude Agent SDK, the lead spawns sub-agents via the task tool, which return compressed, structured outputs.

In the hub-and-spoke model via A2A, a central agent delegates to specialized peer agents – potentially across vendors. The A2A protocol defines for this a task lifecycle (submitted → working → input-required → completed | failed | canceled), a capability discovery via the AgentCard (a JSON document with endpoint, capabilities, skills, modalities, auth schemes), as well as multipart messages with artifacts as the result. The internal logic of the remote agent remains opaque in the process – this allows a Salesforce agent to call an SAP agent without either exposing prompts, memory, or models to the other.

The coordination rule that has crystallized in 2026 concerns the write path: many agents read, gather, reason, propose – but only one agent (or one pipeline stage) commits. Multi-agent fan-out for reading is robust; fan-out for writing is fragile; concurrent write access to shared state is the death spiral.

Failures and compounding errors

Multi-agent systems have failure modes that a single-agent system does not know. Each of the following has been documented in production by Anthropic, Cognition, Sierra, Salesforce, or Microsoft – knowledge of this catalog is non-negotiable for any architect:

1. Cascading failures. A sub-agent hallucinates a fact; the lead synthesizes it into the answer; downstream agents act on the false fact. Countermeasure: verifier-judge agent, grounded retrieval, mandatory citations.
2. Echo chamber. Sub-agents reinforce a false premise from the lead. Countermeasure: diversify the sub-agents' models/prompts (MoA style), introduce a critic role.
3. Authority confusion. A sub-agent overrides lead instructions, or the lead loses authority over the conversation. Countermeasure: clear role hierarchies, A2A task contracts with strong AgentCards.
4. Resource deadlock. Agents wait on each other (A waits for B's result; B for A's clarification). Countermeasure: timeouts on every task, an explicit input-required state in A2A.
5. Prompt-injection amplification. Every sub-agent context window is a new attack surface. EchoLeak (CVE-2025-32711, Aim Labs, June 2025) was the first known zero-click prompt injection with concrete data exfiltration in a productive LLM system (Microsoft 365 Copilot). The same risk class scales linearly with the number of agents that ingest untrusted content.
6. Context fragmentation (Cognition's core critique). Sub-agents make incompatible implicit decisions. Countermeasure: share full traces where coupling is high; single-threaded writes; explicit decision contracts.
7. Cost explosion. The orchestrator-worker pattern consumes roughly 15× more tokens in the Anthropic Research Agent; this pays off only for high-value tasks. Countermeasure: token caps per sub-agent, QoS tiers, routing by complexity threshold.
8. Debuggability collapse. No single trace covers the run. Countermeasure: distributed tracing across the A2A mesh, correlation IDs passed through every A2A task and MCP call.

The conceptual core behind compounding errors comes from Cognition.ai's analysis "Don't Build Multi-Agents" (Walden Yan, 12.06.2025): actions carry implicit decisions, and conflicting decisions produce poor results. "Apparent disagreements" between agents are mostly symptoms of context fragmentation, not genuine dissent. In the April-2026 update ("Multi-Agents: What's Actually Working", 22.04.2026), Cognition clarified: multi-agent works when several agents contribute intelligence, but the writes remain single-threaded.

Synthesis for the architectural decision

If you place Anthropic and Cognition side by side and ignore the rhetoric, the synthesis is unambiguous:

• Multi-agent works on problems that are parallelizable, exhibit low state coupling between the subproblems, and whose write path is single-threaded or trivially reconcilable. Research, broad search, document fan-out, claims triage, fraud screening with independent checks all benefit.
• Multi-agent fails on tightly coupled, sequential problems in which every "implicit decision" shapes every later step. The clean example remains coding: a writer swarm of parallel coder agents produces a diff that no one can merge.
• For most enterprise workflows the answer lies in between – and the pattern choice matters more than the binary question.

The four sentences you can hold against any multi-agent pitch: share context where coupling is high; isolate context where parallelism dominates; never let two agents write to the same state simultaneously; pay 15× tokens only if the task is research-shaped.

DACH relevance and compliance notes

In the DACH region, structural variables come into play that US cloud reference architectures rarely address openly. The following notes are informational and not legal advice.

Data sovereignty. When different agents run on different compute providers – say a Salesforce agent that calls an SAP Joule agent, which uses an Anthropic Claude reasoning step via A2A – the data flow crosses multiple data-residency and data-processor boundaries on each task. Under the GDPR, every agent provider is potentially a data processor (Art. 28); multi-agent thus extends the data-processing-agreement chain. For cross-border US-EU steps, Art. 44–49 (standard contractual clauses, transfer impact assessment) apply on every agent hop that crosses a border. Sovereign-cloud options such as STACKIT (Schwarz Group), Open Telekom Cloud, IONOS, or plusserver are not optional for regulated multi-agent workloads. The A2A handshake to a non-sovereign agent is the most frequently overlooked compliance exposure in DACH multi-agent design.

Audit trail. Every agent-to-agent message is potentially audit-relevant. Reproducibility of multi-agent decisions is harder than for single-agent systems because of the non-determinism: pin model versions, record all sub-agent prompts, tool calls, retrieved contexts, and AgentCards used, and correlate them over a single trace ID. The Allianz Nemo design with a dedicated audit agent that produces a complete summary of all agent decisions is the DACH-relevant pattern here – auditability belongs in the agent topology, not just in the logging pipeline.

EU AI Act (high-level, informational, not legal advice). Open questions are not conclusively resolved in 2026: each agent is plausibly its own "AI system" (Art. 3(1)), and the composition is also an AI system – with a potentially higher risk classification than the parts. In a Salesforce-SAP-Anthropic A2A composition, each vendor is typically the provider of its own agent, while the integrating organization is the deployer of the composite system. Art. 50 transparency obligations multiply across agent calls.

Co-determination. Multi-agent workflows in HR, customer service, or operational monitoring can be subject to co-determination under BetrVG § 87 (1) no. 6 (Germany) or the ArbVG (Austria) – at the workflow level, not per individual agent. The 2026 trend is explicit AI works-council agreements that cover multi-agent compositions (informational, not legal advice).

Linguistic consistency. Multi-agent systems for DACH customers need a uniform tone of voice and a consistent Sie/Du register across all agents. A Salesforce agent that uses "Du" and calls an SAP agent with "Sie" produces a customer experience that reads as "broken". Style guides should be enforced at the AgentCard/prompt-template level.

Outlook and practical note

For DACH projects in 2026 the rational defaults are clear: single-agent + tools as the standard, promotion to multi-agent only if the task is parallelizable, read-heavy, or write-reconcilable and the cost factor adds up. MCP for tools, A2A for agents – anything else in 2026 is a deliberate departure from the converging stack. Treat every sub-agent context window as a new attack surface. Bake auditability into the topology (the Allianz audit agent as the blueprint). Choose one orchestration layer plus one platform-native – three or more frameworks in production are an unmanageable engineering surface. And publish AgentCards, because they are the cross-system contract that decides whether an agent participates in the enterprise ecosystem.

The question in the next architecture review is no longer "Should we build a multi-agent system?", but rather: "Which of the Anthropic patterns fits our workload, how high is our state-coupling tolerance, which vendor estates do we already operate, and where do MCP and A2A enter our governance perimeter?"