What changed on 20 August
- A2A and MCP now answer to the same body. On 20 August 2026, Google's Agent2Agent protocol formally joined the Agentic AI Foundation, which is directed by the Linux Foundation and already counts Anthropic's Model Context Protocol among its founding projects. Axios reported the move on 17 August.
- The stack is two layers, not a field of competing drafts. MCP standardises the vertical integration between an agent and its tools and resources. A2A standardises the horizontal one — agents talking to other agents.
- The membership number is the real signal. AAIF grew from 49 members to more than 250 in under a year. Platinum signatories include AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI.
- Governance is necessary, not sufficient. A neutral home removes the risk of unilateral redefinition. It does not produce compatible implementations.
- The actionable material is in the MCP 2026 roadmap: agent identity, progressive discovery, and two new primitives for long-running and delegated work.
Google announced A2A on 9 April 2025, and Google Cloud had already donated the protocol to the Linux Foundation before this month's move. So the headline is not "Google gives away A2A" — that part happened earlier. What happened on 20 August is narrower and, for anyone building integrations, more useful: A2A was placed inside the same foundation that stewards MCP, so both halves of the agent interoperability problem are now governed in one place under one set of rules. The alternative — a protocol war, one vendor's agent bus against another's, with adapters written by whoever drew the short straw — was plausible and expensive.
Two protocols, two axes, one owner
Hold it as a coordinate system: MCP runs down, A2A runs across. MCP answers what an agent asks about itself — what can I reach? Local files, a search index, an enterprise database, enumerated and callable in a uniform way. A London fintech exposing an MCP server over its risk-scoring service is doing exactly this: one integration surface any compliant agent can consume, instead of a bespoke plugin per client framework.
A2A answers a different question: who else is out there, and what will they do for me? Capability discovery, task delegation, and cross-framework and cross-vendor messaging without bespoke integrations. A Bengaluru team wiring an internal reconciliation agent to a separate document-extraction agent — one in LangGraph, one in something else — is solving an A2A problem, whether or not they have heard of A2A.
| Dimension | MCP (Model Context Protocol) | A2A (Agent2Agent) |
|---|---|---|
| What it standardises | The integration between an agent and its tools and resources — local files, search, enterprise databases | Communication between independent agents — capability discovery, task delegation, message exchange |
| Layer | Vertical: agent down to its capabilities | Horizontal: agent across to its peers |
| Typical caller | One agent, or the application host acting for it, reaching a tool server | An agent — increasingly a cloud workload with its own identity — addressing another team's or vendor's agent |
| What it does not solve | Multi-agent coordination, peer delegation, cross-vendor negotiation of who does what | How any individual agent reaches its own data and tools once it accepts the task |
| Governance | Founding project of the Agentic AI Foundation | Joined the Agentic AI Foundation on 20 August 2026 |
The split matters because most teams conflate the two. If you have built an internal endpoint so Agent A can ask Agent B to do a thing, then found you also had to describe B's capabilities, version that description and handle a caller disconnecting mid-task, you have been writing a private, undocumented A2A. Every team writes a different one.
Treat the two layers as separate architectural decisions with separate review criteria. "Which tools can this agent reach, and under whose authority?" is an MCP question. "Which other agents can hand this one work, and what does a completed task look like?" is an A2A question. Answer both in one sprawling service class and you can change neither.
What 250 members actually buys you
AAIF going from 49 members to more than 250 in under a year is the sort of statistic that usually means very little. Here it means something specific, because of who signed and at what level. AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI are platinum signatories — the model labs, the hyperscalers, the edge network most agent traffic will traverse, and organisations whose interest is being a demanding enterprise customer rather than a vendor.
That last group is the one to watch. Bloomberg and Block are not here to sell you an agent framework; they will deploy agents against regulated data and want the audit story settled in the specification, not negotiated per vendor. When buyers of that profile sit at the governance table, the unglamorous parts — identity, delegation, revocation, logging — grow faster.
Neutral governance also changes the risk calculation outside the big platforms. If you are a four-person team in Pune or Bristol betting a product on an agent protocol, the question was never "is this technically good", it was "can the vendor break it on me". A competing-interests board turns that unilateral decision into a public argument you can watch and plan around.
A shared specification is not a shared implementation. Sharing a foundation guarantees A2A and MCP will not be deliberately steered apart; it guarantees nothing about whether your framework's A2A client and someone else's A2A server agree on error semantics, streaming behaviour or task cancellation. Budget integration testing accordingly, and do not let procurement treat "supports A2A" as a binary.
The engineering is in the roadmap, not the announcement
If you read one document off the back of this news, make it the MCP 2026 roadmap published on blog.modelcontextprotocol.io. It sets four priorities: transport scalability, agent communication, governance maturation and enterprise readiness.
Its stated motivation explains the shape of the work: more and more callers are agents running as cloud workloads with their own identity, acting on behalf of a user who is not present, or delegating narrower authority to sub-agents. Every assumption in a browser-centric OAuth flow fails on at least one of those three.
Agent identity and delegation
An Agent Identity Working Group is defining an opinionated path for agent identity and delegation via Workload Identity Federation, with the ID-JAG grant sitting behind Enterprise-Managed Authorization, plus standard token exchange. In plain terms: a workload proves what it is rather than borrowing a human's credential, and when it delegates it mints something narrower instead of passing its own token along. Anyone who read our coverage of the 143,000 findings across 25,000 MCP servers knows why this ranks first — and why the same pressure is pulling nine-figure sums into agent identity.
Progressive discovery
The roadmap describes progressive discovery, where clients, agents, crawlers, browsers and registries all find an MCP server's capabilities through standardised metadata at well-known URLs. Crawlers and registries being on that list tells you the intended end state: a server is discoverable the way a website is, not the way a private API is. That is A2A's capability discovery instinct, arriving at the vertical layer.
Tasks and Triggers
Two new primitives are on the list: Tasks, tracked as SEP-2663, and Triggers, for long-running and delegated work. This is the most consequential item for anyone whose agents pretend everything is a request-response call. A task that runs twenty minutes, survives a disconnect and reports progress is a different object to a tool call, and most teams simulate it today with a hand-rolled job table and polling loop. Our guide to agent handoff contracts and state transfer covers the failure modes it removes.
The latest MCP specification revision is dated 2026-07-28 — the one that went stateless — and the roadmap builds on it. If you are still on an older revision, migrating first is the cheaper order of operations.
Every article here is written by a Verified Builder. Want your name on the next one?
AI Tech Connect lists AI engineers, founders and researchers across India and the UK — and the people hiring browse it to find them. Adding your profile is free.
Become a Verified Builder →Builder angle: what to change this quarter
Nothing here forces a migration. It makes one set of bets cheaper and one set of habits more expensive. Five things worth doing before the quarter closes, whether you build in Bengaluru, Hyderabad, Manchester or London.
- Write down the capability surface of every agent you own. One document per agent: what it accepts, what it returns, what it must never be asked to do. This is the artefact A2A formalises, and it costs an afternoon. Teams that have it adopt the wire format in days; teams that do not spend a quarter discovering what their own agents promise.
- Stop passing tokens through. If Agent A hands its own credential to Agent B, you have already lost the delegation model the roadmap is building towards. Mint narrower credentials per hop now, even manually, so Workload Identity Federation becomes a swap rather than a redesign.
- Model long-running work as an identified task today. Do not wait for SEP-2663 to reach your SDK. If your agent returns a task ID a caller can poll and cancel, you are structurally compatible when the primitive lands. If it blocks an HTTP connection for eleven minutes, you are not.
- Audit what your MCP servers expose before crawlers and registries find them. Progressive discovery via well-known URLs makes capability metadata public by design — good for adoption, unforgiving of servers relying on nobody looking. The vetting checklist for MCP servers and agent skills and the HTTP hardening guide both apply.
- Cull the tools before you connect the agents. Horizontal interoperability multiplies the tools reachable from any agent. If one already struggles to choose among fifty, connecting it to three peers does not help — the fix is retrieval over tool definitions, done before the surface grows.
Adopt the shape of A2A before the wire format. An agent that publishes a machine-readable description of its capabilities, accepts work as an identified task and returns a structured result is already compatible in every way that costs money to change. The transport is the cheap part, and the part most likely to arrive in an SDK upgrade you did not write.
Rewriting a working internal agent mesh purely to be on the standard. If your agents coordinate reliably behind a stable contract, make that contract explicit and A2A-shaped rather than ripping out the transport. Migrate the interfaces you expose to other teams and organisations first — that is where bespoke integrations actually cost you.
What a foundation cannot do
Some honest limits, because the temptation to declare interoperability solved is strong and the evidence does not support it.
A neutral body cannot make two implementations agree. It can publish a specification and shame the laggards, but the SDK you install tomorrow ships on its vendor's schedule. Every widely adopted protocol has a long middle period where the specification is settled and the implementations are not. Expect it here.
Nor does governance settle the competitive question underneath. "We would rather this be a commodity than a competitor's moat" is a rational reason to join a foundation. Commoditising the connective tissue is what everyone downstream wants — but it means the standard's momentum depends on the layer above staying contested.
And a standard for how agents talk says nothing about whether they should. The wider interoperability effort and the competition between agent SDKs both assume more connection is better. In production it often is not: an agent that reaches three peers has three times the surface for a confused delegation to do something irreversible.
Still, the direction is right. Two separated layers, one neutral owner and a roadmap that names identity and delegation as the hard parts beats a protocol war. The engineering has not been done for you; it has stopped moving underneath you, which is most of what a standard is for. A good quarter, then, to write down what your agents promise each other — and to put that work somewhere the people hiring for it can see.