Agent-to-agent protocols: the next open layer
Actualizado: 2026-05-03
Years 2024 and 2025 consolidated Anthropic’s Model Context Protocol as the de facto standard for connecting an agent to tools and data sources. MCP elegantly solves the problem of every model talking to every service via one-off integrations: with MCP, a server exposes its capabilities once and any compatible client consumes them. But there’s a parallel problem MCP doesn’t address by design: how do two distinct agents communicate with each other. For that gap, Google presented in April 2025 the Agent2Agent protocol (A2A), and in June of the same year donated it to the Linux Foundation as an open project.
Key takeaways
- MCP solves agent-to-tool connection (asymmetric); A2A solves agent-to-agent connection (symmetric, each side with its own reasoning).
- The two protocols are complementary, not competing: a well-designed system can use MCP for tools and A2A for agent coordination.
- A2A defines agent cards, tasks with observable state, structured artifacts, and real-time streaming progress.
- Real limits lie in security and trust (authentication left to integrator), capability semantics (free text, not ontology), and execution guarantees (no formal responsibility model).
- Neutral governance under Linux Foundation AI & Data is the factor that makes it a reasonable bet against proprietary alternatives.
What problem A2A tries to solve
MCP solves a concrete layer: an agent (client) queries services (MCP servers) that expose tools, resources and prompts. The communication is asymmetric: the server responds to client requests but doesn’t initiate autonomous actions. That works very well when the agent is the central intelligence and tools are passive. It doesn’t work when you want two agents, each with its own reasoning capability, to collaborate on a complex task.
Consider a practical example: a company’s sales agent that understands the catalog, promotions and inventory, and a finance agent that knows discount policies and credit limits. When a client asks for a complex quote with a special discount, you want the sales agent to talk to the finance agent, ask what margin is available, and receive an answer with justification. That isn’t a tool call returning JSON; it’s a conversation between two systems with their own judgment.
A2A tries to standardize exactly that conversation. The protocol defines:
- How one agent discovers others — via agent cards published at known endpoints.
- How it initiates a task — with a natural-language or structured description.
- How both sides track state — events, partial results, completion.
- How each agent exposes its capabilities without revealing its internal architecture — opacity is a core design principle.
The relationship with MCP
A common question is whether A2A competes with MCP. The short answer is no: they operate at different layers and are complementary.
| Protocol | Solves | Semantics |
|---|---|---|
| MCP | Agent ↔︎ Tool | Function called with parameters returning data; calling agent owns result |
| A2A | Agent ↔︎ Agent | System with own reasoning; responsibility distributed |
A well-designed system can use both: each agent connects to its tools via MCP, and agents communicate with each other via A2A.
Donation to the Linux Foundation
The decision to donate A2A to the Linux Foundation in June 2025 is strategically relevant. Google could have kept it as an internal project, but chose neutral governance from the start because protocols that catch on as standards are usually perceived as neutral. The official repository lives under the a2aproject organization on GitHub, with explicit sponsorship from Linux Foundation AI & Data, and the first months have seen contributions from Microsoft, SAP, Salesforce, Cisco and Intuit.
What the specification includes
The current A2A specification defines several basic components:
- Agent cards — JSON files published at a known URL (typically
/.well-known/agent.json) describing capabilities, communication endpoints, supported authentication mechanisms and interaction examples. - Tasks — unit of work with description, state (pending, in-progress, paused, completed, canceled, failed), bidirectional message queue, and artifact specifications. State is observable via server-sent streaming events.
- Artifacts — structured output: text, JSON, binary files or URLs to external resources. The protocol is format-agnostic as long as content type is declared.
Where the real limits lie
The specification covers the technical channel well but leaves important questions open:
- Security and trust — A2A defines anchor points for OAuth, OIDC or mTLS but leaves choice to the integrator, meaning two implementations can be incompatible in practice even if both follow A2A.
- Capability semantics — an A2A card says “I can do X” but the description of X is free text. Two agents can describe the same capability in different words, or different capabilities in similar words.
- Execution guarantees — A2A defines the communication protocol but not a responsibility model. Distribution of responsibility is left to legal contracts and service-level agreements.
There are official SDKs in Python, TypeScript, Java, Go and C#. Some platforms like LangChain, CrewAI and AutoGen expose native A2A output. Several enterprise platforms have announced incoming compatibility.
Conclusion
My assessment after tracking the specification since its initial publication is that A2A fills a real, necessary gap. The question isn’t whether a standard agent-to-agent protocol will exist but which one, and A2A starts from a better position than alternative candidates thanks to the combination of decent technical design, neutral governance and multi-vendor backing.
The pragmatic recommendation: design your agents’ internal interfaces with A2A in mind, even if you don’t use it yet, to reduce future friction when the time comes to integrate with external systems that already speak it. Waiting to see who wins has real opportunity cost. Recent protocol history — MCP won, Bedrock Agents and Semantic Kernel stayed in niches — suggests that whoever has open governance and a public specification process wins. A2A meets both conditions.
