Inter-Agent Communication (A2A)

For a while in 2025, every team building a "multi-agent system" was really building one program with several prompts in it.

That works right up until the agents need to live in different places. Your procurement agent is a Python service your team owns. The vendor's pricing agent is a SaaS endpoint behind their API, built on a stack you'll never see. They need to collaborate on a purchase order. Now what? You can't import the vendor's agent as a function. There's no shared memory, no common framework, not even a guarantee they're written in the same language. They're two strangers who need to get work done, and until recently there was no agreed-upon way for them to even say hello.

That's the problem inter-agent communication solves, and in April 2025 Google shipped a protocol for it — Agent2Agent, A2A — with a pile of launch partners. By June it had been handed to the Linux Foundation as a vendor-neutral project, which is the part that made me take it seriously. A protocol owned by one cloud is a moat. A protocol owned by a foundation is plumbing.

A2A is not MCP, and the difference is the whole point

People conflate these immediately, so let's kill that now. They're complementary, operating at different layers.

MCP connects an agent to its tools — a database, a file system, an API. The agent is the boss; the tool is a resource it calls. Vertical relationship: agent on top, capability below.

A2A connects an agent to another agent — a peer, opaque, with its own reasoning and its own tools you can't see. Horizontal relationship: two autonomous systems negotiating as equals.

The clean way to hold it: MCP is how an agent uses a thing. A2A is how an agent talks to someone. Your procurement agent might use MCP to query its own inventory database, and use A2A to negotiate with the vendor's agent — same agent, both protocols, different jobs. One is reaching for a tool; the other is delegating to a stranger.

How two strangers start working

The mechanics are worth walking through, because the design choices encode what's actually hard about agents talking to agents.

It starts with discovery. Each A2A agent publishes an Agent Card — a small JSON document, conventionally at a well-known URL, that advertises who it is, what skills it offers, and how to authenticate. Before delegating anything, an agent fetches the card and learns: can you even do what I need? No card, no contract.

Then work happens as tasks, and this is the smart part. A task is a stateful, potentially long-running unit — not a request/response blip. Because real agent work isn't instant: negotiating a PO might take minutes, involve back-and-forth, need clarification. So a task has a lifecycle (submitted → working → input-required → completed), and the client agent can poll or stream updates as it progresses. The protocol assumes the work is slow and conversational, because between real agents it usually is.

Notice what the protocol does not assume. It doesn't assume the agents share a framework, a language, or a model. It doesn't crack open the vendor agent to see how it thinks. Each side stays a black box; they exchange cards, tasks, and artifacts (the outputs — a file, a structured result, a message). Opacity is a feature. The vendor can swap their model, rewrite their whole agent, and as long as the card and the task interface hold, your agent never notices. That's what interoperability actually requires: agreeing on the envelope and nothing about the contents.

What an Agent Card buys you

The card is the load-bearing idea, more than the message format. It's a contract you can read before committing. An agent decides whether to delegate based on advertised skills, authenticates per the card's scheme, and never has to know the implementation behind it.

It also makes the ecosystem composable in a way function calls never were. You can stand up a registry of agents, each with a card, and an orchestrator can discover which one to delegate a subtask to at runtime instead of being wired to specific endpoints at build time. That's the difference between "I hardcoded a call to the pricing service" and "I found an agent that advertises pricing and asked it" — the second one survives the pricing service being replaced.

The skepticism I'd keep

Now the cold water, because protocol launches always run hot.

A standard existing is not the same as the standard being the right call for you. Most systems that say "multi-agent" are one team's code, one deployment, one trust boundary. For that, A2A is overhead you don't need — function calls and shared state are simpler, faster, and easier to debug, and you should use them. A2A earns its complexity at exactly one boundary: when the agents are owned by different parties, deployed separately, and can't trust or import each other. Cross-organization, cross-vendor, cross-team-with-real-walls. Inside one trust boundary it's a protocol tax for a problem you don't have.

And the genuinely unsolved parts aren't in the spec yet, they're in the operations. When your agent delegates a task to a stranger's agent and gets a wrong answer, whose fault is it? How do you bound what you'll trust from a black box that could be having a bad day or could be adversarial? How do you stop a chain of delegating agents from laundering a prompt injection three hops down the line? The protocol gives them a way to talk. It does not give you a way to know the other one is honest, and that problem — trust between autonomous agents you don't control — is the one that'll define whether any of this works at scale.

A2A is real infrastructure and it solves a real coordination problem. Just make sure you actually have that problem before you pay for the solution. Most people, right now, don't.