Executive Summary

Key Numbers

Of the four cells below, the first three show how quickly this ecosystem converged on one place. The last card has no number in it, because the pace of convergence did not settle a matching number of questions.

Sources: Axios (2026-08-17), AAIF announcement, Linux Foundation press release (2025-12-09)

A2A (Agent2Agent) is a protocol Google launched in April 2025. It defines how agents built on different frameworks and by different vendors find each other, hand off work and get results back. That June, Google donated the specification, SDKs and tooling to the Linux Foundation together with AWS, Cisco, Microsoft, Salesforce, SAP and ServiceNow. In August 2025, IBM merged its own Agent Communication Protocol into A2A.

What Axios reported exclusively on August 17, 2026 is that A2A would become a hosted project of AAIF, the Linux Foundation body focused specifically on agentic AI. TechStrong AI followed the next day, Forbes the day after that. This is not an ownership event. A project already held in neutral governance moved into a narrower, more specialized home.

What was already in that home determines how much the news weighs. The Linux Foundation announced the formation of AAIF on December 9, 2025 with three anchoring project contributions: Anthropic's MCP, Block's goose and OpenAI's AGENTS.md. Its platinum members include AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI. At the time of that announcement MCP had passed 10,000 public servers and had been adopted by Claude, Cursor, Microsoft Copilot, Gemini, VS Code and ChatGPT.

The foundation now holds five projects, and it describes them as layers of a single stack. AGENTS.md sits in the instructions and context layer, telling agents a project's conventions and operating rules. goose is the runtime layer where an agent reasons, plans and carries out work. MCP is the connectivity layer that reaches tools and data. agentgateway sits at the boundary between agent systems and the infrastructure they run on, handling routing, policy and observability. A2A, the new arrival, is the agent-to-agent interoperability layer. Connecting, running and mediating now live in one place.

Rao Surapaneni, VP at Google Cloud, told Axios: "When we first envisioned A2A, the hypothesis was customers are deploying agentic systems from multiple technology providers and platform providers." All of those agents, he said, need to be able to work together. Mazin Gilbert, AAIF's executive director, put the distinction this way in an interview: "There's a big difference between an open protocol and open standard, and having an open protocol becoming interoperable with the entire stack." He added: "Companies don't want just one protocol; they want the whole stack to be open." Both remarks point at the same thing. A specification being published and a specification actually meshing with someone else's systems are different achievements.

The foundation's own argument for neutral governance reads like procurement language. When a foundational component belongs to one vendor, every downstream team absorbs that vendor's roadmap constraints and release cycles; under open governance the community shapes what gets built and when. The 150-plus organizations backing A2A include direct competitors, and that breadth only holds together under governance no single participant controls. Axios framed the significance in buyer terms as well. Making it easier to mix agents and tools from different providers gives companies more room to choose on cost, performance and latency.

Why the two standards do not compete is stated most compactly in a single Forbes sentence pair: "MCP standardizes how an agent reaches a database, an API or a file system. A2A standardizes how one agent asks another to complete a task and return the result." They do not overlap on one layer. They run in different directions.

On the A2A side, everything starts with the agent card. An agent publishes a structured description of what it can do and how to reach it. Another agent reads that card, discovers the capability and delegates the task without a human brokering the handoff. Before that, as AAIF describes the era it is leaving behind, agents built on different frameworks could not hand off work without custom integration code written for each pairing, and every new vendor relationship required the same work from scratch. The cost was never in the agents. It was in the space between them.

The two standards diverge on direction and on the problem they solve, and they arrived at different times by different routes. Only the last row matches. Joining the same foundation changed nothing about how each one is run.

The consolidation trend itself is clear. IBM folding its own specification into A2A was the first real signal that fragmentation was shrinking, and A2A now has backing from more than 150 organizations and runs in production across supply chain, financial services and mobile platforms. Huawei standardized on A2A to link Celia, its OS-level assistant on HarmonyOS, with in-app agents, and Tencent's WeChat uses it to integrate with Huawei and other Android OEM assistants. Google Cloud, Microsoft Azure AI Foundry and AWS Bedrock AgentCore all host A2A agents or expose A2A endpoints.

