Multi-Agent Collaboration: Patterns for Getting Agents to Actually Work Together

Multi-agent collaboration works when agents share a governed store instead of passing messages to each other, because the pattern you choose decides who acts next while the channel underneath decides what they know when they act. In the largest published study of why these systems break, 1,642 annotated traces across seven frameworks, inter-agent misalignment accounts for 32.3% of all failures, and five of the fourteen failure modes appear in zero successful runs. Four of those five are failures of what one agent knew, and another did not.

This blog covers the four multi-agent collaboration patterns and the exact point each one gives out, the five properties a shared channel needs before any pattern holds, a walk through three Apache-2.0 reference fleets where no agent receives task state from an orchestrator, and the cost figure that decides whether you should be doing this in the first place.

What is multi-agent collaboration, and how is it different from orchestration?

At its core, multi-agent collaboration is several specialized agents contributing to one outcome, where the work of one agent changes what another agent should do. Orchestration is the routing layer that decides which agent runs when. They are different problems, and conflating them is why teams ship a working router on top of a multi-agent collaboration layer that still produces contradictory output.

A router can be correct while collaboration fails completely. The Performance agent runs, then the SEO agent runs, in exactly the order the graph specified, and the SEO agent still recommends an external schema library that the Performance agent banned two steps earlier. Nothing about the routing was wrong. The SEO agent simply never saw the ban.

Orchestration answers who goes next. Collaboration answers what the next agent knows. If you have already mapped the control patterns, our companion piece on coordinating specialized agents at enterprise scale covers the routing half. This one covers the other half.

Definitions used throughout:

• A fleet is a set of agents scoped to one shared memory namespace.
• Scope is the visibility boundary attached to a stored fact.
• Provenance is the record of which agent wrote it and when.
• A trust tier is the privilege level that decides which operations an agent may call.

Why does multi-agent collaboration fail in practice?

Agents lose state at the boundary between them. They do not, for the most part, reason badly. The MAST study out of UC Berkeley is the clearest evidence available: 1,642 execution traces, seven frameworks, six expert annotators, inter-annotator agreement of kappa = 0.88, and measured task failure rates running from 41% to 86.7% depending on the system.

In v3 of the paper, the fourteen failure modes cluster into three categories: system design at 44.2%, inter-agent misalignment at 32.3%, and task verification at 23.5%.

Of the fourteen MAST failure modes, five appear in no successful run of either ChatDev or MetaGPT.

The modes that are fatal rather than merely common

The headline percentages are less useful than a table buried in the appendix (Table 7 in v3). MAST reports per-mode occurrence rates split by whether the run succeeded or failed. Five modes register at 0.0% across successful ChatDev and MetaGPT runs while appearing in failed ones: information withholding, loss of conversation history, conversation reset, premature termination, and being unaware of termination conditions.

Read them as a group. Four of the five describe a fact that existed somewhere in the system and did not reach the agent that needed it. Not one describes an agent reasoning incorrectly about a fact it held. The authors put it plainly: certain failures “appear almost exclusively in failed runs,” and both examples they name sit in this set.

Why a better message format does not fix it

The obvious response is a stricter protocol. MAST tested that assumption against the data and rejected it. The failures they observed “occur even when agents within the same framework communicate using natural language,” and they attribute the cause to a collapse of theory of mind, where an agent fails to model what another agent needs to know. A schema tells you how to phrase a message. It does not tell you which message to send, and it does nothing at all for the message nobody thought to send.

The fix has to sit below the message layer, in something both agents can query rather than something one agent must remember to transmit. We wrote separately about the five ways agents share knowledge and why only one of them compounds.

What are the four multi-agent collaboration patterns, and where does each break?

Four multi-agent collaboration patterns cover almost every production fleet. Each is a real answer to a real problem, and each fails at a specific, predictable point.

The four multi-agent collaboration patterns and the single failure they share. Every break listed is an agent acting on state it could not see.

Sequential pipeline

