A2A (Agent2Agent Protocol)

What is A2A?

A2A, short for Agent2Agent, is an open standard that lets AI agents built by different teams and different vendors work together. One agent can ask another agent to do something, follow how the work is going, and get a result back, without either side having to know how the other one was built.

Google put the protocol together in 2025, with support from more than a hundred technology companies, and then handed governance over to the Linux Foundation. That was announced in June 2025, with AWS, Cisco, Google Cloud, Microsoft, SAP, Salesforce and ServiceNow among the companies backing the project. So this is not one vendor's house standard that you are betting your architecture on.

There is one design principle you should understand before anything else. Agents work together based on what they say they can do and on the information they exchange, and they never get access to each other's internal state, memory or tools. Your agent hands over a request and gets a result back. What happened in between stays behind the other agent's front door. That is deliberate, because it is what lets you work with an agent from a supplier without letting that supplier into your systems.

How two agents find each other

Every agent that speaks A2A publishes an Agent Card. The Agent Card is a JSON document that describes who the agent is, what skills it has, where its endpoint sits, and how you are supposed to authenticate. You can find that card at a well-known address on the agent's domain, in the same way that other web standards use a fixed path.

That sounds like a small detail, but it is the part that makes the whole thing work at scale. Because the card is machine-readable and always in the same place, your agent can discover what another agent can do without a developer first reading through a set of API documentation and writing an integration by hand.

The card also declares which security schemes the agent supports. The protocol allows for API keys, HTTP authentication, OAuth 2.0, OpenID Connect and mutual TLS. Your agent reads the card, authenticates the way the card says to, and the receiving agent then checks the credentials and limits what that client is allowed to reach.

What happens during a task

When your agent sends a message, the other agent creates a task. That task is the unit you follow, and it moves through a set of states that are defined in the specification.

It starts as submitted, which means the request has been accepted. It moves to working while the agent is busy. From there it can end up completed, failed, canceled or rejected, which are all final. It can also stop halfway and wait for you, either because it needs extra input or because it needs authentication first. That last group matters more than it looks. It is the protocol saying out loud that a long-running task can pause and ask a human or another system a question, instead of guessing and carrying on.

The content itself travels as messages, which contain one or more parts. A part can be text, a file as raw bytes, or structured data as JSON. At the end an artifact comes out, and that is also made up of parts. A generated document, an image or a structured result therefore all fit the same shape.

You can carry all of that over three different transports: JSON-RPC 2.0 for simple integrations, gRPC when you want performance between services, and plain HTTP with JSON for a REST-style setup. They all offer the same behaviour for the core operations, so you pick the one that fits your stack rather than one that changes what you can do.

For work that takes a while, there are two ways to keep up. Server-sent events give you a live connection where status and results stream in as they happen, which is what you want behind a user interface. Push notifications work the other way around: the agent posts to a webhook you registered whenever the task changes state, which is what you want for a job that runs for an hour and where nobody is watching a screen.

How A2A compares to MCP

These two get mentioned in the same breath constantly, and they solve different problems.

MCP connects a model to tools and data. It is how an agent gets the ability to query your database, read a file or call your API.

A2A connects an agent to another agent. It is how one agent delegates a piece of work to a second agent that has its own reasoning, its own tools and its own way of working.

You could ask why you would not just wrap the second agent as a tool and use MCP for everything. The A2A documentation answers that directly. Treating an agent as a simple tool is limiting, because a tool call is one request and one response. Agents need a conversation over several turns, where they can plan, ask a follow-up question, and delegate further themselves.

In practice you use both. Microsoft, for example, supports both protocols in its identity platform for agents, and Azure API Management can put a gateway in front of both MCP servers and A2A agent APIs. They are two layers of the same stack, not two options you choose between.

What to watch out for with A2A

You need this only when there really are two agents. If everything you build runs inside one platform, then a protocol for talking across vendors is overhead you do not need yet. Ask yourself whether a second party is genuinely running the other side.

Opaque agents are harder to debug. The very thing that makes A2A safe, not seeing inside the other agent, also means that when an answer is wrong you cannot look at how it was produced. Log the task, the message and the artifact on your own side, so you at least have your half of the conversation.

Authentication is your responsibility, not the protocol's. A2A describes which schemes exist and where to declare them. It does not decide which agent is allowed to call yours and what it may reach. That is a question about agent identity and access rules, and you have to answer it yourself.

A task that waits still costs you something. States like waiting for input or waiting for authentication are useful, but they mean tasks can sit around for a long time. Decide up front how long you keep them and who gets a reminder.