Interoperability Standards for AI Agents: The Quiet Power Struggle Over Who Controls Them

Table of Contents

• Why Interoperability Is the Whole Ballgame for GaaS
• The Standards That Actually Matter Right Now
• MCP: The Tool-and-Context Layer
• A2A: The Agent-to-Agent Layer
• The Long Tail: OpenAPI, ACP, and Vendor SDKs
• Who Actually Controls These Standards
• The Governance Gap: "Open" Is Doing a Lot of Work
• How This Plays Out: Fragmentation Before Consolidation
• What Operators Should Actually Do
• Insights Most People Overlook
• References

Why Interoperability Is the Whole Ballgame for GaaS

Strip away the demos and the agentic AI-as-a-service pitch comes down to a simple bargain: you pay per task or per outcome, and in exchange a vendor's agent reaches into your systems, does the work, and reports back. That bargain quietly assumes the agent can connect to your CRM, your ticketing system, your data warehouse, and, increasingly, to other agents, without you writing a custom integration for every pairing.

That assumption is doing enormous load-bearing work, and it is the thing most likely to break.

Consider the combinatorics. If you have ten agents and they each need to talk to twenty tools, the naive approach is two hundred bespoke integrations, each with its own auth, its own error semantics, its own brittle JSON shape. Add a second vendor's agents to the mesh and the number explodes. This is the same n-times-m problem that drove the adoption of USB, of HTTP, of the shipping container. Interoperability standards exist to turn that multiplication into addition: build to the standard once, connect to everything that speaks it.

The catch is that whoever defines the standard defines the terms of the entire market. In the GaaS world, that power is concentrated in exactly the companies whose models you are renting. That is the tension this piece is about, and it connects directly to the broader infrastructure questions in this cluster, from the MCP standard explained for operators to protocol fragmentation and the coming consolidation.

The Standards That Actually Matter Right Now

Most "agent interoperability standard" lists you'll find are padded with proposals that have a GitHub repo and three production users. Two standards genuinely matter for operators today, plus a long tail worth knowing about.

MCP: The Tool-and-Context Layer

The Model Context Protocol, introduced by Anthropic in late 2024, is the closest thing the industry has to a default. MCP standardizes how an agent (the "client") connects to external tools, data sources, and context (exposed by "servers"). Instead of writing a custom adapter for each tool, you run an MCP server in front of it once, and any MCP-aware agent can use it.

What made MCP stick where earlier attempts fizzled wasn't technical elegance, it was timing and distribution. Anthropic shipped it alongside reference servers for the things developers actually use (filesystems, GitHub, Postgres, Slack), open-sourced the spec under a permissive license, and then watched as OpenAI, Google DeepMind, and Microsoft all announced support through 2025. When your two largest competitors adopt your protocol, you've won the layer. Anthropic's own Model Context Protocol documentation frames it as an open standard, and in a meaningful sense it is, the spec is public and the SDKs are forkable.

But "open spec" and "neutral governance" are different things, and the gap between them is the whole story (more below).

A2A: The Agent-to-Agent Layer

MCP connects agents to tools. It does not define how one agent delegates a task to another agent it didn't build and doesn't trust. That is the problem Google's Agent2Agent (A2A) protocol, announced in 2025 with a launch roster of dozens of partners, set out to solve.

A2A defines how agents discover each other (via an "Agent Card" that advertises capabilities), authenticate, negotiate a task, and stream results back, including long-running tasks that don't complete in a single request. If MCP is the agent's hands reaching for tools, A2A is agents shaking hands with each other. The two are explicitly positioned as complementary rather than competitive, and Google later donated A2A to the Linux Foundation, a move I'll come back to because it is more consequential than it looks.

For anyone building toward an agent mesh for enterprise deployments or wrestling with multi-agent coordination patterns, A2A is the protocol that, in theory, lets agents from different vendors cooperate. In practice, adoption is far thinner than MCP's, and the "Agent Card" discovery model is still immature.

The Long Tail: OpenAPI, ACP, and Vendor SDKs