Agents run in a fixed order, each constraining the next. Frontend decides layout, Performance sets budgets, SEO respects them. Cheap, legible, easy to debug.

It breaks at depth. Agent four inherits a summary of a summary of a summary, and by then the reason behind the original constraint is gone. Anthropic reports the same thing from production: in one experiment with agents split by software role (planner, implementer, tester, reviewer), the subagents spent more tokens on coordination than on actual work. They call it the telephone game, and it is the sequential pipeline’s defining flaw.

Orchestrator and workers

A lead agent plans and fans work out to specialists in parallel. It is the pattern behind most research systems, and it is genuinely good at breadth.

It breaks when the orchestrator becomes the only place memory lives. Every worker reports upward, the lead compresses, and the compressed version is the only survivor. Kill the lead’s context and the run is unrecoverable. Workers also cannot see each other, so two of them can research the same thing twice and neither will ever know.

Critic and verifier

One agent produces, a second checks. MAST’s own intervention study found that adding a high-level objective verification step to ChatDev raised task success by 15.6%, and tightening role specifications alone was worth 9.4%. Verification earns its place.

It breaks when the critic cannot cite what it judged against. A verifier that says “this looks fine” without naming the rule it checked is a rubber stamp with extra latency. MAST found existing verifiers frequently perform only surface checks such as confirming the code compiles.

Peer fleet

Agents work in parallel with no chain and no lead. Sales, Legal, Support, each on their own beat, all writing into the same organizational picture.

It breaks on simultaneous contradiction. Two agents commit to incompatible facts at the same moment and nothing arbitrates. That collision is the failure our post on what agent fleet memory actually is treats as the defining fleet problem, because it does not exist at all in single-agent systems.

What has to be true of the channel underneath every pattern?

Five properties. Miss any one and the multi-agent collaboration pattern above it degrades into the failure listed in the previous section.

Addressable: A fact written by any agent can be found later by any authorized agent, by meaning rather than by remembering the exact phrasing. Hybrid retrieval matters here because the recalling agent will paraphrase the query.

Scoped: Every fact carries a visibility boundary enforced before the search runs, not after. In Caura this is a WHERE fleet_id IN (...) predicate applied ahead of scoring, so out-of-scope rows are never loaded, never ranked, never returned. A prompt instruction to ignore data still retrieves the data.

Current: When the world changes, the old fact stops being returned. Caura moves memories through eight lifecycle statuses, and supersession is tracked through a supersedes_id foreign key rather than by deleting history.

Attributable: Every fact names the agent that wrote it and when. Without this a critic cannot cite, an auditor cannot trace, and a contradiction cannot be adjudicated because nobody knows which claim is newer.

Enforceable: Some rules are not suggestions. Caura’s keystones are mandatory rules merged across tenant, fleet, and agent scope, fetched at session start and obeyed over conflicting instructions. In the source, they carry fixed weight buckets and a hard cap of 50 rules, with an explicit truncation flag because silent truncation would hide a governance gap.

The practical consequence is a different handoff shape. Instead of agent two receiving agent one’s output, agent two queries the store for what is relevant to its own task. Agent one’s output does not have to be pre-compressed for a reader it cannot anticipate. We argued the case for making every write and baseline read deterministic rather than leaving either to model behavior.

What does multi-agent collaboration look like in running code?

Caura publishes three Apache-2.0 reference fleets that implement multi-agent collaboration end to end. Reading all three together produced the finding that surprised us most.

Across the three fleets there are eleven agents (five in the build fleet and three in each of the other two), and no agent receives another agent’s output from an orchestrator. In the five-agent build fleet, the pipeline loop invokes each step as module.run() with no arguments, and the shared agent loop exposes no parameter for a prior agent’s output. Results are collected for reporting and never fed forward. In the long-run fleet, simulate.py sends each agent a fixed daily prompt and reads the Sourcing agent’s reply only to find which memory to poll, never to brief Synthesis. The cross-fleet agents have no orchestrator at all and run step by step from the README. In all three, the only channel between agents is the store.

