Agent2Agent Protocol Moves to Agentic AI Foundation

Consolidation Under Shared Governance

The Agent2Agent (A2A) protocol has moved to the Agentic AI Foundation, the Linux Foundation body that already hosts the Model Context Protocol (MCP), according to an announcement made August 17. The transfer places two of the most widely adopted agent interoperability protocols under unified governance, though each maintains separate maintainers and release schedules.

The move represents a shift in hosting rather than control. Google originally donated A2A to the Linux Foundation in June 2025 alongside AWS, Cisco, Microsoft, Salesforce, SAP, and ServiceNow. The protocol had already been under neutral governance for more than a year before joining AAIF.

How the Protocols Differ

A2A and MCP address different layers of the agent stack. A2A functions as a discovery and delegation mechanism—agents publish structured "agent cards" describing their capabilities and endpoints, allowing other agents to delegate tasks without human intervention. MCP, by contrast, standardizes how agents access data sources including databases, APIs, and file systems.

The A2A protocol reached version 1.0 in March 2026, adding multi-protocol bindings, version negotiation, multi-tenancy support, and cryptographically signed agent cards. These signed cards authenticate an agent's identity and metadata against a trusted signing key, though verification depends on establishing that the key genuinely belongs to the claimed organization.

According to the Linux Foundation, more than 150 organizations now support A2A, with production deployments across Google Cloud, Azure AI Foundry, and AWS Bedrock AgentCore. Huawei has implemented the protocol between its Celia operating system assistant and in-app agents on HarmonyOS.

What Remains Unresolved

Shared governance does not standardize enterprise authorization policies. While A2A includes normative requirements that servers must perform authorization checks and scope results to a caller's authorized boundaries, the policy model itself remains deliberately open. Organizations must still define what a partner's agent can access when tasks cross organizational boundaries.

Implementation depth varies significantly across platforms claiming A2A support. Hosting an A2A endpoint differs substantially from supporting protocol bindings, version negotiation, multi-tenancy, and signed cards. Consensus governance may also introduce coordination overhead that could affect release velocity.

Why It Matters

Consolidating A2A and MCP under one foundation reduces the risk that either specification will pivot based on a single vendor's roadmap. Enterprises gain a clearer path for evaluating multi-agent systems, though they must still verify conformance levels, trust mechanisms, and audit capabilities across implementations. The coordination venue matters more than the organizational chart—having both protocols governed in the same place should improve alignment between the communities building on them.

Questions for Vendors

Enterprises evaluating A2A implementations should ask which protocol revision a vendor supports, which bindings it implements, and whether it negotiates versions with older clients. Trust and isolation questions include whether the platform rejects unsigned agent cards, how it validates signing keys, and what mechanisms isolate tenants.

The most frequently overlooked question concerns accountability: when an enterprise agent delegates work to a partner's agent, which system enforces access boundaries, and does the exchange produce an audit record for compliance review?

Details were first reported by Janakiram MSV in Forbes.