The immediate change
A protocol is becoming infrastructure
Axios reported on August 17 that the Agent2Agent protocol, better known as A2A, is moving from the Linux Foundation's broader project portfolio into the Agentic AI Foundation, or AAIF. A2A was created by Google in 2025, transferred to Linux Foundation governance later that year, and has since grown into a multi-vendor interoperability project. The Linux Foundation said in April that more than 150 organizations supported the protocol and that it had integrations across major cloud platforms.
The latest move does not change what A2A is overnight. It changes the institutional neighborhood around it. AAIF was created as a focused home for open agent standards and infrastructure; its membership now spans model providers, cloud companies, security firms, payment companies, public-sector bodies and enterprise software vendors. A2A joins an ecosystem where the Model Context Protocol, agent gateways and related projects are increasingly being treated as shared infrastructure rather than as features owned by one application vendor.
That is the more consequential story. The first generation of AI applications was built around a model endpoint: send input, receive output. Agentic systems add tools, state, long-running tasks, permissions and other agents. Once several independently built agents have to cooperate, the problem starts to resemble service integration. They need to find one another, describe capabilities, exchange structured messages, keep track of tasks and agree on how calls are authenticated. The protocol layer stops looking optional.
This is not evidence that a universal "agent internet" has arrived. Adoption claims come largely from the organizations building the ecosystem, and production use is still uneven. But the direction is clear enough to matter: agent interoperability is moving from a framework feature toward a standards problem.
What A2A actually standardizes
A2A is not a new reasoning algorithm and it does not make a weak model more capable. It defines a common way for independent agent applications to interact even when they use different models, frameworks or internal tools.
The protocol's basic unit of discovery is an Agent Card: a machine-readable description of an agent's identity, endpoint, supported interfaces, skills and security requirements. A client can use that card to decide whether another agent appears able to perform a task and how to contact it. The current specification also defines task operations, messages, artifacts, streaming behavior, protocol-version negotiation and multiple transport bindings.
The distinction between an agent's interface and its internals is important. A2A is designed so one agent does not need access to another agent's private chain of reasoning, memory or tool configuration. The remote agent can remain opaque while exposing a stable contract for what it can do. That is closer to how organizations already integrate payment services, cloud APIs or enterprise software: use a defined interface rather than inspect the service's internal implementation.
It also makes long-running work a first-class concern. A useful agent task may take minutes, involve several exchanges, produce intermediate artifacts or require cancellation and resumption. Those behaviors are awkward to model as a single chat message. A protocol that distinguishes messages from tasks gives infrastructure providers something concrete to route, log, authorize and observe.
The engineering trade-off is that standardizing the envelope does not standardize the meaning. An Agent Card can say an agent has a "procurement" skill, but A2A does not guarantee that every vendor interprets that skill the same way, that the agent will obey a spending policy, or that the result is correct. Semantic compatibility remains a higher layer.
A2A and MCP solve different boundaries
A2A is often mentioned beside the Model Context Protocol, and the comparison is useful as long as the two are not collapsed into one thing.
MCP primarily standardizes the boundary between an AI application and external tools, resources or data. An agent may use MCP to query a database, read documents, call a business system or invoke a specialized tool. A2A focuses on communication between independent agent applications. One agent can delegate work to another without treating the second agent as a low-level function.
A simple example makes the distinction clearer. A travel-planning agent might use MCP to query calendars, maps and booking systems. It could then use A2A to ask a separate corporate-policy agent whether the itinerary satisfies company rules. The policy agent may itself use MCP to read an internal travel policy. A2A coordinates agent-to-agent work; MCP connects an application to capabilities and context below it.
The two protocol families are also converging on ordinary internet infrastructure rather than inventing an entirely separate network stack. The July 28 MCP specification moved toward a stateless core that can sit behind normal load balancers and gateways. A2A similarly relies on familiar web and enterprise security mechanisms, with encrypted transport, standard authentication schemes and server-side authorization. That choice matters because the path to production usually runs through existing identity providers, API gateways, observability systems and security controls.
The emerging stack is therefore less exotic than the "autonomous agents talking to each other" language suggests. Underneath the model calls, it increasingly looks like a distributed application with standardized interfaces.
Agent systems are rediscovering distributed-systems problems
Once agent workflows cross process, vendor and organizational boundaries, familiar systems questions return in a new form.
Discovery: which service should receive the task, and how does the caller know its advertised capability is current? Versioning: what happens when one side speaks an older protocol or uses a different extension? State: where does a long-running task live if a server restarts? Retries: can a repeated request create duplicate side effects? Cancellation: what does it mean to stop a task after one of several delegated agents has already acted? Observability: which system records the path when a task moves across multiple agents?
These are not problems that better natural-language reasoning solves on its own. They require protocols, state machines, logs and operational conventions. That is why AAIF's project mix is revealing. The foundation is not only hosting message specifications. It is also attracting gateway infrastructure designed to route MCP, A2A, model and ordinary API traffic through common controls for security, observability and policy.
This changes the unit of AI engineering. The question is no longer simply which model generated the best response. A production workflow may depend on a model, an agent runtime, an A2A client, another vendor's agent, several MCP servers, an identity provider and a gateway. Reliability becomes a property of the path through that system.
AIUpdateWatch's recent analysis of AI evaluation beyond static benchmarks reaches the same conclusion from the measurement side: once agents interact with tools and state, evaluating only the final answer omits much of the system being tested.
Interoperability does not create trust
The most important misconception around an open agent protocol is that successful communication implies safe delegation. It does not.
The A2A specification is explicit about where its responsibility ends. Production deployments are expected to use encrypted transport. Agent Cards can declare authentication schemes, including OAuth, OpenID Connect and mutual TLS. Servers must authorize requests and scope resources to the caller's permissions. Agent Cards can also be signed so clients have a way to verify integrity.
Those are necessary controls, but they do not answer the hardest authorization question: what authority should travel when one agent delegates to another? A user may authorize an assistant to read invoices but not approve payments. That assistant may ask a finance agent to reconcile the invoices. If the finance agent then calls another service, the system must preserve the original limits instead of silently expanding them.
This is a delegation problem, not merely a login problem. Authentication can establish who is calling. Authorization can define what that caller may do. Multi-agent workflows must also preserve why the authority exists, on whose behalf it is being exercised, how far it may be delegated and which actions require fresh human approval.
Research proposals are already exploring that gap. A 2026 preprint on an Agent Identity Protocol, for example, proposes cryptographically verifiable delegation chains across MCP and A2A. The paper should not be treated as an adopted standard, but its existence is evidence of a real missing layer: common transport does not automatically carry trustworthy provenance of authority.
The same boundary appears after the action. AIUpdateWatch's runtime-verification analysis argues that an agent's claim of completion should not be accepted without evidence from the system that actually changed. A2A can standardize how one agent asks another to do work. It does not prove that the work was correct, policy-compliant or complete.
Why neutral governance matters
Open standards only reduce lock-in if no single vendor can redefine them around its own platform faster than others can participate. That is why governance is part of the technical story.
Google launched A2A with more than 50 partners in April 2025 and moved it to the Linux Foundation two months later. The protocol's subsequent shift into AAIF keeps it within Linux Foundation governance but places it inside a body whose explicit purpose is agentic interoperability. AAIF said in May that it had reached 190 member organizations after adding another 43 members.
Membership counts do not guarantee balanced influence. Large cloud and model providers still have more engineering resources than smaller participants, and a standard can be technically open while the most useful implementations remain tied to proprietary platforms. But neutral governance creates a forum where competing vendors have at least some incentive to preserve common interfaces.
The strategic value is easy to underestimate. If a protocol becomes widely implemented across enterprise platforms, vendors can compete on model quality, workflow design, security, cost and domain expertise without forcing customers to rebuild every connection when one component changes. That is the same economic logic that made internet and cloud standards valuable long before every implementation was perfect.
The enterprise value is optionality, not autonomy
Most organizations should care less about whether agents can form elaborate autonomous teams and more about whether a protocol reduces integration cost and switching friction.
A company that uses one vendor for CRM, another for productivity software, a third for cloud infrastructure and several specialized AI systems is unlikely to standardize everything on one agent framework. If those systems can expose interoperable agent interfaces, the company can build workflows without writing a bespoke connector for every pair of products.
That is a form of optionality. A specialized agent can be replaced without redesigning the entire workflow if the replacement speaks the same protocol and meets the same operational contract. Procurement teams gain leverage because interoperability lowers some switching costs. Security teams gain a smaller number of protocol surfaces to inspect. Platform teams can centralize routing and telemetry instead of scattering custom integrations across business units.
None of this requires the agents to be fully autonomous. In fact, the most valuable deployments may keep humans or deterministic services at consequential boundaries. A protocol is useful even when one agent only prepares a case, another checks a policy and a person approves the final transaction.
That framing also connects to AIUpdateWatch's analysis of the verification bottleneck in AI-assisted software delivery. Increasing the number of agents that can produce work is only beneficial if the organization can still verify, govern and integrate the resulting output.
Standards can spread failure as well as compatibility
A common protocol creates leverage in both directions. A successful standard can make a useful agent available everywhere. It can also make a flawed assumption, weak security pattern or compromised component reachable from many systems.
Discovery is one example. Publishing machine-readable Agent Cards makes integration easier, but cards can expose sensitive capabilities if organizations publish too much information. The A2A documentation therefore recommends access controls for sensitive cards and warns against placing static secrets inside them.
Chained delegation creates another risk. If credentials or user context are passed across several agents, each hop becomes part of the trust boundary. The specification warns that in-band credential exchange can expose credentials across a chain and recommends stronger binding and protection where such flows are used.
Protocol compatibility also says nothing about operational quality. Two agents can be perfectly interoperable and still disagree about task semantics, mishandle cancellation, retry an irreversible action twice or return artifacts that the calling system cannot safely validate. A standard can define the grammar of cooperation without defining every business rule.
This is why the agent stack is likely to need more than A2A and MCP. Identity, policy, gateways, evaluation, provenance, audit and human approval all remain separate layers. The architecture becomes more modular, but modularity transfers responsibility to the contracts between modules.
What would prove this layer is maturing?
The most meaningful signals over the next year will be operational rather than promotional.
First, watch whether vendors support the same stable A2A versions in products that customers actually deploy, not only in demonstration environments. Compatibility suites and reproducible conformance tests will matter more than the number of logos on a partnership page.
Second, watch delegated identity and authorization. Mature multi-agent systems need a reliable way to preserve user intent and least privilege across several hops. If every platform invents a proprietary answer, communication may be standardized while trust remains fragmented.
Third, watch observability. Enterprises will need to reconstruct who delegated a task, which agent accepted it, which tools were used, what state changed, what evidence supported completion and where a failure occurred. A multi-agent workflow that cannot be traced end to end will be difficult to operate in finance, healthcare, government or other regulated settings.
Finally, watch whether open standards actually preserve substitution. The strongest evidence for interoperability will not be two friendly demos exchanging messages. It will be an organization replacing one agent provider with another while keeping the surrounding workflow, security controls and audit system substantially intact.
A2A's move into AAIF matters because it places one important protocol inside the institution trying to build that shared stack. The protocol can make agents easier to connect. The industry still has to prove that easier connection produces systems that are governable, observable and safe to trust.
Primary and independent evidence
Sources
- Axios — Google-backed agentic A2A protocol gets a new home, August 17, 2026.
- A2A Protocol — current specification.
- Google Developers Blog — Announcing the Agent2Agent Protocol, April 9, 2025.
- Linux Foundation — launch of the A2A project under neutral governance, June 23, 2025.
- Linux Foundation — A2A one-year adoption update, April 9, 2026.
- Linux Foundation / AAIF — membership and open-agent standards update, May 18, 2026.
- Model Context Protocol — 2026-07-28 specification release, July 28, 2026.
- Agentic AI Foundation — agentgateway joins AAIF, June 4, 2026.
- Prakash — AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A, March 2026 preprint.
Evidence note: The August 17 AAIF move is reported by Axios based on the protocol's backers. The A2A specification, Linux Foundation releases, Google announcement, MCP documentation and AAIF materials are primary ecosystem sources and are used for protocol design, governance and adoption claims. The AIP paper is a preprint and is cited only as an example of active work on delegated identity, not as an adopted standard.