A2A Joins AAIF Alongside MCP—But the Protocol Seam Remains

For organizations running AI agents across multiple vendors and tools, integration challenges often begin with the protocol used to connect them. Which protocol allows agents to interoperate across organizational boundaries? How much of the authentication, authorization, and audit infrastructure required by those connections can be standardized?

Beyond the connection method itself, the protocol’s governance and change process also shape an organization’s long-term dependencies.

A2A Joins AAIF as a Hosted Project

On August 17, 2026, the Agentic AI Foundation (AAIF), hosted by the Linux Foundation, announced that A2A had joined as a hosted project. This places A2A alongside MCP within AAIF’s portfolio of hosted projects: MCP standardizes how agents connect to tools, and A2A standardizes how agents work with one another.

This article examines what that shared foundation makes common, what it leaves to implementers, and why the seam between the two protocols still matters.

What Happened—Getting the Timeline Right

The Linux Foundation announced the formation of AAIF on December 9, 2025. That founding announcement explained that Anthropic contributed MCP, Block contributed goose, a local-first AI agent platform, and OpenAI contributed AGENTS.md, an instruction format for AI coding agents, each as a founding project.

A2A followed a different path. According to AAIF’s official blog, Google published A2A in April 2025 and, together with founding organizations including AWS, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow, donated it to the Linux Foundation. The Linux Foundation announced the launch of the Agent2Agent Protocol Project on June 23, 2025.

In other words, A2A had already moved beyond Google’s sole control and was being governed as a vendor-neutral project under the Linux Foundation well before the August 2026 announcement. Against that background, A2A was welcomed as a hosted project of AAIF on August 17, 2026. This was not a transfer of ownership. Rather, it brought A2A into the same AAIF portfolio as MCP and the other hosted projects.

Official membership figures also show how quickly AAIF has grown. Its founding announcement listed 49 participating organizations. Membership has grown in stages since then, and on August 13, 2026 the Linux Foundation announced that 57 organizations had joined over the preceding three months, bringing the total to 247 organizations. This growth occurred over roughly eight months.

That growth indicates interest in an open, interoperable foundation for agents, and a widening set of organizations willing to take part in shaping the specifications together. Membership counts do not, however, show that those companies have adopted A2A or MCP in production.

Same Foundation, Separate Technical Governance

The easiest distinction to miss is between joining the same foundation and having governance merged into one. What became shared here is a neutral host in AAIF, foundation-level membership, decisions about funding and strategy, and a venue where the projects can coordinate.

MCP’s official announcement explains that the AAIF Governing Board handles strategic investment, budget allocation, member recruitment, and approval of new projects, while each project retains full autonomy over its technical direction and day-to-day operation. It also states explicitly that the Linux Foundation provides a neutral home and infrastructure, and does not direct MCP’s technical direction.

In practice, the mechanisms that decide specification changes and technical direction remain separate for the two protocols. A2A’s current Technical Steering Committee includes representatives from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow. MCP’s technical direction is set by the MCP Steering Group, which consists of Maintainers, Core Maintainers, and Lead Maintainers, and specification changes go through a proposal process called SEP (Specification Enhancement Proposal). MCP’s governance documents state that eligibility for technical governance roles is assigned to individuals, not companies, and that no seats are set aside for particular companies.

Moving under the same roof, in short, is not the same as the specifications merging into one.

Standards Cover More Than Connection Formats

This is another easily misread point, so it is worth being precise. The A2A and MCP specifications do not stop at agreeing on message formats.

A2A’s specification covers the authentication schemes declared in an Agent Card, authorization scopes based on the authenticated identity, OAuth2 scopes, and task cancellation. MCP likewise addresses human refusal of tool calls, confirmation for sensitive operations, server-side access controls and input validation, client-side timeouts, and audit logging for tool use.

AAIF itself runs working groups covering Identity & Trust (delegation, cross-domain identity, movement of privileges between agents), Observability & Traceability (execution tracking, correlation across systems, audit and forensics), Security & Privacy (secure operation, standard best practices, adversarial testing), Accuracy & Reliability (failure management, recovery protocols), and Governance, Risk & Regulatory Alignment (risk classification, alignment with regulation).

Authorization, auditability, and cancellation are therefore within the scope of the protocols and the foundation’s work. Reducing these standards to connection formats would understate their scope.

At the same time, A2A’s specification, while calling for authorization scopes to exist, positions the actual authorization rules—which permissions exist, and who is granted what—as belonging to each agent’s own authorization model.

The mechanism can be made common; what goes into it is decided by each organization.

Tracing the Seam Through a Single Workflow

An abstract dividing line makes it hard to see what to check in practice, so it helps to follow one piece of work from beginning to end. Consider the following multi-agent workflow.

1. Agent A retrieves customer information from a customer management tool over MCP
2. Agent A delegates a research task to Agent B over A2A
3. Agent B uses a different MCP server to carry out an external operation
4. Agent B returns the result to Agent A over A2A
5. Agent A writes an update back to the customer management tool over MCP