Underneath the headline protocols, a lot of real interoperability still rides on OpenAPI specs, agents calling REST endpoints described by a Swagger/OpenAPI document. This is the unglamorous workhorse, and it's worth remembering that a well-described API is already half an agent tool. Standardizing tool definitions across the industry is its own ongoing fight.

You'll also encounter IBM's Agent Communication Protocol (ACP), various "agent network" proposals, and the proprietary SDK conventions baked into LangChain, LlamaIndex, CrewAI, and the framework crowd. Most of these are not standards in any governed sense; they're conventions that happen to have users. Treat them accordingly.

Who Actually Controls These Standards

Here is the part the press releases gloss over. Strip away the foundation logos and ask a blunt question: who can change the spec, and who can stop a change?

• MCP was created and is still substantially steered by Anthropic. There is a public specification process and community contributions, but the protocol's direction, reference implementations, and de facto roadmap track Anthropic's priorities. The maintainers are largely Anthropic employees and close collaborators.
• A2A was created by Google, then donated to the Linux Foundation in 2025. Donation matters, it puts the trademark and the IP under a neutral steward and creates a governance board. But "donated to a foundation" does not mean "controlled by a diverse coalition." Early-stage foundation projects are routinely run by the donating company's engineers, who hold the institutional knowledge and the commit access for years.
• The vendor SDKs (LangChain et al.) are controlled outright by their companies. No pretense of neutrality, which is at least honest.

The pattern across all of these is what I'd call governance theater lite: the spec is open, the license is permissive, the foundation press release is glossy, and the actual control sits with one commercial party whose business model benefits from the standard's shape. This isn't a conspiracy; it's just how de facto standards have always emerged. The web's standards started at Netscape and Microsoft before the W3C and WHATWG mattered. The difference now is speed: agent protocols are being adopted across an industry in eighteen months, not eighteen years, which means governance maturity is lagging adoption by a wide margin.

For the strategic stakes here, the framing in a16z's writing on why AI agents need new infrastructure and protocols is useful, the venture money is betting that whoever owns the connective tissue owns disproportionate value, which is precisely why no incumbent wants to cede control of it.

The Governance Gap: "Open" Is Doing a Lot of Work

Operators get lulled by the word "open." Let's be precise about what's open and what isn't.

Open specification means the document describing the protocol is public and you can implement it. MCP and A2A both clear this bar.

Open source means reference implementations are available under a permissive license. Both clear this too.

Open governance means no single commercial entity can unilaterally steer the standard against the interests of other implementers. Neither MCP nor A2A clearly clears this bar today. A foundation home is necessary but not sufficient; what matters is whether commit access, the roadmap, and the trademark are genuinely distributed, and whether there's a credible process for the community to override the founding vendor. Those mechanisms are nascent at best.

The reason this matters for GaaS specifically: per-outcome pricing and autonomous workflows mean you're handing real authority to agents that depend on these protocols. If the protocol changes in a way that favors the controlling vendor's agents, say, a new capability that's available first and best in their runtime, your "standards-based" architecture quietly tilts toward that vendor. You didn't get locked in by a contract. You got locked in by a spec revision. This is a subtler cousin of the lock-in dynamics covered in building a multi-model agent without vendor lock-in.

The honest comparison is to Kubernetes and the CNCF. Kubernetes is genuinely open-governed now, but it took years and a deliberate effort by Google to dilute its own control. The agent-protocol world is at the very start of that arc, and there's no guarantee the incumbents will choose dilution over dominance.

How This Plays Out: Fragmentation Before Consolidation

The comforting narrative is that the industry converges on one or two clean standards and we all live happily in an interoperable mesh. I don't buy the timeline, and here's the contrarian read.

In the near term, expect more fragmentation, not less. Every major model provider has an incentive to ship a "supported" variant, an extension, or a competing primitive that works best inside its own ecosystem. Microsoft, AWS, and Salesforce each have agent platforms with reasons to embrace-and-extend. We've watched this movie with messaging protocols, with container runtimes, with GraphQL-vs-REST. The pattern is: a promising standard appears, everyone praises it, then everyone ships an incompatible "enhanced" version, and interoperability gets worse for two or three years before market pressure forces real convergence.

