Do MCP and A2A really compete? No, and here is why

MCP and A2A do not compete. MCP connects an agent to tools and data. A2A lets separate agents delegate and coordinate with each other. Both now sit under the Agentic AI Foundation (AAIF), a vendor-neutral open source foundation that hosts the protocols along with Goose and AGENTS.md, which turns the two into complementary layers rather than rivals.

The person making that case most directly is Manik Surtani, AAIF co-founder, speaking on Dev Interrupted in October 2026. His argument is about governance as much as about protocol design: once two projects share a neutral steward, the question of which one wins stops being a question about where the projects came from.

MCP and A2A in one neutral foundation

MCP and A2A are separate protocols with complementary jobs, and both are now hosted by the Agentic AI Foundation, a vendor-neutral open source foundation that Surtani helped launch. MCP, the Model Context Protocol that Anthropic introduced, lets an agent call tools and read data. A2A, the Agent-to-Agent protocol that originated at Google, lets distinct agents delegate and coordinate.

Surtani described A2A as already a Linux Foundation project before it joined the foundation, which meant governance and open-source processes were in place. A2A was contributed to the Linux Foundation in 2025, before the AAIF existed. That matters because the harder work of neutral governance had already been done, so bringing A2A into the AAIF was mostly incorporation rather than reform.

He pushed back on the idea that MCP and A2A compete. In his account they address different problems and only overlap at the edges, and where they do overlap they borrow ideas from each other. He treats that borrowing as healthy. The current MCP specification and the A2A protocol documentation live in separate project spaces under the same umbrella.

The governance point goes beyond protocol rivalry. Surtani said the foundation is not an Anthropic foundation, even though MCP is the project most people associate with it. A2A arriving from Google is the proof: a project can enter, keep its own maintainers and working groups, and sit next to a protocol from a different company without either being subordinated.

The visible result is a single foundation holding MCP, A2A, Goose and AGENTS.md. Whether that reduces confusion for practitioners is a separate question from whether the governance is neutral, and the transcript offers the foundation's own view rather than independent measurement of adoption effects.

Why Goose needed a neutral home first

Goose, Block's open-source AI agent, drove the creation of the foundation because distributors would not package an Apache-licensed tool whose roadmap sat inside a single company. Surtani was leading open source at Block when Goose launched, and he describes competitors and distributors such as Red Hat stopping short of redistribution for exactly that reason.

The objection was not the license. Apache licensing already permitted redistribution. The objection was trust in the roadmap: without neutral governance, a downstream distributor could not rule out a rug pull, a change of direction imposed by the originating company after the distribution work was already done.

Moving Goose to a foundation addressed that concern directly, and Surtani reports that Goose adoption grew after the foundation was created, which he treats as expected. The Goose repository remains the canonical source for the project's current state, and its current position under foundation governance should be checked there rather than assumed from a 2026 interview.

His broader claim is that neutral governance is a distribution unlock. That is a plausible mechanism supported by the Goose case, but it is one project's experience, not a general law about open-source adoption.

What the fivefold MCP download figure does and does not show

MCP SDK downloads grew roughly fivefold in the eight months after the foundation was created, reaching over a billion downloads according to Surtani's October 2026 account. The figure describes SDK downloads across the project's packages, not production deployments, active users, or tool calls served.

Downloads accumulate across package versions, CI installs, container builds and mirrors, so a fivefold rise measures distribution reach rather than proven adoption inside running systems. Enterprise adoption numbers, agent-to-tool call volumes and retention are not addressed by that metric.

The comparison Surtani makes is against MCP's own earlier baseline, when he describes it as already by far one of the most popular projects and protocols available. His expectation that A2A follows a similar curve is a forecast from the foundation's co-founder, not a measured result. He also names Agent Gateway as another project showing fast growth inside the foundation.

The stated state of MCP in October 2026 is a widely downloaded protocol with a neutral steward. Anyone citing the billion figure should attach it to the SDK download metric and the date, rather than to claims about production usage.