The workflow alternates between MCP and A2A, crossing the boundary between them four times. Trouble tends to arise not inside either protocol, but at the seam where the two meet.

In a report from the MCP Developer Summit, AAIF summarizes a session on where MCP ends and A2A begins, highlighting trace visibility, token delegation, schema mapping, and cancellation semantics as issues concentrated at that boundary. The session captured the point in a phrase: “the seam is the system.”

Applied to the five-step workflow above, the practical questions are:

• At step 2, when the task is delegated, how does the identity of the user who started the work carry through to Agent B?
• At step 3, should Agent B be allowed to inherit the original MCP permissions unchanged, or should its access be narrowed to separate credentials?
• Under whose authority is the write at step 5 considered to have been made?
• If the A2A task from step 2 is cancelled midway, does the downstream MCP tool execution running at step 3 stop as well?
• Can the logs from step 1 through step 5 later be correlated as a single unit of work?

What we consider important is that the answers to these questions are not settled by protocol conformance alone. A2A defines how delegation is conveyed, and MCP defines the conventions for tool calls. Neither specification determines how downstream MCP permissions should be narrowed when a task is delegated over A2A. That remains a design decision for the integrating organization.

The same is true of cancellation propagation. A2A has task cancellation, and MCP has its handling of errors and timeouts, but ensuring that an upstream cancellation also stops downstream execution is left to the implementer.

What Standards Provide—and What Organizations Must Decide

Keeping the seam in view, sorting out where the standards’ shared mechanisms end and each organization’s decisions begin produces something like the following. The granularity below is only one example; the specific scope and operational strictness should be decided by each organization according to its operations, risk tolerance, and regulatory environment.

Topic	What standards and the foundation can provide	What each organization decides and implements
Interoperability	Message formats, capability discovery, task delegation, tool connectivity	Which products and counterparties may connect
Authentication and authorization	Authentication schemes, OAuth scopes, Agent Card, authorization-scope mechanisms	Which people and which agents may access which data and perform which operations
Approval	Mechanisms and guidance for requiring human confirmation	Which operations are automated, and at what monetary or risk threshold approval becomes mandatory
Auditing	Common elements for recording tool calls and task state	Retention periods, tamper resistance, viewing permissions, log correlation across systems, who is accountable for review
Cancellation and revocation	Task cancellation, common mechanisms for errors and state transitions	Who can stop it, the scope of a stop, rollback, fail-safe behavior
Cross-protocol observability	Common observability methods and a venue for cross-project discussion	Assigning a unique ID to work spanning A2A and MCP so it can be traced
Conformance	Specifications, SDKs, interoperability requirements	Who verifies that deployed products conform to the specification, and how that is reassessed after updates

As standards provide more shared mechanisms, the implementation burden on individual organizations may decrease. Organization-specific decisions do not disappear, however.

As Standardization Advances: What Gets Easier, What Remains

As the specifications mature, organizations may need less custom integration code for each counterparty. That does not mean the technical problems go away. Cross-protocol implementation challenges—including authentication, tracing, state management, and cancellation—remain. At the same time, organization-specific decisions about what to delegate and under what limits become more visible.

Standardization does not replace technical problems with organizational ones; both remain.

Gathering several projects under one foundation does make it easier to create a venue for discussing security, identity, auditing, and interoperability across projects, and as noted above, AAIF has working groups for that purpose. At present, however, there is no publicly available evidence that this structure has accelerated security response or made individual vendors’ implementations safer. Those are potential benefits, not demonstrated outcomes.

Summary—What Shared Governance Still Leaves Open

AAIF and the individual protocol projects can provide shared mechanisms and guidance for authentication, authorization, auditing, and cancellation. A2A and MCP already address these areas; they do more than define connection formats.

What AAIF does not do is define or enforce each organization’s internal policies: who may use those mechanisms, where human approval is required, and under what conditions processing must stop.

Even with A2A and MCP under the same AAIF umbrella, the integrating organization must still determine how identity, permissions, and cancellation propagate across the seam between them. The shared foundation has expanded. The next question is where each organization sets its operational boundaries.

Sources and Verification

This article was prepared as of August 2026, drawing primarily on official announcements, specifications, and governance documents from AAIF, the Linux Foundation, A2A, and MCP.

The official announcement date for A2A’s participation in AAIF as a hosted project is August 17, 2026. A2A had already been operating under the Linux Foundation since June 2025; the August 2026 announcement did not mark its initial donation to the foundation.

A2A and MCP sit under the same AAIF, but they maintain separate technical governance: A2A through its Technical Steering Committee, and MCP through the MCP Steering Group.

The figure of 247 member organizations is based on the Linux Foundation’s August 2026 announcement regarding new members. The discussion of the seam between MCP and A2A draws on AAIF’s report on the MCP Developer Summit in Bengaluru.

Membership numbers, governance structures, how each project is run, and the content of the specifications may change.

The three-part framework used in this article—foundation-level governance, protocol specifications and technical governance, and organization-specific policies and operations—is MIF’s own analysis. The seam-related questions are also MIF’s analytical framework.