Consolidation does come eventually, buyers refuse to tolerate the integration tax, and the foundations grow real teeth, but it tends to arrive after a painful fragmentation period, often triggered by a dominant cloud platform deciding it's cheaper to standardize than to keep maintaining adapters. This is the dynamic explored at length in protocol fragmentation and the coming consolidation within this beat, and I'd weight the "fragmentation first" half of that phrase heavily.

McKinsey's analysis of the agentic AI advantage and what enterprises need to capture it leans optimistic on the value at stake, and it's right about the prize. But realizing that value depends on interoperability that, candidly, the standards landscape can't yet deliver at enterprise reliability.

What Operators Should Actually Do

You're buying GaaS, not writing protocol specs. Here's how to act on all of this without a PhD in standards politics.

Treat MCP as the safe default, with eyes open. It has the broadest support and the lowest integration tax today. Build your tool connections to it. Just don't mistake its ubiquity for vendor-neutrality, and keep your MCP servers thin enough to re-point if the spec forks.

Insist on an abstraction layer you control. Whatever protocol your agents speak, route it through a gateway or adapter layer that you own, so a protocol change is a configuration update on your side rather than a rebuild. This is the practical defense against spec-driven lock-in, and it connects to agent gateways: routing, rate-limiting, and policy as the natural home for that control point.

Score vendors on governance, not just features. In procurement, ask: which standards bodies do they participate in, do they hold commit access or just consume the protocol, and what's their track record when a standard evolves against their interest? A vendor that controls the protocol you depend on is a different risk profile than one that merely implements it.

Assume churn and budget for it. Plan for at least one significant protocol migration in the next eighteen to twenty-four months. The teams that get hurt are the ones who hard-coded today's spec as if it were permanent.

Watch the foundations as a leading indicator. When commit access and roadmap control genuinely diversify away from the founding vendor, the way they eventually did for Kubernetes, that's your signal a standard has matured enough to bet the business on. Until then, hedge.

The promise of agent interoperability is real and worth pursuing. But "standards" in this space are currently power positions held by your largest suppliers, dressed in open-source clothing. Build like you understand the difference.

Insights Most People Overlook

1. A foundation donation is a control-laundering move as often as a control-ceding one. Donating a protocol to the Linux Foundation generates a neutrality headline, but for years afterward the founding company's engineers still hold the institutional knowledge, the commit access, and the roadmap pen. Watch who merges the pull requests, not who owns the trademark.

2. The real lock-in isn't the protocol, it's the extensions. A vendor can fully support an open standard and still trap you, by making its best capabilities available first (or only) through proprietary extensions to that standard. "We support MCP" and "our agents are portable" are not the same claim, and the gap between them is where the lock-in lives.

3. Interoperability that's good enough for demos is reliability poison in production. Cross-vendor agent handshakes via young protocols introduce a fault surface most teams never model: undocumented error semantics, version skew, and silent capability mismatches. The agents-talking-to-agents future has a reliability bill that nobody's pricing into per-outcome contracts yet.

4. The winning standard probably won't be the best-designed one. MCP didn't win the tool layer on technical merit; it won on distribution and timing. The standard that consolidates the agent ecosystem will be the one with the best adoption flywheel, which means whoever controls model distribution has an outsized vote, and that's a small club.

5. OpenAPI is quietly the most "neutral" standard in the stack, and it's underrated. While everyone fights over shiny new agent protocols, a huge share of real interoperability still runs through boring, genuinely vendor-neutral OpenAPI specs. Leaning on it where you can is an under-discussed hedge against the agent-protocol governance mess.

References

• Model Context Protocol, Official Documentation
• a16z, AI Agents, Infrastructure, and the New Protocol Layer
• McKinsey, Seizing the Agentic AI Advantage