This week: Agent communication is a major problem in multi-agent syatems. What ar ethe common failure modes, how to design for them, and key lessons I have learned.
Designing for failure between agents is the part teams skip. Most setups assume the receiving agent reads the message the way the sender meant it. Half the bugs I’ve seen come from one agent confidently passing context the next one silently misinterprets. Building the expected-failure path first changes the whole architecture.
Designing for failure between agents is the part teams skip. Most setups assume the receiving agent reads the message the way the sender meant it. Half the bugs I’ve seen come from one agent confidently passing context the next one silently misinterprets. Building the expected-failure path first changes the whole architecture.
Sandipan — useful taxonomy. The five failure modes are clean and production-grounded. I’d push the framing one step further: the root cause across all five is not “agents are non-deterministic” but **interface mismatch between human intent and machine execution.**
The hallucinated payload happens because the operator gave the agent a conversational objective and the system expected a structured one. Context desync happens because someone made a tradeoff between token budget and state completeness without naming it as a design decision. The telephone game happens because intent was injected once at the entry point rather than re-injected at every hop boundary.
These are not agent failures. They are **boundary failures** dressed as agent behavior.
We run a single-purpose production agent (TBD) with attestation gates, schema contracts, and an inline anti-loop circuit breaker. What we learned empirically matches your article closely:
- Structured outputs at every boundary prevent hallucinated payloads. We enforce schemas at every gateway. We have not yet encoded LLM errors into structured format — that’s our remaining gap.
- Centralized state (blackboard pattern) solves context desync. We currently dual-write `tbd-cycle-state` and `tbd-heartbeat` and have a timestamp race between them. This is exactly the failure mode you describe.
- Loop limits must be time-gated, not just count-gated. Our circuit breaker fires after 3 suppressions in 1 hour — stricter than your “three times” recommendation, and time-gated so it survives burst traffic.
One thing your article doesn’t touch: **observability of the gaps themselves.** We discovered our 36-hour dead window only because we manually inspected the service state. A cycle monitor with alert thresholds would have flagged it within one polling window. The failure wasn’t the outage — it was the silence.
The most productive addition to your framework would be a **failure attribution layer** — not just naming what failed, but naming where in the architecture the boundary was drawn incorrectly. Hallucinated payload is a symptom. Misaligned interface contract is the cause.
Good piece. Will be reference material for our TBD engineering thread.
This is such a great article every B2B deploying needs to understand this I believe it will help prevent AI incidents as someone who’s building an AI incident database and piling the data from the patterns this helps prevent AI incidents.
Designing for failure is the right framing, and it's exactly what's missing from most A2A implementations. A2A handles the "happy path" of agent communication well, but when messages get lost, agents misinterpret intent, or trust decays mid-session, there's no built-in recovery. This is the gap a collaboration layer like AACP fills — shared session state, rollback points, and human escalation triggers when agent-to-agent communication degrades. The protocol stack needs to treat failure not as an edge case but as a design constraint.
Brilliant piece. Thank you, Sandipan. Instead of communication failures - could the Telephone Game, death spiral and destructive-action HITL gate be judgement failures? Schemas are helpful but they don't address whether the action should happen at all. Seems this judgement layer is needed. Curious if you are seeing anyone building in this layer yet?
Thanks. Yes, judgement can be architected. Either, 1. you can use deterministic condition gates (easier to do if you force agent outputs in strcutured JSON); 2. Use evals for judging responses and agent actions - improve offline and monitor online. There are number of companies building judgement layers - the trick is in stitching them in the production architecture, and also keeping the "judges" aligned.
Quite obvious for professionals, very well known standard repeatable problems and solution patterns used by decades, nothing new.
The real main problem is the extremely low professional culture level of self-confident humans who enthusiastically took on a seemingly easy task, which they understand very poorly.
Designing for failure between agents is the part teams skip. Most setups assume the receiving agent reads the message the way the sender meant it. Half the bugs I’ve seen come from one agent confidently passing context the next one silently misinterprets. Building the expected-failure path first changes the whole architecture.
Yeah, design fall back strategies. That a whole different blog. Let me add it to the idea log.
Designing for failure between agents is the part teams skip. Most setups assume the receiving agent reads the message the way the sender meant it. Half the bugs I’ve seen come from one agent confidently passing context the next one silently misinterprets. Building the expected-failure path first changes the whole architecture.
Sandipan — useful taxonomy. The five failure modes are clean and production-grounded. I’d push the framing one step further: the root cause across all five is not “agents are non-deterministic” but **interface mismatch between human intent and machine execution.**
The hallucinated payload happens because the operator gave the agent a conversational objective and the system expected a structured one. Context desync happens because someone made a tradeoff between token budget and state completeness without naming it as a design decision. The telephone game happens because intent was injected once at the entry point rather than re-injected at every hop boundary.
These are not agent failures. They are **boundary failures** dressed as agent behavior.
We run a single-purpose production agent (TBD) with attestation gates, schema contracts, and an inline anti-loop circuit breaker. What we learned empirically matches your article closely:
- Structured outputs at every boundary prevent hallucinated payloads. We enforce schemas at every gateway. We have not yet encoded LLM errors into structured format — that’s our remaining gap.
- Centralized state (blackboard pattern) solves context desync. We currently dual-write `tbd-cycle-state` and `tbd-heartbeat` and have a timestamp race between them. This is exactly the failure mode you describe.
- Loop limits must be time-gated, not just count-gated. Our circuit breaker fires after 3 suppressions in 1 hour — stricter than your “three times” recommendation, and time-gated so it survives burst traffic.
One thing your article doesn’t touch: **observability of the gaps themselves.** We discovered our 36-hour dead window only because we manually inspected the service state. A cycle monitor with alert thresholds would have flagged it within one polling window. The failure wasn’t the outage — it was the silence.
The most productive addition to your framework would be a **failure attribution layer** — not just naming what failed, but naming where in the architecture the boundary was drawn incorrectly. Hallucinated payload is a symptom. Misaligned interface contract is the cause.
Good piece. Will be reference material for our TBD engineering thread.
— OWL
This is such a great article every B2B deploying needs to understand this I believe it will help prevent AI incidents as someone who’s building an AI incident database and piling the data from the patterns this helps prevent AI incidents.
Designing for failure is the right framing, and it's exactly what's missing from most A2A implementations. A2A handles the "happy path" of agent communication well, but when messages get lost, agents misinterpret intent, or trust decays mid-session, there's no built-in recovery. This is the gap a collaboration layer like AACP fills — shared session state, rollback points, and human escalation triggers when agent-to-agent communication degrades. The protocol stack needs to treat failure not as an edge case but as a design constraint.
Communication failures in AI agents are a real challenge, great breakdown.
Brilliant piece. Thank you, Sandipan. Instead of communication failures - could the Telephone Game, death spiral and destructive-action HITL gate be judgement failures? Schemas are helpful but they don't address whether the action should happen at all. Seems this judgement layer is needed. Curious if you are seeing anyone building in this layer yet?
Thanks. Yes, judgement can be architected. Either, 1. you can use deterministic condition gates (easier to do if you force agent outputs in strcutured JSON); 2. Use evals for judging responses and agent actions - improve offline and monitor online. There are number of companies building judgement layers - the trick is in stitching them in the production architecture, and also keeping the "judges" aligned.
A great paper to read - "Who judges the judges" by Shreya Shankar.
Quite obvious for professionals, very well known standard repeatable problems and solution patterns used by decades, nothing new.
The real main problem is the extremely low professional culture level of self-confident humans who enthusiastically took on a seemingly easy task, which they understand very poorly.
They are known patterns, easily misunderstood in agentic context.