The build fleet: constraint propagation

Five agents produce a landing page. The Performance agent recalls what Frontend decided, then writes a rule forbidding external JavaScript. The SEO agent recalls that rule and picks inline JSON-LD instead of a CDN schema library. Code Review recalls everything, runs contradiction detection, and issues a verdict citing specific memory IDs.

The Manager agent is the part worth copying. It never receives the write tool in its allowlist, so read-only isolation is enforced at the tool-schema level rather than requested in a prompt. At the end of a run it reports zero writes, which is a proof rather than a claim.

The long-run fleet: staying current over fourteen days

Three agents run daily for fourteen simulated days. A competitor’s price sits at $299 through day eight, then moves to $349. By day nine a naive vector store holds eight reinforced entries saying $299 and one saying $349, with nothing to arbitrate.

Caura queues contradiction detection on the write and marks all eight prior memories outdated once it completes. On day ten the Synthesis agent recalls one result. The eight stale entries are suppressed by lifecycle status, not by an instruction telling the agent to ignore them. The repo separates the write role from the verify role deliberately, on the reasoning that a single agent reading its own output has no external check on it.

The cross-fleet repo: boundaries that hold

Sales, Legal, and Admin share one backend across three fleet partitions. Sales writes a deal to fleet-sales. Legal asks about the same account and gets zero results, because the fleet predicate excludes it before the search executes. Admin reads across all three and surfaces the conflict between an active negotiation and a compliance hold.

One detail from that repo is worth stealing whatever stack you run: the 39-line governance skill sits byte-identical in all three agents’ workspaces, copied in from one source file by the setup script. Same recall protocol, same conflict-reporting rule, same escalation triggers. A shared contract that every agent loads at session start is the cheapest multi-agent collaboration primitive available, and almost nobody ships one.

The repo is also honest about its own limit. In the self-hosted build the boundary holds as long as an agent declares its fleet_ids truthfully. For isolation that cannot be bypassed at the prompt layer, you need separate tenants or the managed service.

Who is allowed to see whose work?

Most multi-agent collaboration writing skips this question, and it is where a fleet stops being a demo. Reading the trust thresholds declared across Caura’s twelve tools produces a clean split.

Seven tools declare trust_required=0: write, recall, doc, entity_get, tune, keystones, and manage. Every one of them is an agent acting on its own behalf. Storing what it decided, searching its own fleet, tuning its own retrieval, or fetching the rules it must obey.

Five declare trust_required=1 or higher: list, stats, insights, evolve, and keystones_set. Every one of them is an agent acting on the fleet. Enumerating what others wrote, aggregating across agents, hunting contradictions, reweighting someone else’s memory, setting policy others must follow. Cross-fleet reads require level 2. Deleting another agent’s work requires level 3.

Contributing is ungated. Auditing, overriding, and erasing are not: That is the design decision, and it is the right default for any fleet you intend to run in production. An agent should never need permission to add what it learned. It should absolutely need permission to overwrite what a peer learned.

A comment in the read-enforcement code makes the reasoning explicit. An earlier version gated the single-fleet case but not the multi-fleet list, so a low-trust agent could widen its own access by naming extra fleets. The fix note reads: asking for more must never be the way to be asked for less. That is the class of bug that governed collaboration exists to prevent.

If your fleet has no equivalent of this split, any agent can quietly rewrite the fleet’s shared understanding, and you will find out from the output rather than from an audit log.

What does multi-agent collaboration cost, and when should you skip it?

Between three and ten times the tokens of a single agent on the same task, by Anthropic’s own measurement. The overhead comes from duplicating context across agents, coordination messages, and summarizing results at each handoff. That is the price of admission to multi-agent collaboration.

That figure should stop some multi-agent collaboration projects before they start. Anthropic is direct that teams have spent months on multi-agent architectures only to find better prompting on one agent matched the result.

