What Is A2A? The Agent2Agent Protocol Explained
A2A (Agent2Agent) is an open protocol for agent-to-agent communication. It lets independent AI agents discover each other, delegate tasks, and exchange results securely, regardless of which framework or vendor built them.
It was introduced by Google in April 2025, contributed to the Linux Foundation, and has reached a stable 1.0 release. It runs on HTTP with JSON-RPC 2.0, Server-Sent Events for streaming, and OAuth 2.0 for authentication.
The one-line version: A2A is to AI agents what HTTP is to web services — a common protocol that lets independent systems interoperate without custom integration for every connection.
The problem: agents that can't talk
You have probably built or used an AI agent that does one job well. A customer-service agent answers questions. A research agent gathers sources. A scheduling agent books meetings. Each is capable on its own — and each is trapped inside its own platform.
The research agent cannot tell the writing agent that the research is done. The support agent cannot hand a refund off to the billing agent. Agents have been smart individually and mute collectively.
The reason is simple: there has been no shared language. Every agent framework invented its own way of representing tasks, messages, and results. Connecting two agents built on different frameworks meant writing custom glue code for every pair — a brittle integration that broke whenever either side changed.
Multiply that across a dozen agents from a dozen teams and the integration burden grows quadratically. The agents are not the bottleneck; the connections between them are.
The lesson from the web
We have solved this shape of problem before. The web did not scale because every server spoke a private dialect — it scaled because HTTP gave every server and client a common, framework-agnostic contract. You can put any browser in front of any web server because both agree on the protocol, not the implementation.
A2A applies the same idea to agents: a thin, shared protocol so an agent built on any framework can talk to an agent built on any other, without either revealing its internals.
A2A is to AI agents what HTTP is to web services.
What the protocol standardizes
At its core, A2A defines how one agent (the client) asks another agent (the remote agent) to do work, and how results flow back. It standardizes four things every collaboration needs:
- Discovery — how an agent advertises who it is and what it can do, so others can find and evaluate it.
- Task delegation — how a client submits a unit of work and how its progress is tracked to completion.
- Communication — how the two agents exchange messages and structured results during the work.
- Security — how agents authenticate to each other and authorize access without sharing credentials.
Built on boring, proven standards
A2A is deliberately unglamorous under the hood, and that is a feature. It reuses the same battle-tested web standards that already run the internet:
- HTTP(S) for transport
- JSON-RPC 2.0 for structured requests
- Server-Sent Events for streaming updates
- OAuth 2.0 + JSON Web Tokens for authentication
Nothing exotic. Any engineer who has built a web service already knows the primitives, which is exactly why adoption has been fast. You can inspect an A2A call with the same tools you use for any web API.
The five building blocks
Almost everything in A2A is assembled from five concepts:
1. The Agent Card
A JSON document describing an agent: identity, endpoint, authentication, and — most importantly — what it can do, as a list of skills. By convention it lives at a well-known path:
curl https://agent.example.com/.well-known/agent-card.json2. The Task
The central unit of work. When a client asks a remote agent to do something, that request becomes a Task with its own identifier and a lifecycle you can track from start to finish. Tasks are stateful: they can run for a long time and stream updates.
3. The Message
A single communication turn between the client and the remote agent — a request, a reply, a clarifying question.
4. The Parts
Typed content inside a Message: a text part for prose, a file part for documents or images, a data part for structured payloads. This typing is what lets agents exchange more than plain strings.
5. The Artifact
A durable output the remote agent produces as a result of a Task. Where Messages are the conversation, Artifacts are the deliverables.
A2A is not a framework
This is the misunderstanding worth clearing early. A2A does not replace LangGraph, CrewAI, or whatever agent framework you already use. It sits between agents as a messaging layer, so agents built with different frameworks can still cooperate.
You keep your stack. A2A connects it to everyone else's. Adoption means giving an existing agent an Agent Card and an A2A endpoint — its internals stay exactly as they are.
Where MCP fits
If you know the Model Context Protocol, the cleanest way to place A2A is alongside it. MCP connects an agent to tools, data, and context — it answers "how does my agent use a resource?" A2A connects an agent to other agents — it answers "how does my agent work with another agent?"
They are complementary, not competing, and both are now governed under the same foundation. Most serious systems use both: MCP to give each agent its capabilities, A2A to let those agents collaborate.
MCP gives an agent hands.
A2A gives it colleagues.
Why A2A is a safe bet
A2A reached v1.0 with core data models frozen — the fundamentals will not shift under you. New capability arrives as extensions rather than breaking changes to the base. It is governed by a neutral foundation rather than a single vendor, which removed the last reason for competitors to hold back.
And it is already infrastructure: official SDKs in five languages, support inside Microsoft Copilot Studio, Azure AI Foundry, Amazon Bedrock AgentCore, and Google ADK, and a large base of production deployments.