Agent Communication

If one agent discovers an important fact but sends only “done,” the next agent cannot use the discovery. Communication means passing enough structured meaning for another agent to continue safely.

Agent A → message + task ID + evidence → Agent B → acknowledgement/result

What You Will Learn

• What information a useful agent message must contain.
• How direct messages, shared state, events, and protocols differ.
• How validation, identity, correlation IDs, and acknowledgements prevent confusion.

Module 2 gave agents distinct roles. A Planner, an Executor, a Critic — each with a clean scope. None of that matters if they can’t actually exchange what they’ve learned.

This module is about the mechanism underneath every multi-agent system this course covers from here forward: how does one agent’s output become another agent’s usable input?

That question sounds trivial. It isn’t.

---

Why this is a real engineering problem, not a detail

Inside a single agent, “communication” doesn’t exist as a separate concept. One reasoning process, one accumulating state — everything the agent knows is already in one place.

The moment you have two agents, you have a boundary. Information has to cross it. And crossing a boundary means answering real questions every single time:

• What format does the message take?
• How does the receiving agent know what the message actually means?
• What happens if the message is incomplete, ambiguous, or wrong?
• How does the sender know the message was received and understood?

None of these questions have a “just figure it out” answer. Every one of them is a real design decision, and getting it wrong is a common source of multi-agent failure — not a rare edge case.

---

The problem grows faster than the agent count

This is worth seeing precisely before anything else, because it explains almost every architectural choice covered later in this course.

If every agent needs to talk directly to every other agent, the number of possible communication paths doesn’t grow at the same rate as the number of agents. It grows quadratically.

2 agents  →  1 possible connection
3 agents  →  3 possible connections
5 agents  →  10 possible connections
10 agents →  45 possible connections

Ten agents, all potentially talking to each other directly, means 45 different relationships to design, secure, and debug. This is precisely why almost no real production system uses pure peer-to-peer communication once agent count grows past a handful — and precisely why patterns like the Supervisor pattern (covered in a later module) exist at all: routing every message through one coordinator turns that quadratic growth back into something linear.

Keep this number in mind. It’s the actual mathematical reason coordination architecture becomes unavoidable, not a stylistic preference.

---

The modes of agent communication

Agents don’t communicate in only one way. Each mode below has a real, different use case.

Structured messages. A defined schema — fields, types, required values — the same discipline you already know from tool calling in the previous course. Reliable, parseable, but requires every participating agent to agree on the schema in advance.

Natural language communication. One agent’s output, in plain text, becomes another agent’s input. Flexible and requires no shared schema — and harder to validate, because “did the receiving agent actually understand this correctly” has no clean, mechanical check.

Tool-mediated communication. Agents don’t talk to each other directly at all — they read and write to a shared resource (a database, a file, an API) that both can access. Communication happens as a side effect of using the same tool.

Shared-state communication. A common data structure — a blackboard, a shared context object — that multiple agents read from and write to. No message is ever explicitly “sent”; agents simply observe changes to shared state.

Event-based communication. An agent publishes that something happened; other agents subscribe to events they care about and react independently. No agent needs to know who’s listening.

Mode	Coupling	Best for
Structured messages	Tight — schema must be agreed in advance	High-stakes handoffs (Planner → Executor task assignment)
Natural language	Loose	flexible or open-ended handoffs
Tool-mediated	Loose	Agents that don’t need to know about each other at all
Shared state	Medium	Agents that need a common, evolving picture
Event-based	Loosest	Large numbers of agents, unpredictable participation

---

What a real message actually needs to contain

A usable agent-to-agent message isn’t just content. It needs enough structure for the receiving agent — and any system observing the exchange — to make sense of it without guessing.

At minimum:

• Sender identity — which agent (or role) produced this
• Recipient — who this is actually intended for
• Content — the actual information being passed
• Intent or type — is this a task assignment, a status update, a question, a result?
• Correlation ID — a shared identifier linking this message to the broader task it belongs to, so a later step can be traced back to what triggered it

