Before v1.0 shipped, an attacker could stand up a fake Agent Card - a JSON document that tells other agents what a remote agent can do - and silently redirect tasks to it. No signature, no verification, no way for a receiving agent to know the card was genuine. That was the most glaring hole in A2A's v0 design, and it was the hole that kept enterprise security teams from approving cross-organization deployments.
The Agent-to-Agent protocol, originally built by Google in April 2025 and now governed by the Linux Foundation , exists to solve a specific plumbing problem: in a multi-agent system you often have a coordinator agent managing the work and specialist agents executing tasks, and without a shared protocol that coordination requires bespoke integration - the coordinator has to know exactly how each specialist works, what inputs it accepts, and how to parse its outputs. A2A standardizes that contract. But "standardizes" is doing a lot of work in that sentence, and v1.0 is where the spec started earning it.
What A2A v1.0 actually changed
The protocol advanced from v0.3.0 in July 2025, which introduced streaming-first transport and enhanced Agent Cards with capability negotiation, to v1.0.0 in January 2026, which marked the transition from experimental to production-ready status, introduced signed Agent Cards for cryptographic verification, and codified the discovery and trust mechanisms identified as gaps in earlier analyses.
The signed Agent Card is the change that unblocked real procurement conversations. 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.
Beyond trust, heterogeneous environment support enables interoperability across diverse technology stacks through multi-protocol bindings and version negotiation, so enterprises are not tied to a single vendor or platform, and multi-tenancy support allows a single endpoint to securely host many agents. That second one matters for SaaS vendors: instead of running one A2A endpoint per customer, a provider can serve many tenants through one address.
The v1.0 spec defines three protocol bindings - JSON-RPC 2.0, gRPC, and HTTP+JSON/REST - with JSON-RPC being the most common public deployment and gRPC favored for low-latency internal microservice communication.
How A2A and MCP fit together
The protocol-to-protocol relationship is worth being precise about, because it gets muddied in most explainers. MCP handles the vertical agent-to-tools layer; A2A handles the horizontal agent-to-agent layer - they are complementary. If your agent needs to call a database or run a code interpreter, that's MCP. If it needs to hand a subtask to a specialist agent running on a different framework at a different company, that's A2A.
A2A lets a LangChain-built application talk securely to an agent built using CrewAI, the OpenAI Agents SDK, PydanticAI, or any other framework that publishes an Agent Card. The framework choice on either side becomes irrelevant, which is the actual value proposition. You're not buying into a vendor's orchestration model; you're agreeing on a wire format.
In December 2025, the Linux Foundation formalized this consolidation through the launch of the Agentic AI Foundation (AAIF) as a neutral top-level foundation hosting both MCP and A2A. Both protocols under one governance body reduces the risk that they diverge into incompatible directions - though it doesn't guarantee the spec committees move at the same pace.
The adoption numbers, read carefully
On April 9, 2026, the A2A Protocol project announced more than 150 organizations supporting the standard, with deep integration across Google, Microsoft, and AWS platforms, and active production deployments across multiple industries.
April 2026 also brought GA support inside Microsoft Copilot Studio, Azure AI Foundry, and Amazon Bedrock AgentCore.
Those numbers are real. They are also what any Linux Foundation press release looks like at the one-year mark. "Supporting the standard" covers a range from shipping A2A in production to having one engineer read the spec. The most cited figure in the April 2026 Agentic AI Foundation status report is 150+ organizations with A2A in production - not in pilot, not on a roadmap, but routing real tasks between agents today
- though that framing comes from the foundation's own communications, not an independent audit.
Vertical adoption spans supply chain, financial services, insurance, and IT operations, where organizations use A2A to coordinate autonomous systems across tools, vendors, and environments. Those verticals make sense: they already run heterogeneous vendor stacks where point-to-point API integrations are expensive to maintain.
Where the spec still leaves you on your own
The honest part. Authentication is where A2A's production story gets complicated. The protocol explicitly supports multiple auth schemes - API key, HTTP Bearer, OAuth 2.0, OpenID Connect, and mutual TLS - but the spec intentionally does not mandate which to use or how to verify Agent Cards. The result: authentication correctness is entirely the implementer's responsibility.
That's a deliberate design choice, not an oversight. Mandating one auth scheme would alienate half the potential adopters. But it means two teams can each build "A2A-compliant" agents that can't actually authenticate to each other without a separate negotiation about which scheme to use.
There's also a subtler issue with what signed Agent Cards prove. A signature confirms who issued the card. It does not confirm that the data behind the agent is certified, current, or consistently defined. Authenticity is not correctness, and it is not shared meaning. An agent card can be cryptographically valid and semantically useless - advertising skills the agent can't reliably perform, or describing outputs in ways a consuming agent can't interpret. The protocol can't fix that. Shared ontologies and careful schema design can help, but that work sits outside the spec entirely.
Finally, discovery.
The protocol leaves discovery and identity largely to you.
There is no central registry. An agent finds another by fetching /.well-known/agent-card.json at a known host. That's fine inside an organization where you control the DNS. Across organizations, you still need an out-of-band agreement on where to look - which is exactly the kind of bespoke integration A2A was supposed to eliminate.
None of this makes A2A the wrong bet. The two-layer model with MCP is genuinely cleaner than the alternatives, the governance is serious, and having the same protocol running natively in Azure, AWS, and Google Cloud matters for enterprise teams who span all three. A coordinator agent in one cloud can now delegate to a specialist in another without a custom connector - something that would have required weeks of integration work eighteen months ago.
The v1.0 release fixed the most important structural gap. The spec still asks you to do real engineering on the things it left open.