On June 23, 2025, Google handed A2A to the Linux Foundation. Two months later, IBM scrapped its own Agent Communication Protocol and merged the engineers into A2A's technical steering committee. By April 2026, 150+ organizations had signed on — AWS, Microsoft, Salesforce, SAP, ServiceNow, Cisco, Atlassian, McKinsey. The GitHub repo sits at roughly 21,900 stars, about 40% of MCP's tally.
That gap matters. MCP won the tool-calling layer. A2A is winning the layer above it — agents talking to agents — and the version that shipped this year is the one worth using.
v1.0 was the upgrade that made A2A production-grade
A2A v1.0 landed in early 2026 after the v0.3 release introduced gRPC three months earlier. Four changes mattered. The big one: Signed Agent Cards.
An Agent Card is the JSON metadata document an A2A server publishes at https://{domain}/.well-known/agent.json. It advertises identity, skills, the service endpoint, and supported auth schemes. Without signatures, an attacker could stand up a forged card and redirect peer agents to a malicious endpoint. v1.0 added JSON Web Signature (RFC 7515) with JSON Canonicalization (RFC 8785), so a receiver can cryptographically verify the domain owner actually issued the card.
The other three: multi-tenancy (one endpoint, multiple logical agents — required for SaaS providers), multi-protocol bindings (the same logical agent exposed over both JSON-RPC and gRPC), and version negotiation that promised a backward-compatible migration path from v0.3.
If you're still on v0.2, upgrade this quarter. v0.2 has no signed cards. That's a forgery vector you don't want sitting in your trust model.
The protocol is boring on purpose
A2A uses JSON-RPC 2.0 over HTTPS for the request/response layer. Streaming uses Server-Sent Events, where each event payload is a JSON-RPC response. Long-running tasks — minutes to days — use push notifications: the client registers a webhook URL via PushNotificationConfig, and the server POSTs task, message, statusUpdate, or artifactUpdate events when state changes.
State changes traverse a defined lifecycle: submitted → working → input-required → completed, with canceled, failed, rejected, and auth-required as terminal or branch states. Once a task hits a terminal state, it cannot restart — refinements get a new task ID under the same contextId. That constraint sounds annoying. It isn't. It forces both sides to agree on what "done" means, which is the failure mode every multi-agent system runs into first.
Auth is discoverable. Agent Cards advertise securitySchemes aligned with OpenAPI: API keys, OAuth 2.0, OpenID Connect Discovery. Auth0 and Google Cloud published a joint integration in March 2026 that wires the OAuth client-credentials flow in a few lines.
A2A and MCP solve different problems
This is the one architectural distinction worth memorizing. MCP is a client-server protocol: an agent (client) calls a tool (server) that returns data and holds no state of its own. A2A is peer-to-peer: both sides are agents with reasoning, planning, and their own task lifecycle. MCP is vertical — you reach down to tools. A2A is horizontal — you delegate sideways to other agents.
The reference stack Google ships looks like this: MCP for tool calls, ADK 1.0 for in-process agent orchestration, A2A for cross-organization or cross-framework agent communication. Microsoft, AWS, and IBM all adopted variants of the same three-layer split. If you're building a single agent that uses 10 tools, you need MCP. If you're building a system where a Salesforce CRM agent has to delegate a support escalation to a ServiceNow ITSM agent without either team writing a custom integration, you need A2A.
Production deployments are real, not press releases
PayPal shipped A2A in production for merchant commerce: a sales agent receives a natural-language request, locates the PayPal payment agent via its Agent Card, authenticates over OAuth, and delegates invoice creation. Google's AI Mode in Search uses A2A to route shoppers to merchant agents at Best Buy, Lowe's, and Walmart — initial transactions through Google Pay, PayPal added as a second payment rail. Salesforce Agentforce talks to Google Workspace agents over A2A. SAP and ServiceNow have IT-ops workflows where one platform's agent hands off tickets to another.
Adoption is broadest in supply chain, financial services, insurance, and IT operations — domains where the agent has to cross a vendor boundary. Single-vendor stacks don't need A2A. Cross-vendor stacks have nothing else.
Framework support is uneven
Google ADK, LangGraph (via LangSmith), CrewAI (added in March 2026), and the Microsoft Agent Framework all support both MCP and A2A as first-class citizens. AutoGen and the OpenAI Agents SDK don't have native A2A yet — you can bridge, but you're writing glue. Among SDKs, Python and Java are official; Go and Node are catching up. The unofficial community Python SDK (themanojdesai/python-a2a) ships features the official one hasn't merged yet, which is a signal of where the official roadmap is behind.
Security is a discoverable contract, not a guarantee
Read this carefully. A2A publishes which auth schemes you support but doesn't enforce mTLS, doesn't mandate signed cards (they're a "MAY" in the spec, not a "MUST"), and treats credential provisioning as out of scope. The protocol assumes you'll bring your own trust infrastructure.
The right pattern: mTLS inside your trust boundary, OAuth across it, signed Agent Cards everywhere, and webhook URL validation on push notifications so a malicious client can't trick your server into a SSRF attack against an internal service. The Diagrid + Dapr writeup on hardening A2A is the best practical reference published this year.
When to adopt
Adopt A2A now if you have agents crossing organizational or vendor boundaries — that's where the protocol pays for itself. Wait if you're inside a single framework and a single trust zone; native orchestration is faster to build and easier to debug. If you're on v0.2, upgrade to v1.0 this quarter and turn signed Agent Cards on by default.
The boring decisions in A2A were the right ones. JSON-RPC over HTTPS, SSE for streaming, OpenAPI for auth, JWS for identity. Nothing exotic, nothing that requires a custom runtime. That's why it's the protocol that actually shipped while three competing standards either folded into it or stayed academic.