That last field matters more than it looks. Without a correlation ID, tracing why an agent did something three steps later — exactly the observability discipline from your previous course — becomes difficult the moment more than one task is in flight at once.

---

A real, current protocol: Google’s A2A

This isn’t a hypothetical design pattern. It’s a real, adopted, actively-governed standard, and it’s worth knowing precisely because it answers nearly every question this module has raised so far, concretely.

Google launched the Agent2Agent (A2A) protocol in April 2025, with support from more than 50 technology partners at launch — Salesforce, SAP, ServiceNow, MongoDB, PayPal, Atlassian, and LangChain among them. In June 2025, Google transferred the protocol’s governance to the Linux Foundation, specifically to make it vendor-neutral rather than Google-controlled. (Google Developers Blog, Announcing A2A; Wikipedia, Agent2Agent)

By April 2026, A2A had reached a serious adoption milestone: more than 150 organizations, deep integration across AWS, Azure, and Google Cloud, and — this is the important distinction — real production deployments, not pilots, across supply chain, financial services, insurance, and IT operations. (Linux Foundation, A2A Surpasses 150 Organizations)

What A2A actually solves

A2A directly answers this module’s opening questions, with real technical mechanisms:

• Format — messages travel as JSON-RPC 2.0 over HTTP(S), a widely-adopted, well-understood standard rather than a proprietary format
• Discovery — every agent publishes an Agent Card, a metadata document describing its capabilities and how to reach it, so another agent can find and understand it without prior integration work
• Meaning — A2A defines a task lifecycle, not just a single message exchange — a client agent formulates a task, a remote agent works on it, and the protocol tracks status through to completion
• Trust — built-in OAuth 2.0 and JWT-based authentication, so agents can verify who they’re actually talking to

(GitHub, a2aproject/A2A; Security Threat Modeling for Emerging AI-Agent Protocols, arXiv)

By 2026, the protocol reached version 1.2, adding signed Agent Cards with cryptographic signatures for domain verification — a direct, structural answer to “how do you know this agent is actually who it claims to be.” (TheNextWeb, Google Cloud Next 2026)

The distinction worth knowing precisely: A2A vs. MCP

You may already recognize the name MCP — the Model Context Protocol — from earlier references in your learning path. It’s worth being precise about how it differs from A2A, because the two are frequently confused.

MCP connects an agent to tools and data. A2A connects an agent to another agent.

One research paper puts it cleanly: “While MCP focuses on the agent-to-tool relationship, A2A generalizes it to agent-to-agent collaboration.” A2A treats the other side of the conversation as an actor with its own capabilities — not a passive data source to query. (Beyond Message Passing, arXiv)

This course covers MCP itself, in depth, later in your learning path. For now, the distinction is what matters: tool access and agent communication are different problems, solved by different protocols.

The honest part: A2A wasn’t universally welcomed

Consistent with this course’s commitment to real trade-offs, not marketing — A2A’s first year wasn’t a clean success story.

A widely-read 2026 technical analysis describes the actual reaction: “Some developers saw A2A as the missing agent-to-agent layer for the emerging agentic stack. Others saw it as yet another Google protocol, another acronym, and another attempt to define a market before the market had real production needs.”

The skepticism centered on one direct question: “We already have MCP. Why do we need A2A?” — a fair question in 2025 that only became clearly answered as real production adoption accumulated through 2026. The same source’s honest verdict: “A2A is not dead. It is just not universal.” (Rost Glukhov, Google A2A Protocol in 2026)

That’s worth sitting with. A real, well-funded, widely-backed protocol still took over a year of skepticism before adoption numbers settled the argument. Don’t expect a new communication standard — in this course or in your own work — to be embraced immediately just because the technical design is sound.

What a concrete A2A exchange actually looks like

It helps to see this as a specific scenario rather than an abstract capability. Before A2A existed, a real integration problem looked like this: a Salesforce agent could not delegate a sub-task to a ServiceNow agent without custom glue code, and a Google Vertex agent couldn’t coordinate with an AWS Bedrock agent without a hand-built bridge — every vendor pair needed its own one-off integration. (Atlan, Google A2A Protocol)

