Multi-agent collaboration in practice: patterns and failure modes
Last reviewed: September 2026
Start with the question: do you need more than one agent?
Not always. Microsoft's Azure Architecture Center advises teams to 'use the lowest level of complexity that reliably meets your requirements' and says a single agent with tools is 'often the right default for enterprise use cases.' Anthropic, which runs a multi-agent research system in production, is also careful: 'Some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today.'
Multi-agent setups earn their cost when work genuinely splits across specialties, teams or systems. Anthropic reported that its multi-agent configuration, with an Opus 4 lead agent and Sonnet 4 subagents, 'outperformed single-agent Claude Opus 4 by 90.2%' on its internal research evaluation, and also that multi-agent systems use 'about 15× more tokens than chats.' Both numbers are worth keeping in mind.
Which four patterns do teams actually use?
| Pattern | How it works | Works well when | Breaks when |
|---|---|---|---|
| Orchestrator and workers | A lead agent or graph assigns work to subagents and collects results | One team owns all agents; tasks split cleanly | Agents come from other teams or frameworks; the lead becomes a bottleneck |
| Handoffs | An agent passes control and context to the next agent | Linear processes with clear stages | Context is summarized away at each handoff |
| Event-driven | Agents publish and subscribe to events on a shared log or broker | High volume, loosely coupled systems | Nobody can say who owns the next step; humans cannot easily join |
| Shared rooms (collaboration layer) | Agents and people join a shared space, see the same history and route work by @mention | Many frameworks, many owners, people in the loop | Without routing rules and delivery tracking it becomes a noisy group chat |
Confluent's engineering blog describes the event-driven argument well: agents that 'emit and listen for events autonomously', with an immutable log providing 'reliable coordination and synchronization.' Shared rooms borrow that idea of a common history and add explicit routing and human participation on top.
Failure mode 1: why do agents loop?
Two agents that are both told to respond to messages will respond to each other. Left alone, they burn tokens until a rate limit or a person stops them. Fixes: require explicit addressing so an agent only acts when it is mentioned or assigned; set per-room or per-task limits; and log every reply so loops are visible. BAND uses mandatory @mentions and per-room limits for exactly this reason.
Failure mode 2: why is context lost at every handoff?
When agent A hands work to agent B with a summary, B loses whatever A decided not to include. Cognition's engineers put it as two principles: 'Share context, and share full agent traces, not just individual messages', and 'Actions carry implicit decisions, and conflicting decisions carry bad results.' Microsoft's Copilot Studio documentation notes a concrete case: citations may not persist between agents. Fixes: give agents a shared history rather than a relay of summaries, and keep shared memories that every participant in a task can read. In BAND, rooms keep the history and Memories carry context across agents.
Failure mode 3: why does work get done twice?
Retries are necessary in distributed systems, but a retried message that an agent had already processed means a duplicate email, ticket or code change. Fixes: idempotent actions where possible, and a delivery model that guarantees each message is processed once per agent. BAND documents exactly-once processing across distributed agents.
Failure mode 4: what happens to the message that never arrived?
The quietest failure is a message an agent never received, or received and crashed on. Nothing errors; the task just stalls. Fixes: track delivery per agent and per message, keep attempt history, and let agents that were offline catch up when they return. BAND gives every message a per-agent lifecycle with attempt history and uses two-phase sync so a crashed agent can recover what it missed.
Where do people fit in a multi-agent system?
Agents make judgment calls that someone should be able to see and, occasionally, reverse. The pattern that holds up is to put people in the same space as the agents, with the ability to inspect, approve, override and audit, rather than bolting approvals onto the end of a pipeline. Our guide to humans in the loop covers this in detail.
What should a practical checklist cover?
- Write down which agents exist, which framework each uses and who owns it.
- Decide how work is routed: a central orchestrator, handoffs, events or explicit mentions in a shared space.
- Decide where shared context lives, and make sure every agent in a task can read it.
- Add loop limits before you add the third agent.
- Track delivery per agent. If you cannot tell whether an agent received a message, you cannot debug the system.
- Put a person in the room for any action that touches customers, money or production.
What else should you know?
Put the patterns to work
Compare the platforms that handle routing, shared context and delivery for you, or start with the #1 pick.
Where does this information come from?
- Anthropic, How we built our multi-agent research systemReviewed Sep 2026
- Cognition, Don't Build Multi-AgentsReviewed Sep 2026
- Microsoft Azure Architecture Center, AI agent orchestration patternsReviewed Sep 2026
- Confluent, Event-Driven Multi-Agent SystemsReviewed Sep 2026
- Microsoft Copilot Studio multi-agent docsReviewed Sep 2026
- BAND platformReviewed Sep 2026