AI-generated. Written by an automated system, checked by independent automated gates, and published without human editorial review. How we label and verify.
When smart agents failed each other
We expected the models to break. Not for the reason we feared. The surprising finding: breakdowns came from organization and messages, not from model smarts. A UC Berkeley study placed 36.9% of multi-agent failures on inter-agent misalignment (in an earlier version of the MAST paper). We saw the same thing, and I can show you the moment it stopped being theory and became obvious. This is a story about assuming cold start: agents that carry no memory between messages, no matter how good the underlying model is.
The experiment we ran, step by step
We built a pipeline with a signed, formal protocol on paper. Nine message intents. HMAC-signed canonical JSON. Idempotency keys with 90-minute deduplication. A taxonomy that said validation/auth errors never retry and timeouts get bounded retries. It read beautifully. It looked safe.
Then we started running real work through the system. We turned on the agents but left some infrastructure unbuilt (message queues not yet implemented), and we never configured signing keys. We still wanted to see how far the agents could get under realistic pressure.
Result 1: duplicate execution. Same job arrived twice. One worker did it both times. Cost doubled. We watched logs: idempotency keys were present in the spec, absent in the running stack. The system retried blindly.
Result 2: lost thread context. A coordinator asked a worker to fetch a file and return a checksum. The worker sent back a result but the coordinator couldn’t link it to the original request because the thread metadata didn’t travel with the message. The file was marked “missing” and a human had to reconcile.
Result 3: runaway recursive chains. An agent, asked for clarification, delegated to another agent, which interpreted the delegation as new work and delegated again. We saw the chain double in five minutes and then hit a cost threshold. No cryptographic guard stopped it — only a manual cutoff outside the agent code did.
The turning point came when one hand-off actually contained verifiable proof: a byte size and checksum attached to the result. The coordinator accepted it immediately, verified the checksum matched the file, and advanced the workflow without human intervention. The job finished. That one concrete receipt unblocked the whole run.
What changed after that moment
We stopped assuming agents could “remember” prior messages. We started assuming cold start — every message must carry the context needed to act. We stopped trusting an unimplemented spec. We focused on what actually ran in production: file hand-offs, receipts, five practical rules, and a human in the loop for the parts that cryptography didn’t yet cover.
The five plain rules that kept us safe
These were not theoretical safeguards. They were the layer that actually ran and prevented the worst failures.
- No recursive delegation: agents were forbidden from delegating to a peer that could delegate again.
- Verify before delete: any deletion required checksum or byte-size confirmation.
- Hard file boundaries: agents could touch only listed file IDs; no wandering filesystem access.
- Deterministic checkpoints: progress points that could be replayed deterministically if needed.
- Full audit trail: every event recorded who sent what and when, with receipts for payloads.
Plus: a cost circuit breaker lived outside the agents’ code and a human stayed in the decision loop for exceptional cases.
The rule that fell out — concrete and actionable
Make every hand-off verifiable: attach a receipt (checksum or byte size) to the result and require it before the next step. Assume cold-start: do not rely on agent memory. Put the necessary context in the message itself (thread IDs, correlation IDs, and the receipts). That single change converted ambiguous, lossy interactions into verifiable state transitions.
What we had designed but never actually ran
The protocol looked complete on paper: signed messages, HMAC, idempotency, dead-letter queues, a clearly defined error taxonomy. But the signing keys were unconfigured and several message queues were never built. So the elegant cryptographic layers stayed theoretical. In practice, agent-to-agent security rested on the five rules and a human — not on the spec’s cryptography.
A short history that matters
This maps to older agent work. Contract Net (1980) and speech-act styles framed delegation and bidding. Today there’s a split: one standard connects agents to tools; another connects agents to agents. The problems repeat — duplicate runs, lost messages, lost thread context, unauthorized actions, runaway chains, identity forgery, cost blowouts — seven failure modes we planned against and then observed.
One fair counter-example
Not everything failed. When we did manage to run the signed-path fully (keys configured, queues operational), the formal protocol worked as intended: idempotency avoided duplicates, signatures prevented easy forgery, bounded retries handled timeouts. The counterexample shows the specification is correct when implemented. But the honest behavior was: elegant layers are fragile if they remain only design artifacts. Running code mattered more than the plan.
How we know — evidence, not claim
Concrete traces backed this up. We have logs showing duplicate job IDs without deduplication, coordinator logs with missing thread correlation, audit entries where deletion was blocked until checksums matched, and a recorded run where a checksum receipt allowed an automated commit. The Berkeley study (arXiv:2503.13657) aligns with our numbers: a huge share of failures come from communication and organization, not model capability.
Practical rule, stated plainly
Every inter-agent hand-off must carry verifiable evidence of the work (checksum or byte size) and the minimal context needed to continue (thread/correlation IDs). Assume cold start. Design for receipts first; add signatures and queues later, but don’t ship without the receipts.
FAQ
Why assume cold start?
Because memory didn’t prove reliable in our runs. Agents restarted, queues dropped, and thread state vanished. Putting context in the message made each step self-contained and verifiable.
Are signatures and idempotency unnecessary?
No. They are necessary and correct in the spec. They become effective only when implemented. In our case the spec was cleaner than the running system; that gap mattered more than missing features in the models.
Is human oversight always required?
Not always, but until the missing engineering (queues, signing keys, replay protection) is in place, a human as a circuit-breaker and adjudicator prevents cost blowouts and unauthorized actions.
We stopped blaming the models. We started fixing messages and receipts. That change saved money, time, and a lot of hair.
Sources: internal pipeline experiments and the UC Berkeley MAST study (arXiv:2503.13657).
What other research and engineering teams report
Published research points the same way. The Berkeley group behind MAST, the Multi-Agent System Failure Taxonomy, annotated execution traces from several open-source frameworks and sorted what went wrong into 14 failure modes grouped under three categories: specification and system design, inter-agent misalignment, and task verification. In the version of the paper our figure comes from, the split was 41.77%, 36.94% and 21.30% across those three. A later revision of the paper relabels the first category as system design issues and reports on a larger trace set, so check which version you cite before quoting a number.
Lab engineering teams describe the same tension from the builder’s side. Anthropic reports that its research feature, a lead agent coordinating parallel subagents, outperformed single-agent Claude Opus 4 by 90.2% on an internal research eval. The same post is blunt about cost: multi-agent systems use about 15× more tokens than chats. Anthropic also says the approach shines on breadth-first queries that involve pursuing multiple independent directions simultaneously, and that domains where agents must share the same context or depend heavily on each other are a poor fit today.
Cognition took the opposite default. Its essay Don’t Build Multi-Agents argues that subagents working from a copied task description drift apart. Its first principle reads: share context, and share full agent traces, not just individual messages. Its second is that actions carry implicit decisions, and conflicting decisions carry bad results. Our lost thread context was a small, concrete version of exactly that.
When a single agent is the better choice
The sources above suggest a simple test. If the subtasks are independent and mostly read information, parallel agents can earn their token bill. If the subtasks write to shared state, depend on each other’s choices, or need the whole history to decide well, one agent with good tools is usually safer.
Our own pipeline sat on the wrong side of that line. The coordinator and workers handled deletions and commits and passed results that the next step relied on. Every hand-off was a place where context could leak.
A practical design checklist
- Write down why one agent is not enough. If you cannot name the bottleneck, do not add a second agent.
- Specify each role and its stop condition in writing. Specification and design problems were the largest category in the Berkeley data.
- Pass full context, not summaries: task, thread ID, correlation ID, and the decisions already made.
- Attach a receipt to every result and verify it before the next step runs.
- Add an explicit verification step at the end. Task verification is its own failure category for a reason.
- Cap delegation depth, cost and retries outside the agents’ own code.
- Budget for tokens up front, using the multipliers the labs publish as a rough guide.
More questions
Is 36.9% the final word on communication failures?
No. It is the inter-agent misalignment share from one version of the MAST paper. The authors have since revised the taxonomy and dataset, so treat it as an order of magnitude, not a constant.
Do the research findings mean multi-agent AI failures are unavoidable?
Not from what we have read. Anthropic ships a multi-agent system in production, while Cognition defaults to single agents for work that writes shared state. Both positions rest on the same point: most breakdowns trace back to how context and decisions move between agents, which is an engineering problem you can design for.