With A2A in place, the same scenario becomes a standard exchange: a Salesforce CRM agent can route a support escalation directly to a ServiceNow ITSM agent, using the same protocol either side would use to talk to any other A2A-compliant agent — no custom bridge, no vendor-specific integration work. That’s the concrete, practical thing 150+ organizations actually adopted.

The honest limit: A2A doesn’t solve what agents disagree about

This is worth knowing precisely, because it’s a limitation, not a minor caveat.

A2A standardizes how agents communicate. It does not standardize what agents know. If a Salesforce agent and a SAP agent hold different internal definitions of “active customer” or “approved vendor,” they’ll produce contradictory outputs — even while communicating perfectly through A2A. The protocol guarantees the message arrives in a format the other agent can parse. It guarantees nothing about whether the two agents mean the same thing by the words inside that message. (Atlan, Google A2A Protocol)

This is precisely why message validation, covered next, has to check more than just “is this message well-formed.” A perfectly valid A2A message can still be built on a semantic disagreement the protocol itself has no way to catch.

A real, current disagreement about this exact problem

It’s worth closing the A2A discussion with a live industry split, current as of mid-2026, because it shows this module’s questions don’t have one settled answer even among major vendors.

Salesforce and ServiceNow took an open approach. Salesforce’s “Headless 360” architecture and ServiceNow’s “Action Fabric” both expose their platforms directly through APIs and MCP tools — any compliant agent, from any vendor, can invoke a deterministic action (start a flow, create a record, run a report) without being funneled through a single proprietary gateway. (Techzine, SAP blocks external AI agents)

SAP took the opposite position. In April 2026, SAP updated its API policy to explicitly restrict autonomous, non-deterministic agent access to its systems outside of endorsed pathways — meaning A2A specifically — with real enforcement: rate throttling, token revocation, and contractual review for organizations that don’t comply. SAP’s own Chief Customer Officer defended this as necessary governance for a multi-tenant platform; SAP’s CTO went further, publicly calling plain APIs “outdated technology” for agentic use cases. (Agents with SAP; Techzine)

Two major enterprise vendors, facing the identical underlying question — how much should we control agent-to-agent access to our platform — reached opposite conclusions, in the same industry, in the same year. Neither side has “won” as of this writing. That’s worth remembering the next time a vendor presents their specific communication architecture as the obviously correct one.

---

Why you can’t just trust an incoming message

This is worth flagging now, even though it gets full treatment in a later security module.

An agent receiving a message from another agent is, structurally, in the same position as an agent receiving content from a web page or a document — a topic your previous course covered in depth. The message came from inside the system, but that doesn’t make it automatically trustworthy.

• A compromised or malfunctioning agent can send a malformed or manipulative message
• A message can be technically well-formed but factually wrong — the sending agent could have made a reasoning error
• Without message validation, a receiving agent has no structural way to tell the difference between a trustworthy peer and an unreliable one

The same discipline your previous course taught for untrusted content applies here: a message from another agent is data to evaluate, not an instruction to blindly execute.

---

When you don’t need a formal protocol at all

Consistent with this course’s restraint principle from Module 1 — A2A-grade infrastructure is not the right answer for every multi-agent system.

Reach for shared-state or tool-mediated communication instead of a full message protocol when:

• All your agents run inside one system you control — you don’t need cross-organization interoperability
• The number of agents is small enough that the quadratic-growth problem hasn’t actually bitten you yet
• Latency matters more than flexibility — a shared database read is faster than a full request-response message cycle
• You’re not planning to let agents built by other teams or vendors ever participate

A2A earns its complexity specifically when agents need to work across organizational or platform boundaries — the exact problem its 150+ adopting organizations actually have. A single team’s internal three-agent pipeline usually doesn’t.

---

Applying this to a concrete scenario

It helps to see these communication modes chosen deliberately rather than defaulted into. Take the legal-contract review system from the previous module — Planner, Executor, Critic.

