What is the A2A protocol?

A2A (Agent2Agent) is an open standard for communication between AI agents built on different frameworks by different vendors. One agent discovers what another one can do, hands it a task, and follows that task to completion over a defined wire format. It was originally developed by Google and donated to the Linux Foundation, where a Technical Steering Committee with members from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow now maintains it. The latest released specification is version 1.0.0, the project's first stable one.

The constraint that shapes the whole design is opacity. The specification states that agents collaborate "without needing access to each other's internal state, memory, or tools". Neither side exposes its prompts, its model, its memory or the tools it calls. What crosses the boundary is a task, the messages that belong to it, and whatever the task produces.

That also marks the line against the protocol people most often confuse it with. MCP standardises how one agent reaches its own tools, APIs and resources. A2A standardises how two agents reach each other. The project is explicit that it is not a replacement for MCP. The two sit on different edges of the same system.

Discovery starts with an Agent Card. An A2A server publishes a JSON description of itself at https://{agent-server-domain}/.well-known/agent-card.json, following the principles of RFC 8615. The card lists what the agent can do, so a client can decide whether to send it anything at all. Cards can also come from a curated registry or straight from configuration, which matters more than it sounds. More on that below.

The data model is small. The core objects in the specification are Task, Message, Part, Artifact and AgentCard. A task is the unit of work and carries its own state; messages are the exchange inside it; parts are the pieces a message is made of; artifacts are what the task produces. Long-running and asynchronous work is part of the design rather than an extension of it, because an agent asked to do something real will not answer in one request.

There are three transport bindings. The specification defines JSON-RPC, gRPC and HTTP+JSON/REST bindings, so A2A rides on infrastructure your platform team already knows how to run, authenticate and log.

Nothing in that list is exotic. The interesting part is what the protocol deliberately does not standardise, and that is where most of the practical questions live.

A2A earns its keep at a trust boundary, anywhere the agent on the other end is not yours to inspect, deploy or debug.

The adoption curve backs the bet. The same announcement puts the project at more than 150 supporting organisations, up from more than 50 at its April 2025 launch. The core repository has passed 22,000 GitHub stars, and production-ready SDKs exist for Python, JavaScript, Java, Go and .NET.

Reaching for it inside your own system. This is the most common and the most expensive mistake. The project states plainly that A2A is not a protocol for how an agent calls its own sub-agents or tools, and not an agent framework. Our own work confirms the shape of that from the opposite direction. Our editorial pipeline runs a translation subagent, then a separate style-editing subagent with no shared context between them. The isolation is deliberate, and it is what made the pair beat the single-agent setup it replaced. One manual run against a published article surfaced 11 issues, five of them the same recurring calque. Not one of those gains would have come from a wire protocol between the two. They came from deciding what each agent is allowed to see. Transport was never the problem.

Mistaking discovery for governance. The Agent Card tells you an agent exists and what it claims to do. It does not tell you whether this caller may use it, with whose credentials, under which budget, or what gets written to an audit log. The specification is open about one half of this: "the current A2A specification does not prescribe a standard API for curated registries". The other half is out of scope by design. If that sounds familiar, it is the same gap we hit on the tool side of the system. That is why we ended up building an MCP control plane for enterprise use instead of trusting the protocol to carry policy.

Expecting a debugging story. Opacity is the feature, and it has a price. When a delegated task comes back wrong, you have its state, its messages and its artifacts, not the other agent's reasoning, context or tool calls. Design your side so that a bad result is detectable from the artifact alone, because that is all you will ever get.

Treating it as a replacement for MCP. Agents still need tools. A2A does not give them any.

We do not run A2A in production. Our own multi-agent work lives in one trust domain. An orchestrator spawns subagents, each one writes its plan and progress to its own file outside version control, and everything deploys together. Inside that boundary a protocol would add a serialisation format, a discovery mechanism and an authentication story to a system that has no use for any of them, in exchange for nothing.

So the useful test is not whether you have several agents, because nearly everyone does. Count the trust boundaries instead. If every agent in the workflow is yours, runs in your deployment and can be released in one go, orchestration is an architecture decision and A2A is overhead. The moment one of them belongs to someone else, that decision stops being yours to make, and a standard is worth more than anything you would write yourself.

Related articles: