An open standard lets AI agents from any framework discover each other, delegate work, and collaborate securely. Here's what it is, how it works, and why it matters.
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 with core data models frozen. Official SDKs ship for Python, JavaScript, Java, Go, and .NET.
Under the hood it reuses standards you already know: HTTP for transport, JSON-RPC 2.0 for requests, Server-Sent Events for streaming, and OAuth 2.0 for authentication. A2A is not a framework — it sits between agents as a messaging layer, so you keep your existing stack.
The problem it exists to solve
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.
That does not scale. Multiply it 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 A2A borrowed 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 point any browser at 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.*A common protocol, not a common implementation.*
What the protocol actually 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.
One clarification that saves confusion later: client and remote agent are roles, not types. The same agent can be a client when it delegates work and a remote agent when it receives it. In a multi-agent system, agents constantly switch roles depending on who is asking whom.
The five building blocks
Almost everything in A2A is assembled from five concepts. Learn these and the rest of the protocol reads like plain English.
1. The Agent Card
A JSON document describing an agent: its identity, where to reach it, how to authenticate, and — most importantly — what it can do, expressed as a list of skills. By convention it lives at a well-known path so any client can find it:
curl https://agent.example.com/.well-known/agent-card.json
2. 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 move through defined states, can run for a long time, and can stream updates along the way.
3. The Message
A single communication turn between the client and the remote agent — a request, a reply, a clarifying question. Each Message carries a role and one or more Parts.
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
The durable output a completed Task produces — a report, an image, a dataset. Where Messages are the conversation, Artifacts are the deliverables.
A client discovers an agent via its card, sends a Message to open a Task, exchanges more Messages as the work proceeds, and receives Artifacts as the Task completes. Five nouns, one clean flow.
Built on boring, proven standards
A2A is deliberately unglamorous under the hood, and that is a feature. It reuses the same battle-tested standards that already run the internet:
- HTTP(S) for transport.
- JSON-RPC 2.0 for structured requests and errors.
- Server-Sent Events for streaming live task updates.
- OAuth 2.0 and JSON Web Tokens for authentication.
Nothing exotic. Any engineer who has built a web service already knows the primitives, and every debugging tool they already use works unchanged. That conservatism is a large part of why the protocol was production-ready so quickly.
Who governs A2A, and why that matters
A2A was introduced by Google in April 2025 and quickly moved out of any single company's control: it was contributed to the Linux Foundation, which now governs it as a vendor-neutral standard.
This is not a detail. A protocol controlled by one company gives every competitor a reason to hold back — and agent interoperability is worthless if half the ecosystem refuses to adopt it. Neutral governance removed that objection, which is why you now find A2A supported inside Microsoft Copilot Studio, Azure AI Foundry, Amazon Bedrock AgentCore, and Google ADK simultaneously.
It reached a stable 1.0 release with core data models frozen. New capability arrives as extensions rather than breaking changes, so what you build against stays standing.
How A2A relates to MCP
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.*
What A2A is not
It helps to draw the boundary clearly:
- Not a framework. A2A does not replace LangGraph, CrewAI, or whatever you use. It sits between agents as a messaging layer.
- Not a model or a runtime. It does not decide how your agent thinks or what it can do.
- Not a replacement for MCP. Different problem, designed to coexist.
- Not a message queue or integration bus. It is narrowly a protocol for one agent to discover, delegate to, and collaborate with another.
Everything it deliberately leaves out is something a framework, model, or companion protocol already handles better. That restraint is why it composes so cleanly.
Frequently asked questions
What is the Agent2Agent protocol?
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, is governed by the Linux Foundation, and has reached a stable 1.0 release.
Who created A2A and who controls it now?
Google introduced A2A in April 2025 and contributed it to the Linux Foundation, which now governs it as a vendor-neutral open standard. No single company controls it.
Is A2A production ready?
Yes. A2A reached a stable 1.0 release with core data models frozen, ships official SDKs for Python, JavaScript, Java, Go, and .NET, and is supported inside Microsoft Copilot Studio, Azure AI Foundry, Amazon Bedrock AgentCore, and Google ADK.
Do I need to rewrite my agents to use A2A?
No. A2A is not a framework — it's a messaging layer between agents. Adoption means giving an agent an Agent Card and an A2A endpoint. Its internals, model, and framework stay exactly as they are.
What's the difference between A2A and MCP?
MCP connects an agent to tools, data, and context. A2A connects agents to each other. MCP is vertical; A2A is horizontal. They're complementary and most production systems use both.
More in this series
- A2A vs MCP — A2A vs MCP: The Two Protocols Behind Every Serious AI Agent System
- The Agent Card — The Agent Card: How AI Agents Discover Each Other
- The Task Lifecycle — Understanding the A2A Task Lifecycle (and the Bug That Hangs Every Client)
Want to go deeper?
I wrote two guides on this.
A2A Quick-Start — free, 6 pages. The Agent2Agent protocol in 15 minutes: what it is, the five building blocks, the task lifecycle, and where MCP fits.
A2A: The Complete Guide — 42 pages. 15 chapters, 5 appendices. Discovery, security, building your first agent with the SDK, orchestration patterns, extensions and AP2, production and scaling — plus a full worked example of two agents talking and a 30-day adoption path.
Independent educational content. Not affiliated with, endorsed by, or sponsored by Google, the Linux Foundation, Anthropic, or any vendor named. A2A and MCP are evolving specifications — confirm details against the official specification for your target version.
Top comments (0)