A2A Protocol Explained: How Agents Talk to Other Agents

A recent Hacker News thread asked a deceptively simple question — is anyone actually using the A2A protocol? — and drew dozens of replies. That's a useful signal: agent and platform engineers know agent-to-agent interoperability is coming, but many are still orienting on what A2A actually is and where it fits. This guide answers that, with the mechanics grounded in the official A2A specification rather than secondhand discussion.

If you're building agents that will eventually need to call, delegate to, or collaborate with agents you didn't write, this is the layer that makes that possible without every team inventing its own bespoke handshake.

What is the A2A (agent-to-agent) protocol?

A2A — Agent2Agent — is "an open standard designed to facilitate communication and interoperability between independent, potentially opaque AI agent systems." The key word is opaque: A2A lets agents built on different frameworks discover each other's capabilities, agree on how to interact, and collaborate on tasks without exposing their internal state, tools, or implementation to one another.

Under the hood, the spec defines a single canonical data model (expressed in Protocol Buffers) with three interchangeable transport bindings — JSON-RPC 2.0, gRPC, and HTTP+JSON/REST — that the spec describes as offering "functional equivalence." In practice, you pick the binding that fits your stack and still speak the same protocol as everyone else.

A handful of core objects do the work:

Agent Card — metadata an A2A server publishes describing its "identity, capabilities, skills, service endpoint, and authentication requirements." It's how one agent learns what another can do before talking to it.
Task — "the fundamental unit of work managed by A2A, identified by a unique ID," with an explicit lifecycle (submitted, working, input-required, completed, failed, canceled, and so on).
Message and Part — a Message is "one unit of communication" with a role (user or agent), built from Parts; a Part is "a container for a section of communication content," which can be text, file bytes, a URL, or structured data.
Artifact — output the agent generates, "composed of Parts," tracked separately from the conversation history.

What problem does A2A solve?

The agent ecosystem is fragmenting fast. Teams build agents on different frameworks, in different languages, behind different APIs. The moment you want two of them to work together, you're back to writing custom point-to-point glue for every pair — and re-writing it whenever either side changes. That's the integration tax A2A is designed to remove.

Why agents need an interop standard

Tool-calling standards already let a single agent use external tools. But an agent is not a tool. As the protocol's own documentation puts it, tools have "well-defined, structured inputs and outputs," whereas agents "reason, plan, use multiple tools, maintain state over longer interactions." Coordinating with something that plans and holds state needs more than a function call: you need a shared way to advertise capabilities, kick off and track long-running work, stream partial results, and exchange rich content. That's exactly the surface A2A standardizes — so an agent can collaborate with one it has never seen, as long as both speak A2A.

A2A vs MCP — how are they different?

This is the question most builders trip on, and the official docs answer it directly. They're complementary, not competing:

MCP (Model Context Protocol) "defines how an AI agent interacts with and utilizes individual tools and resources, such as a database or an API." It's the agent-to-tool layer.
A2A "focuses on enabling different agents to collaborate with one another to achieve a common goal." It's the agent-to-agent layer.

The documentation frames them as two halves of the same system: "An agentic application might primarily use A2A to communicate with other agents. Each individual agent internally uses MCP to interact with its specific tools and resources." Put plainly: MCP is about agents using capabilities; A2A is about agents partnering on tasks. You'll likely use both — MCP to wire each agent to its tools, A2A to let those agents work together.

Is anyone actually using A2A?

The honest, source-grounded answer: A2A is an open standard with a published specification and open-source implementations, and there's visibly active developer interest — the Hacker News thread that prompted this article is itself evidence that builders are evaluating it in the open. What we won't do here is hand you a fabricated list of production adopters or version-by-version adoption stats; the credible signal today is a real, maintained spec plus genuine community demand, which is the right stage to learn the protocol rather than wait. If you need a current adopter list, check the official project directly rather than trusting any single blog's snapshot.

How do you start building with A2A?

You don't need to implement the protocol from scratch. A practical on-ramp:

Read the spec's core objects first. Understand Agent Card, Task, Message/Part, and Artifact — they're the whole mental model. The specification is the authoritative reference.
Decide which side(s) you're building. An A2A server publishes an Agent Card and executes tasks; an A2A client discovers servers and sends work. Many systems are both.
Pick a transport binding — JSON-RPC, gRPC, or HTTP+JSON/REST — based on your stack; they're functionally equivalent.
Choose your interaction mode. The spec supports synchronous request/response, streaming (Server-Sent Events over HTTP, or gRPC streams) for real-time updates, and push notifications (webhooks) for long-running, server-to-server work. Note that streaming and push notifications are optional capabilities an agent advertises in its Agent Card — clients should check support before relying on them.
Model your work as Tasks, not chat turns. A2A's task lifecycle is what makes long-running, recoverable collaboration possible; design around it from the start.

Takeaways for agent and platform engineers

A2A is the agent-to-agent interoperability layer — an open standard for independent, "potentially opaque" agents to discover capabilities and collaborate without sharing internals.
It's complementary to MCP, not a competitor. MCP connects an agent to its tools; A2A connects agents to each other. Most real systems use both.
The core model is small: Agent Card, Task, Message/Part, Artifact. Learn those four and the rest follows.
Capabilities like streaming and push notifications are optional — advertise and check them via the Agent Card rather than assuming.
The demand is real and the spec is live — a good moment to prototype against it rather than wait for the dust to settle.

As multi-agent systems move from demos to production, interoperability stops being a nice-to-have and becomes the thing that decides whether your agents can participate in a larger ecosystem at all. A2A is the current best answer to that question.

Building multi-agent systems and want to ship them faster? Try Clawvard, and follow our updates for ongoing agent-infrastructure and protocol coverage.