Read those numbers with the caveat Forbes attached to them. The count of supporting organizations and the production deployments come from the foundation and its vendors rather than independent measurement. The 250 member figure is the foundation's own tally too. It is enough to show direction and not enough to treat as market share. Fragmentation is not fully resolved either. IBM's ACP was absorbed into A2A, but Cisco's AGNTCY still addresses overlapping ground in discovery and identity. That happens to be the ground closest to the problem this article is about.

A2A v1.0, released in March 2026, is the standard's first stable specification. Multi-protocol bindings and version negotiation, multi-tenancy and cryptographically signed agent cards all landed in that release. Those are enterprise deployment and identity verification features.

The caveat Forbes adds here is the more useful one for practitioners. Hosting an A2A endpoint is not the same as supporting protocol bindings, version negotiation, multi-tenancy and signed cards. A name on a list of supporting organizations tells you nothing about which revision the agent on the other side implements or how far it goes. The list points at a direction. It does not report a state.

The unresolved item all three outlets converge on takes Forbes two sentences: "A shared foundation settles who stewards the specifications. It does not standardize enterprise authorization policy." Another line in the same piece states that after joining, each protocol keeps its own maintainers, specification process and release schedule. What came together here is governance, not policy.

The signed agent card in v1.0 illustrates the distinction well. A signature confirms that the card really belongs to the organization it claims. That is identity verification, which is authentication. But the question that produces incidents in practice comes next. This agent's identity checks out, so may it read our customer table? That is authorization, and a signature answers none of it. Forbes puts the limit precisely: the guarantee a signed card provides holds only as far as the recipient can establish that the signing key belongs to the organization being asserted.

The A2A specification does not leave the problem alone. It states that "Once a client is authenticated, the A2A server is responsible for authorizing the request," and it says access can be controlled on a per-skill basis as advertised in the agent card. It requires least privilege as well: agents must grant only the permissions a client or user needs for their intended operations, and agents that interact with backend systems, databases or tools must enforce appropriate authorization before performing sensitive actions or reaching sensitive data.

This split is a design decision rather than an omission. Rather than inventing new standards for security and operations, A2A aims to integrate with the infrastructure and practices enterprises already run. Authentication is delegated to standard web mechanisms such as OAuth 2.0 and OpenID Connect, and the server advertises which schemes it accepts in its agent card. Protocol payloads do not carry user or client identity at all. Identity is established at the HTTP layer, and credentials are obtained through processes outside the protocol. A server should return 401 when credentials are missing or invalid, and 403 when the credentials are valid but the client lacks permission for the requested action. The boundary between authentication and authorization is encoded in those two status codes.

That is where the specification's requirements stop. It says to authorize; the basis for the decision belongs to each organization. In Forbes's phrasing the policy model itself is deliberately left open, so what a partner's agent may touch once a task crosses an organizational boundary still lands on the enterprise. How far a partner's agent may see inside your boundary, where tenant isolation is enforced, how you verify that a signing key really belongs to the organization asserting it: all of it remains an implementation choice.

You can gauge the size of that gap by watching what the industry did when it actually had to settle authorization. Google Cloud and PayPal extended A2A into commerce without handing payment authorization to A2A. Shopping and merchant agents exchange product discovery, pricing and order fulfillment over A2A, and a separate layer built on top, AP2 (Agent Payments Protocol), provides the payment authorization. When the question became what an agent is permitted to do, one communication standard was not enough and a second standard had to be built.

Nor is the foundation short of a place to enforce policy. agentgateway, described earlier, is exactly that place, taking MCP and A2A traffic at one point and applying policy to it. What a gateway supplies, though, is an enforcement point rather than the content of the policy. Which agent from which partner gets which data is still something the adopting organization has to write down and load in.

