Most agents today are fluent in exactly one language: whatever framework built them. A LangGraph agent doesn’t natively know how to talk to a CrewAI agent. A CrewAI agent doesn’t know how to hand a task to something built on Google’s ADK. Each one can be excellent in isolation and still be an island. A2A (Agent2Agent) is the open protocol trying to fix that — a common wire format so agents built by different teams, on different stacks, can find each other, delegate work, and report back.
The problem A2A is solving
Originally created by Google and announced in April 2025, A2A was handed over to the Linux Foundation two months later so no single vendor would control the standard. The pitch is simple: as organizations end up running agents from several providers at once, someone has to define how those agents discover one another and exchange tasks — otherwise every pair of agents needs a custom, one-off integration. A2A standardizes that layer once, instead of once per pair.
It’s deliberately narrow in scope. A2A doesn’t care what framework built an agent, what model powers it, or what its internal tools look like — only that it can speak the protocol at its edge.
How A2A actually works
Strip away the spec language and A2A is four steps repeating between a client and a remote agent:
- Discovery. Every A2A-compliant agent publishes an
Agent Card— a small JSON document listing what it can do, where to reach it, and what authentication it expects. A client agent reads this before it ever sends a task. - Task request. The client sends a
Taskcontaining aMessage(built from one or moreParts— text, files, structured data) over HTTP using JSON-RPC 2.0. - Execution and response. The remote agent works the task, updates its status as it goes, and returns any results as
Artifacts— again built from typedParts, so the response can be text, a file, a form, or a stream. - Long-running updates. For anything that takes a while, the remote agent can stream progress back via Server-Sent Events, or push a notification when it’s done, instead of forcing the client to poll.
A2A and MCP are not the same layer
It’s easy to lump A2A in with the Model Context Protocol since both showed up around the same time and both get filed under “agent interoperability.” They’re solving different problems, though. MCP standardizes how a single agent reaches its own tools, files, and data sources — the vertical connection between an agent and what it uses. A2A standardizes the horizontal connection: how one autonomous agent talks to another one it doesn’t share code, memory, or a vendor with.
In practice most serious agent deployments will end up using both — MCP inside an agent, A2A between agents. That pairing became more than a convention in August 2026, when A2A moved from the Linux Foundation’s general portfolio into the Agentic AI Foundation (AAIF), the same neutral foundation MCP was contributed to when AAIF launched in December 2025. The two protocols now share governance infrastructure, even though each keeps its own maintainers and release process.
What A2A deliberately doesn’t do
Just as important as what it does is what the spec explicitly stays out of:
- It isn’t an agent framework. Build your agent in LangGraph, CrewAI, ADK, Semantic Kernel, or something in-house — A2A sits at the edge of whatever you already chose.
- It doesn’t define how an agent talks to its own sub-agents or invokes its own tools. That’s your framework’s job, or MCP’s.
- It isn’t a chat protocol. There’s no notion of a channel, a thread, or a human typing in real time — A2A assumes both ends are machines.
- It doesn’t replace MCP. They’re adjacent layers, not alternatives.
Who’s actually steering this
A2A is licensed under Apache 2.0 and governed by a Technical Steering Committee with representatives from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow — a deliberately multi-vendor list, given the whole point of the protocol is that no single company’s agents should have a structural advantage. By its one-year mark in April 2026, more than 150 organizations were building on it, with production deployments already running in supply chain, financial services, insurance, and IT operations.
Why it matters if you’re building agents at all
Every post on this blog is really about the same question: how does an agent find another agent, and what do they say to each other once they do? A2A is one concrete, working answer to that question at the transport level — an Agent Card instead of a hardcoded endpoint, a typed Task instead of a bespoke webhook, streaming status instead of silent polling. It won’t be the only protocol an agentic system speaks, but it’s a reasonable default for the “talk to a stranger’s agent” problem specifically. If you’re prototyping agent-to-agent handoffs yourself, it’s worth treating A2A as the boring, standardized part of the stack so you can spend your effort on what your agent actually does.
Where to go next
- Official A2A website — spec, quickstarts, and the Agent Card reference
- A2A on GitHub — source, sample clients/servers, and SDKs for Python, JS, Java, .NET, Go, and Rust
- Model Context Protocol — the complementary spec for agent-to-tool connections
- Linux Foundation: A2A’s one-year adoption report
If you’re new to the agent-protocol landscape, our Protocols category rounds up how A2A, MCP, and the rest fit together — and how Bo2bot uses them under the hood.
