You have a single agent , or a small fixed set you fully control — internal calls are simpler. Your agents never cross an organizational or trust boundary , so vendor neutral discovery buys you little today.

The A2A Protocol Explained: How Agent-to-Agent Interoperability Actually Works

A recurring question keeps surfacing among practitioners: is anyone actually using the A2A protocol? A mid-June 2026 Ask HN thread put exactly that to the community — and the spread of answers, from production deployments to "we looked and walked away," is the clearest sign that agent-to-agent interoperability has moved from press release to real engineering decision. This is the A2A protocol explained for people who have to choose whether to adopt it: what it is, how it works under the hood, how it relates to MCP, and what the honest state of adoption looks like right now.

If your roadmap involves more than one agent — or agents you didn't build talking to agents you did — A2A is the standard most directly aimed at that problem.

What is the A2A protocol?

A2A (short for Agent2Agent) is an open protocol for letting independent AI agents discover each other, exchange tasks, and coordinate work — even when they're built by different teams, on different frameworks, by different vendors. Google announced it in April 2025 and transferred the specification and SDKs to the Linux Foundation in June 2025, which now governs the project as a vendor-neutral standard. By 2026 the protocol reached its v1.0 milestone with a published, stable specification.

The core idea is mundane in the best way: agents are network services, so give them a common way to advertise capabilities and pass work to one another. Instead of every multi-agent system inventing its own private glue, A2A defines the envelope — discovery, messaging, task lifecycle — and leaves the agent's internal reasoning untouched.

How does agent-to-agent interoperability work?

A2A is built on boring, well-understood web primitives, which is much of its appeal. Three pieces do most of the work.

Agent Cards: how agents discover each other

An Agent Card is a JSON document an agent publishes — by convention at /.well-known/agent-card.json — describing who it is, what skills it offers, what input and output it accepts, and how to authenticate. A client agent fetches the card to decide whether a remote agent can do what it needs. In the v1.0 line, Agent Cards can carry cryptographic signatures, so a calling agent can verify a card genuinely belongs to the agent it claims to, rather than trusting an unauthenticated JSON blob.

Think of the Agent Card as the agent equivalent of an OpenAPI description plus a business card: it's the machine-readable answer to "what can you do and how do I reach you?"

JSON-RPC and tasks: how agents pass work

Once an agent is discovered, A2A uses JSON-RPC 2.0 over HTTP, with Server-Sent Events for streaming, to send and track work. The unit of collaboration is a task: one agent submits a task, the other moves it through a lifecycle (submitted, working, input-required, completed, failed), and intermediate updates or artifacts stream back as they're produced. Because tasks are stateful and asynchronous, A2A handles the realistic case where a delegated job takes minutes, needs a follow-up question, or returns partial results — not just a single request/response round trip.

Messages carry typed parts — text, structured data, files — so agents can exchange more than plain strings. The v1.0 work also added multi-tenancy and multi-protocol bindings, aimed at the enterprise reality of many agents, many users, and more than one transport.

A2A vs MCP: what's the difference?

This is the comparison most readers actually came for, and the short answer is that A2A and MCP solve different layers and are designed to be used together — not as competitors.

MCP (Model Context Protocol) connects a single agent to its tools, data, and context — the "give my agent hands and memory" layer. It standardizes how a model calls a function, reads a resource, or loads a prompt.
A2A connects agents to other agents — the "let my agent delegate to your agent" layer. It standardizes discovery and task handoff between autonomous peers.

A useful mental model: MCP is how one agent reaches down to a tool; A2A is how one agent reaches across to a peer. Google framed A2A as complementary to MCP from day one, and most serious multi-agent stacks layer them — A2A for high-level orchestration between agents, MCP for low-level tool execution inside each one. If you've already invested in MCP-based tools (see our agent skills and MCP scaffolds guide), A2A sits above that work rather than replacing it.

Is the A2A protocol worth adopting yet?

Here's the honest read in mid-2026. On the "yes" side: A2A is no longer a single-vendor project — it's Linux Foundation–governed, has a stable v1.0 spec, and by April 2026 counted more than 150 organizations participating in the ecosystem. That's real institutional weight, and it's the kind of neutrality that makes a protocol safe to build on.

On the "it depends" side: the same practitioner threads that prove demand also surface friction — teams that only have one agent get little from an inter-agent protocol, early integrations expose rough edges in auth and long-running task semantics, and some organizations conclude a simpler internal RPC is enough until they actually need cross-vendor reach. Adoption interest is clearly real; universal production deployment is not yet the default.

When A2A earns its place

A2A is most worth it when at least one of these is true:

You need agents from different vendors or teams to interoperate without a custom integration for each pair.
You're building an open ecosystem where third parties bring their own agents.
You're running enough agents that a standard discovery-and-delegation layer beats N-squared bespoke connectors — the scaling problem we cover in multi-agent systems at scale.

When you can wait

You have a single agent, or a small fixed set you fully control — internal calls are simpler.
Your agents never cross an organizational or trust boundary, so vendor-neutral discovery buys you little today.

Frequently asked questions

Who maintains the A2A protocol?

The Linux Foundation has governed A2A since June 2025, after Google contributed the specification and SDKs. It's developed as an open, vendor-neutral standard rather than a single company's product.

Does A2A replace MCP?

No. MCP connects an agent to its tools and data; A2A connects agents to other agents. They operate at different layers and are commonly used together.

What transport does A2A use?

HTTP with JSON-RPC 2.0 for requests and Server-Sent Events for streaming updates, plus Agent Cards for capability discovery.

Is A2A production-ready in 2026?

The spec reached v1.0 and has broad institutional backing, but real-world adoption is uneven — strong where cross-vendor interoperability matters, optional where a single team controls every agent.

Takeaways for Clawvard readers

A2A is the interoperability layer, not another tool protocol: it standardizes how independent agents discover and delegate to each other via Agent Cards and JSON-RPC tasks.
A2A and MCP are complementary. Use MCP to give an agent tools; use A2A to let agents collaborate. Most mature stacks run both.
Adoption is real but selective. The 2026 evidence points to genuine demand and serious governance, with the highest payoff for cross-vendor and open-ecosystem scenarios — and limited upside if you control every agent yourself.
Decide by trust boundary. If your agents cross teams or vendors, A2A is worth piloting now; if they don't, you can adopt when that day comes.

If you're designing systems where more than one agent has to cooperate, keep going with our deep dive on multi-agent systems at scale, or see how tool-level standards fit in via the agent skills and MCP scaffolds guide. And if you'd rather coordinate agents without hand-rolling the plumbing, that's exactly what Clawvard is built for.