So Forbes reduces the vendor conversation to three questions. Which A2A revision does the vendor implement, which bindings does it support, and does it negotiate versions with older clients (conformance). Does the platform reject unsigned agent cards, how does it establish that a signing key belongs to the asserted organization, and what isolates one tenant's agents from another's (trust and isolation). And when an enterprise agent delegates work to a partner's agent, which system enforces the access boundary, and does the exchange leave an audit record a compliance team can read (accountability).

TechStrong AI attached a warning from a different angle to the same news. Mahesh Shanmugasundaram, lead AI solutions architect at Seekr, granted the progress and then named the cost: "Open protocols like A2A are an important step toward making agentic AI more interoperable and flexible. But the truth is, interoperability only expands that already existing trust gap. While the protocol standardizes the pipe, organizations decide what travels through it."

The failure mode he described is specific. "In an A2A chain, each agent treats the prior agent's output as 100% trusted input vs. a claim to be verified," he said. "Once that assumption has been baked in, cascading failure becomes structurally worse than teams expect." A small hallucination near the front of a chain can surface several steps later as a highly authoritative-looking answer, a pattern he called an AI game of telephone.

This risk is not only a matter of careless implementations. The A2A specification writes agent opacity into its design principles: agents are typically opaque because they don't share internal memory, tools, or direct resource access with each other. The upside is that a remote agent can be treated as a standard HTTP-based enterprise application, so existing security models apply unchanged. The cost is that an agent further down the chain has no way to see what the agent before it based its answer on. All it receives is the output. That is why the game of telephone gets structurally worse. Without the evidence traveling alongside the answer, the receiving side cannot verify even when it wants to.

The authorization problem and the trust problem look separate, but in practice they meet at the same point. Both are judgments the standard does not make for you, and both depend on whether the basis for the judgment can be reconstructed later. Without a record of which agent read what under whose authority, a permissions incident cannot be replayed; without a record of which claim passed unverified at which step of a chain, a wrong answer cannot be traced to its origin. Which is why Shanmugasundaram argued that evidence-based evaluations and explainable output cannot be an afterthought and need to be the default unit of exchange between agents.

The argument about how to connect things has largely wound down. Tool access goes through MCP, agent-to-agent communication goes through A2A, and one neutral foundation stewards both. For organizations that delayed adoption while waiting to see which standard would win, that is good news.

Once the pipes are laid, though, more requests arrive through them. Until yesterday the things attaching to your systems were people and applications you built. Now agents built by another company and running in another cloud knock at the door using a standard protocol. The questions waiting at that door do not change when the protocol does. Whose authority is this request carrying, may this data be shown to this party, and if it becomes a problem later, what will we use to explain it.

All three answers live on the data side: which data falls into which classification, what access policy is attached to that classification, and what gets recorded when access happens. The specification asks enterprise implementers for the same things. Be acutely aware of the sensitivity of the data exchanged in messages and artifacts, comply with regulations such as GDPR, CCPA and HIPAA based on the domain and data involved, and avoid including or requesting unnecessarily sensitive information in the first place. None of that is work a protocol can do on your behalf. An organization that has not settled those three cannot safely open cross-boundary delegation no matter how tidy the standards get. For an organization that has, A2A is less a new risk than one more doorway where policies it already uses can be applied.

The preparation available right now also sits outside the protocol. Decide first which skills your organization is willing to expose to external agents, write down which data each of those skills reaches, and build the place where delegation requests and their results will be kept as an audit record. It takes longer than reading a specification, and it survives the specification changing.

Official Documents

• 1.The Linux Foundation. (2025). Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF).
• 2.Agentic AI Foundation. (2026). Agent2Agent (A2A) joins AAIF's open agentic stack.
• 3.A2A Project. Enterprise-Ready Features. A2A Protocol Specification.

Press

• 4.Fried, I. (2026). Exclusive: AI agents inch toward interoperability. Axios.
• 5.Janakiram MSV. (2026). Agent2Agent Joins The Agentic AI Foundation Alongside MCP. Forbes.
• 6.Vaughan-Nichols, S. J. (2026). Google Moves A2A Under Agentic AI Foundation. Techstrong AI.