Where A2A adoption looks different

A2A adoption is not evenly distributed, and the difference is structural. Surtani points to heavy A2A uptake in China on mobile devices, where apps carry their own built-in agents that need to discover each other and talk. In the west, the more common pattern is corporate workloads exposing SaaS systems, server-side systems or custom internal systems to agents.

That changes why teams reach for A2A. A data-centric workload mostly needs an agent to reach a tool, which is MCP work. An app-centric workload with many agents living side by side needs agent-to-agent discovery and handoff, which is A2A work. The protocols are not substitutes in either case; the deployment context decides which one carries the weight.

The scale difference is hard to overstate. Surtani describes Chinese teams running what they consider a small beta experiment across 40 million users, a distribution base that changes how protocol decisions get tested.

Statelessness and the operational shape of MCP

MCP became stateless at the protocol level in its 2025-07-28 specification revision, which simplified deployment by removing session handling from the server contract. Surtani framed the revision as a response to community pain around serving MCP servers at scale inside existing services, and he credits the MCP project's closeness to its community for catching that pain early.

Stateless protocol does not mean stateless systems. State still has to live somewhere, and in practice that responsibility moves into the application or gateway layer. Surtani called that a good place to manage state, since the application already knows the user, the request and the business rules. What the protocol stops guaranteeing, the surrounding system has to track explicitly.

The practical consequence is easier packaging and deployment of MCP servers, plus a clearer split between what the protocol guarantees and what the surrounding system must track. Teams that previously struggled to serve stateful MCP servers embedded in existing services get a simpler deployment story. The MCP changelog records the exact change set, and teams still running stateful assumptions should read it before upgrading.

Choosing between MCP, A2A and agent skills

Choose MCP when an agent needs to read data or invoke a capability; choose A2A when separate agents need to delegate or coordinate; choose an agent skill when the reusable unit is instructions plus procedure. The three address different boundaries rather than competing for one slot. Surtani describes the whole area as a wild west with no standardized answer, which means teams are free to combine the options rather than pick one.

The comparison below reflects the roles Surtani described in the October 2026 interview, together with the projects' current documentation. It does not measure performance, and no benchmark in the transcript compares them.

Option	Primary role	Typical unit	Main limitation
MCP	Agent to tool or data access	Server exposing tools and resources	Not designed for agent-to-agent delegation
A2A	Agent to agent coordination	Agent card and task handoff	Still building adoption outside early regions
Agent skill	Reusable procedural knowledge	Instructions plus assets	Not a transport or access protocol
Agent gateway	Central routing and observability	Proxy in front of model calls	Adds a hop the team must operate

Surtani describes a common internal pattern: one department builds agents, another wants to tap into them, and the team has to decide how the pieces interop. His answers are that each department can keep its own agents and use A2A to coordinate, or encode the department's know-how as an agent skill others can pick up, or expose data endpoints as MCP endpoints. A team that starts with MCP endpoints and adds A2A coordination later is following the sequence most of these projects describe.

When to sunset your own protocol

The complement to choosing a standard is knowing when to abandon your own. Surtani gives the example of a Cisco-backed consortium that built a protocol called ACP. It was in production use and had absorbed real engineering effort. When A2A arrived, the people behind ACP judged it close enough in purpose that they sunset their own protocol, moved their resources over and joined the A2A project instead.

His general advice follows from that case. Experiment freely, but do not marry a particular approach, and be ready to drop one when another has more momentum. The reverse also happens: other teams sunset their work and join yours, which counts as a win for the ecosystem either way.

Where the tooling gap still sits

Surtani argues that today's developer tooling is still built for human-scale pull requests and lacks the audit and coordination primitives a software-factory workflow needs. The missing pieces he names span code hosting, adversarial agent collaboration, identity, permissions and verifiability.

The gap shows up in concrete places:

• Code hosting built for human scale. Surtani asks whether GitHub is still the right answer when the unit of work is no longer a human-sized pull request, and says the rebirth of the git forge is overdue because the problem has changed.
• Provenance of prompts. He wants tooling that records which prompts produced a given outcome, not just which diff landed.
• Adversarial agents. He describes a forge where multiple agents backed by different models attack the same problem, critique each other and converge on the best answer, with a readable audit trail of what each considered and dropped.
• Security and identity. Who is allowed to do what, with short-lived tokens and revocable access that can be reassigned at any point.
• Deployment and runtime. Building software is only half the problem; running it with the right access levels and audit trails is a separate area that needs work.
• Verifiability. Tracing whether an action rested on real information, and rolling back when it did not.

Code review is where the gap bites hardest today. Surtani describes organizations where code generation runs automatically and an author signs off without reading the output, which makes a second human review hard to justify. His proposed trade-off: let an AI do the review, provided the author actually read and approved their own generated code, and find a way to hold that author accountable. He also notes that some projects, Goose included, have stopped accepting pull requests and ask for detailed issues instead, on the argument that a PR is mostly a conduit for someone else's tokens while the idea is the real contribution.

On the software factory itself, Surtani is bullish on the direction and clear that it is not here yet. He sees it working in narrow pockets, with domain experts at the front and verification at the end, and engineers becoming the people who build the factory rather than the people who write every line. His analogy is the move from machine code to high-level languages: the people writing machine code thought the higher level was a dumbing down, and it turned out to be a necessary step for scale.

Practical takeaways for teams

• Pick the boundary, not the brand. If the unit of work is a tool call, MCP is the fit. If it is coordination between agents, A2A is.
• Treat neutral governance as a procurement signal. A protocol under a vendor-neutral foundation answers the roadmap question that a distributor cannot answer for a single-company project.
• Read the 2025-07-28 changelog before upgrading MCP servers that assume sessions. Decide where state will live, because the protocol no longer holds it.
• Measure at the layer you control. Route model calls through a gateway to get token spend and metadata per request, and pin tasks to inference calls so cost can be traced to work. Surtani describes one setup where pinning tasks to gateway requests showed where spend concentrated, which made the next question obvious.
• Watch model independence. The best model for a task today may be a different vendor's model tomorrow, so avoid coupling your agent stack to one provider.
• Be willing to sunset. The Cisco ACP case shows the cheaper move is often to join the project with momentum.

FAQ

• Do MCP and A2A actually compete? No. MCP gives an agent access to tools and data, while A2A lets separate agents delegate and coordinate. Surtani says they address different problems, overlap only at the edges, and borrow ideas from each other where they do.
• Who owns MCP and A2A now? Both sit under the Agentic AI Foundation, a vendor-neutral open source foundation. A2A originated at Google and became a Linux Foundation project in 2025 before joining the AAIF; MCP was introduced by Anthropic is now hosted in the same foundation.
• What did the 2025-07-28 MCP revision change? It made MCP stateless at the protocol level, removing session handling from the server contract. State moves to the application or gateway layer, which simplifies deployment but does not remove the need to manage state.
• What does the billion MCP downloads figure measure? SDK downloads across the project's packages, up roughly fivefold in the eight months after the foundation was created. It does not measure production deployments, active users or tool calls served.
• Why did Goose need a foundation rather than just an open license? Apache licensing already allowed redistribution, but distributors such as Red Hat would not ship a tool whose roadmap sat inside one company. Neutral governance removed the rug-pull risk.

Sources and further listening

The main source for this article is Surtani's October 2026 interview on Dev Interrupted. For the protocols themselves, start with the MCP specification, the 2025-07-28 changelog and the A2A protocol documentation. The Goose repository is the place to check the project's current governance and release state.

If protocol comparisons like this one are useful to you, the same careful reading applies to any technical interview: Gustavo dev doido has made the point that the value in a long conversation sits in the specific claims and the conditions around them, and that is exactly what a written article can preserve.

Turning a recorded conversation into something readable is the step most teams skip. Skala Blog takes a YouTube URL, transcribes the video and generates an article from it, so the explanation you already recorded can be read, cited and found later.