A2A Protocol After One Year: 150+ Organizations, In Every Major Cloud, First Stable Spec
On April 9, 2026, the Linux Foundation took stock at the first anniversary of the Agent2Agent protocol (A2A): the roughly 50 supporting organizations from the April 2025 launch have grown to more than 150, the protocol now sits inside the platforms of all three major cloud providers, and with spec version 1.0 there is, for the first time, a stable foundation declared production-ready. A2A governs how agents from different vendors talk to each other across organizational boundaries. For teams that want to combine agents from different tech stacks, this interop layer — not another framework — is the actual news.
What concretely changed
- More than 150 supporting organizations at the one-year mark — up from around 50 in April 2025. Named members include AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP and ServiceNow.
- Embedded in every major cloud: Microsoft (Azure AI Foundry, Copilot Studio), AWS (Bedrock AgentCore Runtime), Google directly in its own platforms.
- A2A 1.0 is the first stable spec — with multi-protocol support, enterprise-grade multi-tenancy and modernized security flows.
- Signed Agent Cards at the heart of 1.0: an agent’s card is cryptographically signed so a receiving agent can verify its origin.
- Division of labor with MCP: A2A coordinates agents with each other (horizontal); the Model Context Protocol connects agents to tools and data (vertical). The two are complementary, not competing.
What applied before
A2A was introduced by Google in April 2025 and shortly after handed over to the Linux Foundation — as an open standard, not a Google product. At launch it was a statement of intent backed by roughly 50 supporters: a protocol draft for how two autonomous agents negotiate tasks, exchange status and return results without both having to come from the same vendor.
In practice that stayed aspirational at first. Anyone wanting to make several agents work together in 2025 usually built the connection themselves — with vendor-specific APIs, custom glue code and no reliable identity check between the agents. A cross-agent standard existed on paper, but not as a broadly adopted, production-ready specification.
What applies now
With the one-year update, A2A shifts from announcement to operation:
1. From statement of intent to adoption. Tripling the number of backing organizations reads less as hype than as evidence that the big platform providers are not ignoring A2A. When AWS, Microsoft, Google, IBM, SAP, Salesforce and ServiceNow sit together on one interop standard, that signals to the market that cross-vendor agent communication is being treated as shared infrastructure, not as competitive ground.
2. Built into the clouds, not just compatible. Microsoft has integrated A2A into Azure AI Foundry and Copilot Studio, AWS into the Bedrock AgentCore Runtime, Google directly into its own platforms. That is the difference between “A2A is supported” and “A2A is part of the runtime” — teams no longer have to build the interop layer themselves.
3. First stable spec with security at the core. A2A 1.0 brings multi-protocol support, enterprise-grade multi-tenancy and reworked security flows. The practically most important detail is Signed Agent Cards: the “Agent Card” describes an agent’s capabilities; the cryptographic signature lets a receiving agent verify whether the card really originates from the stated domain owner — a basic precondition once agents act across organizational boundaries.
4. A clear split with MCP. The Linux Foundation explicitly positions A2A and the Model Context Protocol as complementary: A2A is the horizontal axis (agent talks to agent, across vendor lines too), MCP the vertical one (agent reaches into tools, data sources, internal systems). If you already work with MCP, A2A adds not a competing piece but the missing second one.
Context
What is notable about this news is not a single number but that two open protocols are establishing themselves side by side, rather than one vendor dictating the standard. A2A and MCP split the interop layer cleanly — and both run under open governance (A2A at the Linux Foundation). For a discipline that in 2025 was still shaped by proprietary SDKs, that is a sign of maturity: the question “how do agents talk to each other?” is no longer answered per vendor, but once for everyone.
The numbers warrant sobriety. “Over 150 organizations” measures participation in a specification, not the count of productive deployments — membership and real-world use are two different things. The Linux Foundation does cite production use in supply chain, financial services, insurance and IT operations, but without figures. The robust claim is the qualitative one: platform integration by the three big clouds is harder evidence than any membership count, because it means A2A becomes available with no extra effort wherever agents already run.
If you take that seriously, you plan agent architectures in two layers going forward: MCP to connect your own tools and data, A2A to coordinate with external agents. That very split makes it easier to keep a system incrementally vendor-open instead of binding yourself to one stack early.
What you can do now
If you already use MCP: Treat A2A as the missing second axis, not as competition. MCP connects your tools and data, A2A links your agent to agents from other vendors. Together they form the vendor-open interop layer.
If you want to combine agents from different vendors: Check whether your platform already ships A2A natively — for Azure AI Foundry, Copilot Studio and AWS Bedrock AgentCore that is now the case. It saves the hand-built glue code between agents.
If security matters (and with cross-agent communication it always does): Look at the Signed Agent Cards from A2A 1.0. They are the mechanism by which one agent verifies another’s origin before handing it a task.
Foundations in the lexicon
How a multi-agent system is built technically and which building blocks it needs is covered here: → Building AI agents
Entdecke mehr
Why AI Models Find Different Code Problems
Three frontier models, the same 1000-line script, three different finding lists — and why that very spread makes multi-orchestration strong.
GlossarEnsemble / Multi-Model Orchestration
Ensemble means combining several deliberately varied LLM runs or models whose findings complement each other. Multi-model orchestration drives these runs via orchestrators with sub-agents, so the union of results is larger than any single run.
LexikonAgentic Workflows vs. Agents — when to fix, when to free
The difference between fixed, predefined workflows and autonomous AI agents — with Anthropic's definition, the trade-offs, and a clear decision guide.