Key Takeaways
- A2A lets AI agents discover and collaborate as peers, growing from 50 to 150+ partner organizations in its first year.
- MCP handles the vertical agent-to-tools layer; A2A handles the horizontal agent-to-agent layer — they're complementary.
- With v1.0's Signed Agent Cards and the AP2 extension, A2A is now the horizontal bus for agentic commerce.
One Year In, Agents Finally Learned to Talk to Each Other
On April 9, 2026, PR Newswire marked the one-year anniversary of the A2A Protocol. More than 150 organizations participate, the GitHub repo has passed 22,000 stars, and production deployments now exist inside Azure AI Foundry and Amazon Bedrock AgentCore. The numbers in the PR Newswire release are an entirely different order of magnitude from the 50-partner Cloud Next launch a year ago.
This article covers Google's A2A (Agent-to-Agent) Protocol as it stands in April 2026 — the design philosophy, the architecture, what the v1.0 release changed, how it relates to MCP, and how the AP2 extension ties it into payments. MCP has already been covered in depth in our What is MCP guide and MCP server implementation guide, so this piece focuses firmly on A2A.
What is the A2A Protocol?
A2A is an open protocol that lets AI agents discover, communicate, and collaborate as peers across frameworks and vendors. Google's official announcement went out on April 9, 2025, at Google Cloud Next. More than 50 launch partners came along, including Accenture, Atlassian, Box, Cohere, Deloitte, Elastic, LangChain, MongoDB, PayPal, Salesforce, SAP, ServiceNow, and UiPath.
Two months later, on June 23, 2025, Google donated A2A to the Linux Foundation, establishing the Agent2Agent Protocol Project under neutral governance. The initial LF founding members were AWS, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow. That decision to give up ownership, together with Anthropic's similar move for MCP later in the year, signaled the industry agreement that the wiring standards for AI agents no longer belong to any single vendor.
The problem A2A is solving is, in one sentence, horizontal interoperability. Agents built by different vendors haven't had a common way to talk to each other directly. Even agents sitting on the same SaaS platform couldn't federate without defining ad-hoc REST APIs. A2A creates a single language for that "agent-to-agent" layer.
Agent Card, Task, Message, Artifact — The Four Core Concepts
The A2A specification rests on just four ideas.
First, the Agent Card. Every agent publishes a JSON document describing its name, capabilities, authentication schemes, endpoint, and skills at https://{domain}/.well-known/agent-card.json. Because it follows the RFC 8615 well-known URI convention, any other agent can discover capabilities simply by knowing the domain. This is the foundation of decentralized discovery.
Second, the Task. Every A2A interaction is tracked as a Task with an explicit lifecycle: submitted → working → input-required / auth-required → completed / failed / canceled / rejected. Long-running asynchronous work is a first-class citizen, which is a significant departure from MCP's essentially synchronous request-response model. A2A assumes long-lived tasks from the beginning.
Third, the Message — the unit of exchange inside a Task. Messages carry a role of either "user" or "agent" and a body expressed as an array of Parts. Parts can mix text, binary data, files, and structured data, making the protocol multi-modal by design.
Fourth, the Artifact — the output of a Task. A PDF invoice, a JSON analysis result, an image: each is delivered to the client as an Artifact.
On the wire, A2A uses JSON-RPC 2.0 on top of HTTP, Server-Sent Events, or gRPC bindings. Supported auth methods include API keys, HTTP auth, OAuth 2.0 / OIDC, and mutual TLS — parity with OpenAPI security schemes, which is a pragmatic design choice for enterprise integration. The official specification defines 11 JSON-RPC methods including SendMessage, SendStreamingMessage, GetTask, SubscribeToTask, and CreateTaskPushNotificationConfig, and both streaming and webhook-based push notifications are baked in from day one.
What v1.0 Unlocked — Signed Agent Cards and Multi-Tenancy
A2A v1.0, released in early 2026, is the version that turned the spec into something production-grade. The v1.0 release notes call out four changes.
The most important is Signed Agent Cards. By adding a cryptographic signature to the Agent Card, a receiving agent can verify that the card was actually issued by the domain owner. Without this, an attacker could stand up a fake Agent Card and redirect other agents into a card forgery attack. Signed Agent Cards are effectively the trust model that makes decentralized discovery viable at all.
The second change is multi-tenancy. A single endpoint can now host multiple agents, letting SaaS providers serve different agents per tenant. The third is multi-protocol bindings: the same logical agent can be exposed over both JSON-RPC and gRPC. The fourth is version negotiation, which spec-level guarantees backward-compatible migration from v0.3 to v1.0.
Looked at together, v1.0 is explicitly the release that fixed "v0 was functional but not production-grade." Without Signed Agent Cards, cross-organization integration wasn't defensible. Without multi-tenancy, SaaS providers had no real path. In other words, v1.0 filled in the last pieces needed to actually run A2A in the enterprise.
A2A vs MCP — Different Layers, Not Competitors
A2A and MCP are often conflated, but the layers they occupy are completely different. Google's own docs dedicate a page titled "A2A and MCP" to the distinction.
| Dimension | A2A | MCP |
|---|---|---|
| Primary axis | Horizontal (agent ↔ agent) | Vertical (agent ↔ tools/data) |
| Creator | Google (April 2025) | Anthropic (November 2024) |
| Governance | Linux Foundation (June 2025) | Linux Foundation / AAIF (Dec 2025) |
| Interaction model | Peer-to-peer, opaque agents negotiating tasks | Client-server, model invokes tools |
| Discovery | Agent Card (/.well-known/agent-card.json) | Capability handshake at connect time |
| State model | Explicit state machine per Task | Mostly stateless tool calls |
| Long-running ops | First-class (input-required, streaming, push) | Limited, ad-hoc |
| Typical use | Procurement agent ↔ supplier agent, multi-agent orchestration | Agent ↔ GitHub, Agent ↔ Postgres |
Google's own metaphor is the clearest. Picture an auto repair shop. From the outside, the customer sees a single "repair agent." Internally, that repair agent collaborates over A2A with specialized diagnostic, estimate, and parts-procurement agents, and each of those specialists uses MCP to reach its own inventory systems or parts catalogs. A2A is the horizontal bus; MCP is the vertical bus. Hold that picture and the rest of the architecture falls into place.
For the full map of how A2A, MCP, UCP, and ACP relate, our agentic AI protocol taxonomy lays out the complete landscape.
AP2 Rides on A2A as a Formal Extension
In September 2025, Google Cloud and Coinbase announced AP2 (Agent Payments Protocol). What matters is that AP2 isn't a separate protocol — it ships as a formal extension to A2A. The AP2 A2A Extension spec registers AP2 as an AgentCard extension with the URI identifier https://github.com/google-agentic-commerce/ap2/tree/v0.1.
In practice, that means a client agent asking "are you payment-capable?" only has to inspect the extensions field of the Agent Card to see whether AP2 is supported and at what version. Rather than inventing a new discovery mechanism, Google reused A2A's existing channel and bolted payments onto it. This is a clean example of extending commerce capabilities without breaking the protocol stack's layer boundaries.
The full AP2 story is in our AP2 Agent Payments Protocol deep dive; the point to carry away here is that A2A doesn't handle payments at all. Payments live in AP2, which is an extension. A2A stays focused on the language of inter-agent conversation and coordination, and specialized extensions stack on top as needed.
What A2A Means for Agentic Commerce
From a commerce operator's point of view, A2A's real payoff is the next 18 months.
Agentic commerce today is mostly single-agent: one AI agent acts as the customer's proxy on one merchant. Real procurement, B2B transactions, comparison shopping, and complex contract negotiation, however, require multiple agents working together. A buying agent talks to several supplier agents in parallel, gathers quotes, negotiates terms, and settles through AP2 at the end. If every vendor builds that flow as a private integration, each new supplier relationship needs a custom connector.
A2A provides a common horizontal language for exactly this. Agent Cards handle discovery, Tasks handle long-lived negotiation, and AP2 extensions handle payment. With those three layers in place, commerce between agents becomes technically viable. Our Agent-to-Agent era of ecommerce article goes deeper into the practical implications, and what is agentic commerce offers the broader context.
One more 2025 event worth noting: in August, IBM's ACP (Agent Communication Protocol) merged into A2A under LF AI & Data. A2A's largest potential competitor joined it voluntarily. For any operator designing inter-agent integration today, there is essentially no alternative to A2A as of April 2026.
Conclusion — From Wiring Spec to Commerce Bus
A year ago, A2A was a new specification announced by Google with 50 partners. A year later, it is a cross-industry horizontal bus: 150+ organizations, owned by the Linux Foundation, v1.0 with Signed Agent Cards, AP2 shipping as a formal extension, and production deployments at Microsoft, AWS, Salesforce, SAP, and ServiceNow.
Three things are worth holding onto. A2A and MCP are complementary layers, not competitors. v1.0 is the version that met the enterprise production bar. And with the AP2 extension, A2A is now the horizontal bus for agentic commerce as well as its transaction layer.
If MCP is plumbing, A2A is the electrical distribution panel. Individual agents can have perfect plumbing to their own tools, but a multi-agent society can't exist unless those agents can exchange power with each other. The next question every agentic system designer will face is whether the system closes around a single agent or collaborates with agents built by other organizations. When you get to that question, ignoring A2A is no longer one of the available answers.
