"Agent-to-Agent Communication (A2A): When Agents Start Talking, the Message Deforms"
The real hard part of multi-agent collaboration isn't the division of labor — it's how they pass messages without distortion.
The target: you split the work cleanly, but the results won't fit back together
Many people assume the hard part of a multi-agent system is the *division of labor* — slicing one big task into chunks and handing each chunk to an Agent. But the place things actually fall apart is never the division of labor; it's how they pass the message clearly between each other.
Picture a perfectly ordinary scenario: a "research Agent" produces a set of user-research conclusions, hands them to a "writing Agent" to draft, which then hands off to a "review Agent" for a final check. All three Agents are individually smart, and each tests fine in isolation. But once you chain them together, three kinds of accidents keep recurring:
- Information distortion: The research Agent says "users drop off most at step 3, the form is probably too long," which in the writing Agent's mouth becomes "users hate filling out forms," and by the time it reaches the review Agent it's been "polished" into "the product experience is poor." Each hop drifts the semantics a little, and after three hops the conclusion no longer matches the original facts. This is communication distortion, the number-one killer in multi-agent systems.
- Results that won't reconcile: Have three Agents analyze the same batch of data in parallel — A says retention is 40%, B says 45%, C uses a different definition and says 30%. Who adjudicates? With no aggregation mechanism, the three results are just three drafts fighting each other.
- The Orchestrator becomes a single point of failure: You stand up a central coordinating Agent to handle coordination, and now every message passes through it. The moment it stalls, misunderstands, or blows its context window, the whole system grinds to a halt. Centralization solved coordination but manufactured a single point of failure.
The common root of all three is a question the other patterns in this course rarely answer head-on: when Agents need to talk to each other, how should that "talking" itself be designed. This is exactly what Agent-to-Agent communication (commonly abbreviated A2A in the industry) sets out to solve. It is not the same thing as single-Agent Tool Use: calling a tool is "I command a deterministic function and it dutifully returns"; A2A is "I entrust my intent to another Agent that thinks for itself, rewrites, and makes mistakes" — and the uncertainty of the latter is several times that of the former.
The framework: three layers of communication structure
Layer 1: Message passing (structured messages)
Agents can't get by passing raw text around. A line like "go handle that thing for me" can be filled in between humans by shared context, but between Agents it's a source of distortion. The first step toward reliable A2A is to structure the message, with at least four fields:
| Field | Purpose | What gets lost in raw text |
|---|---|---|
| sender | Who sent it — so you can trace problems back | You don't know which Agent gave you this conclusion |
| recipient | Who it's for — to avoid broadcast noise | Everyone receives it, and nobody is responsible |
| intent | Is this a request? An answer? A challenge? | A "I'm guessing" gets executed as "I've confirmed" |
| content | The actual payload, ideally with evidence sources | Only the conclusion travels, not the basis, so downstream can't double-check |
Intent is the easiest to overlook and the most critical. Passing "an unverified hypothesis" and "a confirmed fact" in the same format means downstream simply can't tell whether to take it at face value — and that's often where communication distortion begins.
Layer 2: Orchestration patterns (who directs whom)
Structured messages solve "how to say one sentence"; orchestration patterns solve "how a group of Agents coordinates as a whole":
| Orchestration pattern | How it works | Strengths | Risks | Fits |
|---|---|---|---|---|
| Orchestrator-Worker (central orchestration) | A central Agent assigns work, collects results, and makes decisions; Workers only do their assigned part | Clear accountability, easy to aggregate, easy to debug | The center is a single point of failure; context easily overflows | Tasks that decompose cleanly and need unified adjudication (the default for most production systems) |
| Peer-to-peer (negotiation among peers) | Agents talk directly, challenge each other, and negotiate a conclusion, with no center | Flexible, resistant to single points of failure, can produce emergence | Hard to converge, prone to infinite loops, a debugging nightmare | Open-ended exploration, debate-style problem solving |
| Blackboard (shared blackboard) | All Agents read from and write to the same shared space | Thoroughly decoupled, easy to add new Agents | The blackboard becomes a point of contention, consistency is hard to guarantee | Multiple experts contributing asynchronously, assembling a global picture |
These three aren't better-or-worse; they're fit-for-purpose. The vast majority of real-world systems use Orchestrator-Worker as the foundation (easy to aggregate, easy to debug) and apply Peer-to-peer or Blackboard locally in the sub-steps that need divergence.
Layer 3: The trend toward standardized protocols
The first two layers are matters internal to your own system. When Agents need to communicate across systems and across vendors, you need protocol standards: the Google A2A protocol defines how Agents discover each other, exchange structured messages, and negotiate tasks (solving "how does my Agent talk to your Agent"); MCP (Model Context Protocol) solves a different layer — how an Agent connects to tools and data sources. Remember it in one line: MCP governs Agent-to-tool, A2A governs Agent-to-Agent — complementary, not substitutes. The point of protocolization is that when the communication format is constrained by a standard, the room for "distortion" gets squeezed.
Three new kinds of cost: the price unique to multi-agent
Three accounts a single Agent never has to worry about come due the moment you go multi-agent. These three costs are the very same set discussed in Module B's "four stages of a multi-agent platform" — B speaks from the platform-evolution angle about "why a platform must digest them in stages," while this lecture speaks from the communication-protocol angle about "what they actually look like in the message stream." Same thing, two cross-sections.
| Cost | What it asks | What happens if you don't pay | Corresponding design action |
|---|---|---|---|
| Handoff cost | When a message goes from A to B, can the semantics stay undeformed | After multiple hops the conclusion drifts and the facts get rewritten | Structured messages + carry evidence sources + an intent field |
| Shared-context cost | Is the world state seen by several Agents consistent | Each computes its own, and the definitions clash | A shared blackboard / single source of truth, with clear write authority |
| Aggregation cost | How do you merge multiple results into one consistent one | Three drafts contradict each other and nobody adjudicates | The orchestrator owns arbitration and defines the merge rules |
Spread the three accounts out and they all point to the same core risk — communication distortion: handoff is single-hop distortion, sharing is out-of-sync-state distortion, aggregation is the distortion of multiple results that can't converge. Engineering-wise, well over half the effort in a multi-agent system essentially goes into suppressing these three forms of distortion.
Case: distortion and repair in a three-Agent research pipeline
Before the fix (raw-text handoff): The research Agent outputs natural language — "users drop off noticeably at step 3 of signup, possibly related to form length." For smoother prose the writing Agent rewrites it as "users broadly resent lengthy signup flows," and the review Agent reworks it further into "there are serious problems with the product's signup experience." In the final draft, that specific, actionable, well-located insight (step 3, form length, "probably") is all gone, leaving behind one correct platitude.
After the fix (structured messages + central orchestration + intent field): The research Agent outputs a structured message — sender: research-agent; intent: finding-hypothesis (explicitly tagged as a hypothesis); content: { phenomenon: "47% drop-off at step 3", conjecture: "the 12-field form is probably too long", evidence: "funnel data link" }. Because the writing Agent sees the intent is hypothesis, it cannot turn "probably" into "definitely", and preserves "the data shows the highest drop-off rate is at step 3, with a preliminary conjecture that it relates to form length." The review Agent no longer rewrites in a chain; instead it passes the draft together with the original message back to the Orchestrator, which makes a consistency ruling against the "evidence source." The key difference isn't which Agent is smarter, but: the intent field blocked the semantic upgrade, the evidence source gave downstream an anchor to re-check against, and central orchestration provided an adjudicator.
Actionable practices
- Don't rush into multi-agent. If a single Agent plus a few tools can do it, don't split. Only consider it when these signals appear: subtasks need different expertise / system prompts, parallelism is required to make the latency acceptable, or a single context window can't hold all the responsibilities. This is consistent with Module A's five layers, L5 — L5 is the highest layer of the foundation, built on the premise that the first four are all solid; it's not your opening move.
- Choose the orchestration pattern by "is adjudication needed." Need a unified, trustworthy, accountable conclusion → Orchestrator-Worker; need divergent exploration with no right answer → Peer-to-peer; multiple asynchronous experts adding bricks → Blackboard. When in doubt, Orchestrator-Worker (the easiest to debug).
- The anti-distortion trio, each mapping to one cost: prevent handoff distortion — always structure messages, mandate carrying intent and evidence sources, and forbid downstream from making unfounded semantic upgrades; prevent shared distortion — build a single source of truth, with clear write authority and whether writes need arbitration; prevent aggregation distortion — make the orchestrator own adjudication and define in advance "what rule to merge by when results conflict."
- Offload and add redundancy to the Orchestrator: it should handle only coordination and adjudication, delegating the heavy lifting to Workers; set a cap on its context, and when exceeded, summarize and batch it to avoid a central context explosion dragging down the whole system.
- Cross-system, prefer protocols over custom formats: a custom schema is fine for a small internal system; to interoperate with external Agents, prefer aligning on Google A2A, and use MCP for connecting to the tool layer.
Closing
A2A fills in a blind spot this course often skips: we spend a lot of pages on how an individual Agent thinks, uses tools, and plans, but rarely talk head-on about the line between two Agents. And it's precisely that line that decides whether a multi-agent system is "1+1>2" or "three smart people arguing into a mess."
A single Agent's ceiling depends on how smart it is; a group of Agents' ceiling depends on whether the messages between them travel without deforming. Division of labor is addition; communication is multiplication — and also division.