Planner → Executor. This handoff matters: the Executor needs to know exactly which policy area to check and which contract section to extract from. A vague natural-language instruction risks the Executor working from the wrong section entirely. This is exactly where structured messages earn their tighter coupling — a defined schema with policy_area, contract_section_id, and expected_output_format fields leaves far less room for the Executor to misinterpret the assignment.

Executor → Critic. The Critic needs the Executor’s actual comparison, plus enough context to judge it independently — but doesn’t need to know how the Executor arrived at its answer, only what it concluded. This is a reasonable case for a shared-state approach: the Executor writes its comparison to a shared record, and the Critic reads from that same record without a dedicated message ever being “sent.”

Critic → Planner (on rejection). If the Critic rejects a comparison, the Planner needs to know specifically enough to decide whether to re-run the Executor or escalate to a human. This is where the correlation ID from earlier in this module becomes load-bearing — without it, the Planner has no reliable way to connect a rejection back to the original checklist item it came from, especially once several items are being processed at once.

Notice that all three of these communications happen within a single system this team fully controls. None of them need A2A’s cross-organization guarantees. That’s precisely the restraint judgment from the section above, applied concretely rather than left abstract.

---

Interview-relevant framing

Q: Why does agent communication get harder as the number of agents grows? A strong answer names the actual mechanism:

Ans: If agents communicate peer-to-peer, the number of possible connections grows quadratically, not linearly — five agents means ten potential relationships, ten agents means forty-five. That’s the real, mathematical reason coordination patterns like a supervisor or an event bus exist: they turn that quadratic growth back into something linear by routing communication through a smaller number of paths.

Q: What’s the difference between MCP and A2A?

Ans: MCP standardizes how an agent connects to tools and data sources — agent-to-tool. A2A, Google’s protocol now governed by the Linux Foundation, standardizes how independent agents discover, authenticate with, and delegate tasks to each other — agent-to-agent. They’re complementary, not competing: a real system might use MCP for each agent’s tool access and A2A for how those agents coordinate with each other across organizational boundaries.

Q: How would you validate a message coming from another agent in your own system?

Ans: The same way I’d treat any untrusted input — I wouldn’t assume it’s correct just because it came from a peer agent rather than a user or a web page. At minimum, I’d check the message against its expected schema before acting on it, verify the sender identity where the communication mode supports it, and — for anything consequential — keep a human or automated check downstream rather than letting one agent’s claim propagate straight into an action.

Common Misconception

Incorrect idea: Agents can safely communicate by passing free-form text.

Why it is incorrect: Free-form text can omit identity, task, evidence, status, and expected format. Important handoffs need structured, validated messages.

Key takeaways

• Communication doesn’t exist inside a single agent — it becomes an engineering problem only once there’s a boundary between two reasoning processes.
• Peer-to-peer communication grows quadratically with agent count, not linearly — the real mathematical reason coordination architectures exist, covered in later modules.
• Agents communicate through several distinct modes — structured messages, natural language, tool-mediated, shared state, and event-based — each with different coupling and trade-offs.
• A real message needs sender, recipient, content, intent, and a correlation ID — the last one is what makes cross-agent tracing possible later.
• Google’s A2A protocol (April 2025, transferred to the Linux Foundation in June 2025) is a real, current answer to this entire module: JSON-RPC 2.0 messaging, Agent Cards for discovery, a task lifecycle, and OAuth-based trust — reaching 150+ organizations and real production use by April 2026.
• MCP handles agent-to-tool. A2A handles agent-to-agent. They’re complementary standards solving different problems.
• A2A faced real, public skepticism in its first year — a reminder that sound technical design doesn’t guarantee immediate adoption.
• A message from another agent is not automatically trustworthy just because it came from inside your system — the same untrusted-content discipline from your previous course applies here too.
• Formal protocols like A2A earn their complexity for cross-organization or cross-vendor systems. A small, internally-controlled agent team often doesn’t need one yet.

Module 4 goes deep on what happens once agents can actually talk to each other: coordination — who decides which agent acts when, how work gets allocated, and what happens when two agents’ outputs conflict.