A2A Joins the Agentic AI Foundation—MCP Still Solves a Different Problem

In its August 17, 2026 announcement, the Agentic AI Foundation said Agent2Agent (A2A) was joining as a hosted project. The foundation describes A2A as an inter-agent communication standard supported by more than 150 organizations, with discovery, task delegation and work exchange across framework and vendor boundaries among its core functions.

The move gives A2A the same specialized governance home as the Model Context Protocol (MCP), but it does not combine their specifications or make them interchangeable. Axios’s August 17 report independently documented A2A’s transfer from the Linux Foundation’s broader portfolio and summarized the boundary: MCP connects AI applications to tools and data, while A2A connects independent agents.

A governance move, not a protocol merger

A2A was already under the Linux Foundation, so the change is primarily organizational. It places the protocol inside a foundation focused specifically on agentic infrastructure, alongside projects that address neighboring parts of the technology stack.

No merged A2A-MCP specification was introduced as part of the move. Neither protocol was made dependent on the other, and their message formats were not unified. Shared stewardship creates a common setting for maintainers to discuss roadmaps, boundaries and integration, but it does not automatically produce compatible implementations.

For enterprise adopters, that distinction defines the practical effect of the news. Neutral governance can reduce dependence on the roadmap of a single vendor and give competing organizations a shared venue for development. Actual interoperability still depends on specifications, conforming software, security controls and testing across the systems expected to communicate.

The open agentic stack keeps responsibilities separate

The foundation’s project map separates several responsibilities that are often compressed into the phrase “agent interoperability.” AGENTS.md carries project-level instructions and conventions. goose provides a runtime in which an agent can reason, plan, invoke capabilities and perform work.

MCP covers connections from AI applications to tools, data sources, applications and services. agentgateway occupies an infrastructure boundary concerned with routing, policy and observability. A2A addresses communication between independently operated agents, including capability discovery, delegation and the exchange of task results.

These layers may participate in the same workflow without becoming one protocol. Instructions do not supply a runtime; a runtime does not standardize every external connection; a traffic gateway does not define the working relationship between autonomous agents. A2A’s new home makes the layers easier to coordinate institutionally while preserving those technical divisions.

When a system needs MCP, A2A or both

MCP fits an interaction in which an AI application needs standardized access to an external capability or source of context. The remote endpoint exposes tools, resources or data that the application can use. The application remains responsible for deciding how those capabilities contribute to its work.

A2A models a different relationship. The remote participant is an independent agent that advertises capabilities, accepts delegated work and can manage a task across an agent boundary. It may operate on another framework, belong to another vendor or organization, and retain control over how it completes the assignment.

The protocols are therefore not always an either-or choice. In a conditional enterprise workflow, a coordinating agent could use MCP to retrieve approved records from a business system, then use A2A to delegate specialist analysis to an independently operated agent. The MCP interaction obtains a capability or context; the A2A interaction assigns responsibility for work.

Some systems will need only one layer. An assistant that calls approved tools but never delegates to another autonomous system may use MCP without A2A. A federation of independently managed agents may use A2A for cross-system assignments even when each participant relies on different internal mechanisms for tool access.

What adopters must still implement

The expanded project portfolio is not a complete enterprise agent platform. Engineering teams still have to select runtimes, define instructions, connect tools and data, enforce traffic policies and decide which tasks may cross an agent or organizational boundary. Identity, authorization, monitoring, retries, cancellation and failure recovery remain deployment responsibilities.

Teams must also decide whether a remote component should be treated as a callable capability or as an autonomous participant responsible for delegated work. That decision depends on who controls execution, how progress is represented, which side handles failure and whether the caller expects a direct response or a managed task lifecycle.

At present, the confirmed change is narrower than protocol consolidation: A2A now sits alongside MCP and other components within the Agentic AI Foundation, while the protocols retain separate roles. The next meaningful evidence of deeper alignment would be technical—such as joint integration guidance, conformance tests or interoperable tooling—and those additions were not part of the hosting change.