An IT operations agent picks up a Sev-2 alert at 2 AM. It classifies the incident, decides it needs a network-diagnostics specialist, and routes the subtask to one - an agent it has never directly called before, built by a different vendor, running on a different platform. No shared memory. No bespoke integration written by whoever was on call. The whole handoff completes in a few hundred milliseconds.
That scenario is no longer theoretical. SAP's Joule orchestrator delegates subtasks like legal review and finance checks to partner A2A agents across S/4HANA, and ServiceNow's Now Assist registers A2A agents as skills so incident triage can fan out to specialized agents. The plumbing that makes this possible is the Agent-to-Agent Protocol, and in April 2026 it passed its first year in production - with results worth looking at honestly.
What A2A actually is
A2A standardizes communication between AI agents built on different frameworks, enabling them to discover one another's capabilities and collaborate on complex tasks. The clearest way to hold the concept is to contrast it with MCP. A2A defines how agents communicate and coordinate with each other across organizational boundaries, while MCP defines how agents connect to internal tools and data sources. MCP is the vertical bus - agent to tool. A2A is the horizontal bus - agent to agent.
Agent Cards serve as a discovery mechanism through which each agent publishes a machine-readable description of its capabilities, input and output modalities, and authentication requirements. Tasks represent units of work with a defined lifecycle, progressing through states such as submitted, working, input-required, completed, canceled, and failed. That lifecycle model is where A2A diverges sharply from simple REST calls. An agent does not fire and forget; it tracks task state, handles partial results over streaming connections, and knows when to ask for more input.
What v0 was missing
A2A v1.0, released in early 2026, is the version that turned the spec into something production-grade. That phrasing is a polite way of saying v0 was functional but not deployable in any enterprise that cares about identity and multi-tenancy.
The two changes that mattered most:
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. Without this, every SaaS vendor shipping an A2A endpoint would have to run separate infrastructure per customer - a dealbreaker at any reasonable scale.
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 provides spec-level guarantees for backward-compatible migration from v0.3 to v1.0.
v1.0 is explicitly the release that fixed "v0 was functional but not production-grade."
The adoption numbers, read carefully
Since April 2025, the number of supporting organizations has grown from more than 50 to over 150 - including AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, and ServiceNow.
Cloud providers reinforced that momentum by embedding A2A directly into their platforms. Microsoft integrated A2A into Azure AI Foundry and Copilot Studio, and AWS added support through Amazon Bedrock AgentCore Runtime.
That is a lot of logos. It is also worth being precise about what "supporting" means. Many of those 150 organizations are committed to compatibility, not running large fleets of A2A agents today. The most cited figure in the April 2026 Agentic AI Foundation status report is 150+ organisations with A2A in production - not in pilot, not on a roadmap, but routing real tasks between agents today. The distinction matters. Routing real tasks and routing important tasks at scale are not the same thing.
In August 2025, IBM's ACP (Agent Communication Protocol) merged into A2A under LF AI & Data. A2A's largest potential competitor joined it voluntarily. That consolidation is probably the clearest signal that A2A has won the standards race, at least for now. The governance structure matters too: governance moved under the Linux Foundation's Agentic AI Foundation in mid-2025, alongside MCP. That transition signalled to large enterprises that A2A was not a Google-only spec they could be locked into, and removed the last procurement objection for conservative buyers.
What the spec does not give you
A2A tells two agents how to find each other, negotiate a task, and exchange structured results. It does not tell you what the agents should actually do, how to evaluate whether the delegated task was completed well, or how to recover when a specialist agent returns a plausible-looking but wrong answer.
The trust model in v1.0 covers identity - you know the Agent Card is genuinely from the claimed domain. It does not cover competence. An agent can have a valid signed card and still hallucinate its way through a KYC check. A teammate like Beagle operating inside your Slack or Teams environment can surface the audit trail and the task states back to the humans who need to review them, but that review loop is something you have to design deliberately. A2A will route the work; it won't tell you when the work should go back to a person.
The protocol has also expanded beyond communication into economic coordination. The introduction of the Agent Payments Protocol (AP2) enables secure, agent-driven transactions, with more than 60 organizations across payments and financial services already supporting the initiative. That extension is genuinely new territory - agents that can not only coordinate work but authorize spend. Whether that belongs in a coordination protocol or deserves its own trust boundary is an open design question, and the honest answer is that nobody has enough production experience yet to be confident.
What to actually do with this
Framework support is broad. Native A2A is in Google ADK, LangGraph, CrewAI, LlamaIndex Agents, Semantic Kernel, and AutoGen. If your team is already in one of those frameworks, the on-ramp is short. The spec itself is at a2a-protocol.org, the reference SDKs are actively maintained, and the GitHub repo is a reasonable place to watch the roadmap evolve.
The practical thing to understand is the two-layer architecture before you write a line of integration code. MCP handles tool connectivity inside an agent. A2A handles the coordination between agents across team and vendor boundaries. Conflating them - making every tool call look like a peer agent, or tunneling agent coordination through MCP - produces systems that are hard to debug and harder to secure. The layers exist for a reason. Keep them separate, understand what each one owns, and the 2 AM handoff to an agent you have never met starts to look less like magic and more like ordinary infrastructure.