On August 17, 2026, Google transferred the Agent2Agent (A2A) protocol to the Agentic AI Foundation (AAIF), the Linux Foundation body that already hosts the Model Context Protocol (MCP), Block's goose runtime, and OpenAI's AGENTS.md convention. The move was reported by Axios and confirmed by the AAIF project page.
In one year, the AAIF has become the neutral home for the three foundational protocols of the agentic stack: MCP for agent-to-tool connectivity, A2A for agent-to-agent communication, and AGENTS.md for agent-to-repository guidance. This convergence is not cosmetic — it changes how developers should think about building multi-agent systems.
What A2A Actually Does
A2A is an open protocol for AI agents to discover, communicate with, and securely hand off tasks to other agents across different platforms and frameworks. Where MCP standardizes how a single agent invokes tools and reads resources, A2A standardizes how multiple agents coordinate with each other.
The protocol defines:
- Agent Cards — machine-readable manifests (JSON) that describe an agent's capabilities, skills, authentication requirements, and endpoint information. Think of it as a service discovery document for agents.
- Task lifecycle — a standardized state machine for multi-agent work:
submitted→working→input-required→completed(orfailed/canceled). This gives observability into distributed agent workflows. - Artifact exchange — structured payloads (text, files, data) passed between agents with content-type negotiation and streaming support.
- Push notifications — webhook-based callbacks so agents can receive updates without polling.
- Authentication & authorization — built on OAuth 2.0 and OIDC, with support for mutual TLS for enterprise deployments.
Google open-sourced A2A in April 2025 with initial support from over 50 technology partners. The protocol was designed to be framework-agnostic — an agent built on LangGraph can hand off to an agent running on AutoGen, CrewAI, or a custom runtime, provided both speak A2A.
Why the Governance Shift Matters
Until August 2026, A2A was a Google-led project. Google's transfer to the AAIF moves it into the same vendor-neutral governance structure that now stewards MCP. The practical implications are significant:
1. Single governance body for the agentic protocol stack
Developers no longer need to track separate governance processes, IP policies, and contribution agreements for the two core interoperability protocols. The AAIF's Technical Steering Committee now oversees both. This reduces fragmentation risk — the scenario where MCP evolves in one direction while A2A evolves in another, creating integration friction.
2. Cross-protocol roadmap alignment
The AAIF has signaled that MCP and A2A roadmaps will be coordinated. The MCP 2026-07-28 revision introduced stateless HTTP transport, server identity, and official extensions. A2A's next milestone is expected to align its transport layer with MCP's HTTP binding, making it trivial to run both protocols on the same infrastructure. For teams deploying agent fleets, this means one ingress, one auth layer, one observability stack.
3. Enterprise adoption signal
Neutral governance is the prerequisite for regulated industries. The Linux Foundation's track record with Kubernetes, Node.js, and PyTorch shows that vendor-neutral homes accelerate enterprise adoption. With both MCP and A2A under the AAIF, enterprises evaluating agentic infrastructure now have a single compliance checkpoint instead of two.
4. Trademark and IP clarity
The AAIF holds trademarks for both protocols. This prevents the "embrace and extend" dynamic where a single vendor could fork the protocol and claim the name. The governance model mirrors MCP's: maintainers prioritize community input and transparent decision-making.
MCP vs A2A — The Boundary Is the Architecture
A common question: when do you use MCP, and when do you use A2A? The distinction maps to the architecture pattern:
| Dimension | MCP (Agent → Tool) | A2A (Agent ↔ Agent) |
|---|---|---|
| Primary actor | Single agent invoking capabilities | Multiple agents coordinating |
| Discovery | Tool listing via tools/list |
Agent Card via /.well-known/agent.json |
| Invocation model | Request/response (tools), subscription (resources) | Task lifecycle with async handoff |
| State | Stateless (post 2026-07-28) | Task-scoped state machine |
| Auth | OAuth 2.1 / Bearer tokens | OAuth 2.0 / OIDC / mTLS |
| Typical use | Code execution, file access, API calls, DB queries | Planning delegation, specialist handoff, human-in-loop escalation |
In practice, a production agent system uses both. A lead agent receives a user request, uses MCP to fetch context from a knowledge base, then uses A2A to delegate a sub-task to a specialist coding agent. That specialist uses MCP to write files and run tests. The protocols compose.
What This Means for Your Stack
If you're building on MCP today
Nothing breaks. The MCP governance model is unchanged. But you should watch the AAIF's cross-protocol working group — the first joint RFCs (likely around shared authentication primitives and unified error taxonomies) will land in Q4 2026. If you're running an MCP gateway, plan for A2A-aware routing.
If you're evaluating multi-agent frameworks
Frameworks that implement both protocols natively (or provide first-class adapters) will have a durability advantage. Look for: Agent Card generation from framework primitives, A2A task lifecycle hooks, and MCP server embedding within agent runtimes. The AAIF's project lifecycle policy (Growth → Impact → Emeritus) now applies to both protocols, giving you a signal for maturity.
If you're deploying in regulated environments
The AAIF's vendor-neutral home is the compliance artifact your security team needs. Both protocols now share the same IP policy, trademark stewardship, and governance transparency. You can point auditors to one foundation, not two vendor-led projects.
If you're building agent-to-agent products
A2A's move to AAIF de-risks building on it. Google's initial stewardship created a perception (fair or not) that A2A was "Google's protocol." The transfer signals long-term neutrality. Expect more framework integrations and enterprise-grade implementations in the next two quarters.
The Missing Piece: Authorization
Both MCP and A2A delegate authorization to the transport layer (OAuth, mTLS). Neither defines a fine-grained, protocol-native authorization model for what an agent is allowed to do — only who can connect. The AAIF has chartered an Authorization Working Group (announced alongside the A2A transfer) to address this. The goal: a shared authorization vocabulary so that an MCP tool call and an A2A task delegation can be governed by the same policy engine.
This is the next convergence point. If you're building agent infrastructure today, design your auth layer to be protocol-agnostic — the policy decision point should not care whether the request came via MCP or A2A.
What to Watch
- AAIF Technical Steering Committee minutes — published monthly. The first joint MCP/A2A roadmap session is scheduled for October 2026.
- A2A spec v1.1 — expected to align transport with MCP's HTTP binding and add structured error codes compatible with MCP's error taxonomy.
- AgentGateway project — the AAIF-hosted proxy that speaks both MCP and A2A. Early adopters are using it as a single ingress for agent fleets.
- MCP Dev Summit Tokyo (Sept 10-11) and AGNTCon + MCPCon Europe (Sept 17-18) — both will feature A2A sessions for the first time.
If this was useful, you can support my open-source work on Ko-fi or check out my services.