The decomposition rule that follows is the most useful thing in that post. Split by context boundary, not by problem type. An agent handling a feature should also handle its tests, because it already holds the context. Splitting planner, implementer, tester, and reviewer across four agents guarantees a lossy handoff at every seam.

Two of their three problematic boundaries deserve a direct answer, because they read as arguments against fleets: tightly coupled components, and work requiring shared state. The first stands. The second depends entirely on where the state lives. If shared state means agents forwarding context to each other, they are right and you should keep the work in one agent. If shared state means a store both agents query independently, the coupling cost mostly disappears.

Anthropic’s own research system does the second thing, writing artifacts to a filesystem so subagents return lightweight references instead of piping everything through the lead.

Notably, most of the token cost is coordination rather than reasoning. A store that lets agents recall a scoped set instead of carrying full history is how that curve flattens, which we covered in detail in the token tax of multi-agent systems.

Skip multi-agent collaboration entirely for fleets of two on sequential phases of one task, for anything a sharper prompt already handles, and for work where agents would need to synchronize understanding constantly. Adopt multi-agent collaboration when research paths are independent, when components sit behind a clean interface, when verification can run blackbox, or when the work outlives a single context window.

What to do next?

Take your fleet’s worst recent output and find the multi-agent collaboration handoff where the information was lost. There will be one. Then answer three questions about your current channel: can agent four find what agent one decided, without agent one having anticipated the question; does anything mark a fact stale when the world changes; and can any agent silently overwrite what a peer wrote.

If the answer to the third is yes, fix that first. The other two are correctness problems. That one is a trust problem, and it compounds.

Caura is governed shared memory for AI agent fleets, open source under Apache 2.0, with scope, provenance, lifecycle, and trust tiers on every operation rather than bolted on afterward. A NASDAQ-listed fintech runs 300+ agents on one company brain with 26,500+ memories. The free tier covers 10,000 memories with unlimited agents and fleets, which is enough to reproduce every pattern in this article.

Frequently Asked Questions

What is the difference between multi-agent collaboration and multi-agent orchestration?

Orchestration decides which agent runs next. Multi-agent collaboration decides what that agent knows when it runs. A correctly ordered pipeline can still produce contradictory output if each agent acts on state it cannot see, which is why MAST finds inter-agent misalignment in 32.3% of observed failures despite frameworks having working routers.

Does MCP or A2A solve multi-agent collaboration?

No, and the MAST authors tested this directly. Message-format standards make agent communication consistent, but the failures they measured occur even when agents inside one framework talk in plain natural language. The gap is an agent failing to model what a peer needs to know, which no message schema addresses. Standards help the transport; the shared store handles the content.

How many agents do you need before shared memory is worth it?

Roughly the point where an agent needs a fact it did not produce and cannot receive in a prompt. For two agents in a fixed sequence, passing output directly is simpler and cheaper. The overhead pays for itself once you have parallel agents, agents running on different schedules, or a task spanning more sessions than one context window holds.

Can agents in a multi-agent collaboration setup see each other’s private data?

Only if you let them. In Caura, visibility scope is applied as a query predicate before search executes, so out-of-scope rows are never loaded or ranked. Per-row scope_agent restricts a memory to its writing agent, and cross-fleet reads require trust level 2. PII is detected at write time and quarantined before it can cross a fleet boundary.

What happens when two agents write contradictory facts?

The store detects the conflict and demotes the loser rather than storing both. Caura runs contradiction detection on write using RDF triple comparison plus model analysis, transitions superseded memories to outdated, and keeps the supersession chain traceable. Recall then returns the current fact by default, so the stale one is suppressed by status rather than by asking an agent to ignore it.

Is multi-agent collaboration more expensive than a single agent?

Yes, three to ten times the tokens on an equivalent task by Anthropic’s measurement, with most of it spent on coordination rather than reasoning. That is why decomposition should follow context boundaries: agents split by job title pay the tax at every handoff, while agents split by what they need to know pay it once.

Related reading: AI Agent Orchestration · How AI Agents Share Knowledge · What Is Agent Fleet Memory?