The Agent2Agent Protocol, Google's open standard for AI agents to talk to one another, moved to the Agentic AI Foundation this week. That puts it under the same neutral governance as the Model Context Protocol - the same foundation, the same membership roster, the same release pipeline. If you are building anything that involves more than one agent, this is the most consequential infrastructure decision of the past month.
But "two protocols now share a foundation" is the headline. The harder question is what that actually changes for a team shipping agents today - and the honest answer is less than the announcement implies, and more than most coverage says.
What the A2A move to AAIF actually does
A2A handles communication between independent agents; MCP handles connections between AI applications and tools and data. They were always complementary. What was missing was a shared governance structure that would let both protocols evolve in coordination. This shift consolidates cross-agent communication and tooling standards in a single organization focused on agentic AI rather than the broader Linux Foundation portfolio.
From its launch in December 2025, the Agentic AI Foundation says it has grown from fewer than 40 members to more than 250, with key backers including Google, Microsoft, Amazon, Anthropic, OpenAI, Bloomberg, Shopify, and Block. That breadth matters for a different reason than you might think: it makes the foundation hard for any single vendor to steer. When one company controls a protocol, every implementation decision is also a competitive decision. Under neutral governance, breaking changes require broader consensus, which is slower but more predictable.
A2A v1.0, the first stable specification, shipped in March 2026 and added multi-protocol bindings, version negotiation, multi-tenancy, and signed agent cards for cryptographic identity verification.
IBM's Agent Communication Protocol merged into A2A in August 2025, showing the field was moving toward a single shared standard rather than competing ones. The consolidation at the AAIF is the governance layer catching up to what the ecosystem had already voted for with its feet.
What a shared envelope does not fix
This is where most coverage stops, and where the real work begins.
A common envelope still leaves hard questions about authentication, authorization, capability discovery, task ownership, cancellation, data classification, and audit evidence. A2A tells two agents how to find each other and exchange structured messages. It does not tell you who is accountable when an agent delegates a task to a subagent and that subagent calls a tool that modifies production data. That accountability chain is your architecture problem, not the protocol's.
The official A2A project provides SDKs for Python, JavaScript, TypeScript, Java, Go, C#, and Rust, plus an inspector and a technology compatibility kit - making conformance testing a more credible adoption gate than a demo where two agents exchange a message. That conformance kit is worth reading before you wire anything to production. Two agents that both claim A2A compliance can still disagree on how they handle task cancellation mid-flight, because the spec's cancellation semantics are defined but not tested end-to-end across vendor boundaries yet.
The MCP stateless spec ships the same week - and that is not a coincidence
While A2A was moving foundations, MCP published its largest revision since launch. The highlight of the 2026-07-28 release is a stateless protocol core: MCP is transforming from a bidirectional stateful protocol into a request/response stateless protocol.
In the previous spec, a remote MCP server needed sticky sessions, a shared session store, and deep packet inspection at the gateway to route requests to the right instance. In 2026-07-28, any server instance can handle any request. The practical result: an MCP server can now run behind a plain round-robin load balancer, with no sticky routing and no shared session store.
That matters directly for teams combining A2A with MCP. In a multi-agent system, a coordinator agent (communicating via A2A) delegates tool calls to specialist agents (which call tools via MCP). Under the old stateful MCP, every specialist needed its own sticky session infrastructure - a meaningful operational burden when you have five specialists, a serious one when you have twenty. Under the stateless spec, those specialists become ordinary HTTP services you can autoscale normally.
The deeper shift is that MCP stopped being a transport-flavoured protocol and became an HTTP-flavoured one. That means the boring, battle-tested layer of the web now applies to agent tooling: CDNs and the full web infrastructure stack.
| Layer | Protocol | What it solves | What it leaves open |
|---|---|---|---|
| Agent ↔ Agent | A2A | Discovery, delegation, task exchange | Cancellation, partial state, cross-org auth |
| Agent ↔ Tool | MCP 2026-07-28 | Stateless tool calls, OAuth/OIDC hardening | Prompt injection, supply-chain trust |
| Auth everywhere | OAuth 2.1 / OIDC | Token binding, issuer verification | Who owns the token when agents chain |
| Governance | AAIF | Neutral spec ownership | Adoption rate across vendor implementations |
What to do with this if you are shipping agents
The short version: treat this week's moves as a buying signal for the protocol stack, not a reason to pause current work.
If you are building multi-agent systems now, the practical steps are:
- Map your task boundaries. Decide which coordination problems are agent-to-agent (A2A territory) and which are agent-to-tool (MCP territory). Mixing them in a single bespoke layer is the thing you are trying to escape.
- Read the A2A conformance kit before a vendor demo. A2A 1.0 adds multitenancy, protocol negotiation, and signed agent cards designed to strengthen enterprise deployment and identity verification
- but "supports A2A" in a sales deck can mean anything from full v1.0 conformance to an HTTP endpoint that returns JSON.
- Migrate MCP servers to the stateless spec deliberately. Deploy multiple server instances behind a round-robin load balancer and run your test suite. Any test that fails has a hidden session dependency you missed. That is the migration audit in one sentence.
- Design the accountability chain explicitly. The practical response is to design contracts explicitly: identity, permissions, task state, and failure handling for agent connections. A2A provides the vocabulary; the contracts are yours.
A teammate like Beagle operating inside Slack sees this layer as infrastructure, not product - the same way a Slack integration does not expose the OAuth flow to the user. What matters is that the delegation chain is auditable and that a human can see what any agent did and why, before the result posts to a channel.
Beagle in action#eng-infra, Thursday morningA2A protocol multi-agent interoperability: common questions
What is the difference between A2A and MCP?
The Agent2Agent protocol addresses a different problem than MCP. Where MCP connects an agent to tools and data, A2A connects one agent to another. In practice, most multi-agent systems need both: MCP so each agent can call tools, A2A so agents can delegate tasks to each other across vendor and framework boundaries.
Why did A2A move from the Linux Foundation to the Agentic AI Foundation?
A2A moved from the Linux Foundation's broader portfolio into AAIF, a foundation focused specifically on agentic AI. The practical effect is that A2A and MCP now share governance, release coordination, and a membership base - making it easier to evolve the two protocols without introducing incompatibilities between the agent-to-agent and agent-to-tool layers.
Does the MCP 2026-07-28 stateless spec break existing servers?
It is a breaking change, but a manageable one.
The 1.x line moves to maintenance mode with security fixes only, so if you're not ready, pin mcp>=1.28,<2 and come back to it.
The key breakage is the removal of Mcp-Session-Id: any server that relies on session pinning for state will need to move that state to the application layer.
Is A2A actually in production anywhere?
A2A is already running in production across mobile platforms, cloud AI infrastructure, financial services, supply chain, and enterprise IT. The conformance story is thinner - many deployments call themselves A2A-compatible without having run the technology compatibility kit - but production adoption is real.
What does a common protocol standard mean for vendor lock-in?
Putting A2A alongside MCP and related projects could help push the industry toward more modular, model-agnostic AI systems, giving companies more flexibility to choose providers based on cost, performance, latency, or other needs. The qualifier is that standards lower switching costs only when vendors implement them fully and conformance is verified - neither of which is guaranteed yet.