Agent interoperability

What is agent interoperability?

Agent interoperability is what lets agents built by different teams or vendors find each other, handover work between them, and produce one combined result. People usually talk about it as a protocol question, something a technical standard can solve on its own. In practice, it's actually four separate problems stacked on top of each other, and only the bottom one of those four is currently standardized.

The problem is familiar from every past integration wave:

• A procurement team builds an agent on one cloud
• Finance builds one on another
• A supplier runs a third entirely outside your perimeter

Each one works on its own. None of them can call the others without someone writing custom glue code, and that glue code becomes the thing nobody wants to own. Two open protocols now solve a large part of this problem, and both moved under Linux Foundation governance during 2025. What they solve is the mechanics of connection. What they don't solve is everything above those mechanics, and that's exactly where enterprise programs stall.

The four layers

• Protocol. How a message gets from one agent to another, or from an agent to a tool. Formats, transports, discovery, error handling. Status: standardized. This is what MCP and A2A cover.
• Identity. Who an agent is, on whose authority it acts, and what it is permitted to do on the other side of the boundary. Status: emerging. Authentication is specified; delegated authority across organizations largely is not.
• Semantics. Whether both agents mean the same thing by the words they exchange. Two agents can pass a perfectly valid message about a "customer" and be describing different entities. Status: not standardized.
• Accountability. Whose record holds what happened when two agents from different organizations produced an outcome together, and who answers for it. Status: not standardized.

Reading the four together explains a common frustration. Teams adopt a protocol, connect two agents successfully in a week, and then spend three months on the parts nobody warned them about. The protocol was never the hard layer. It was the only one somebody else had already solved.

What are MCP and A2A, and how do they differ?

MCP connects an agent to tools and data. A2A connects agents to each other. MCP is vertical, reaching down from an agent to its capabilities; A2A is horizontal, reaching across to peers. They are complementary by design and both are now Linux Foundation projects.

This is the most common point of confusion in the space, and the two projects themselves are unusually clear about it. The Linux Foundation's framing is that A2A defines how agents communicate and coordinate across organizational boundaries, while MCP defines how agents connect to internal tools and data sources.

Model Context Protocol, in brief

MCP standardizes the interface between an agent and the things it acts on. A server exposes tools, data resources, and prompt templates through one specification, and any compliant client can use them. The practical effect is that an integration written once works with any agent that speaks MCP, rather than being rebuilt per framework. Anthropic released it in November 2024 and donated it to the Linux Foundation's Agentic AI Foundation in December 2025, and it now has support from every major model provider. Full specification: modelcontextprotocol.io.

Agent2Agent Protocol, in brief

A2A standardizes how independent agents discover each other, delegate tasks, and return results across organizational boundaries. Its central object is the Agent Card, a published description of what an agent can do, which lets another agent decide whether to call it without knowing anything about its internals. The specification separates the data model, the operations, and the transport bindings, with JSON-RPC over HTTPS as the primary binding alongside gRPC and REST. Google announced it in April 2025, donated it to the Linux Foundation that June, and version 1.0 is the current stable release with more than 150 supporting organizations. Full specification: a2a-protocol.org.

What do agent protocols not solve?

Protocols only carry messages. They don't establish whose authority an agent acts under, whether two agents mean the same thing by a term, what happens when a partner's agent misbehaves, or whose audit record holds the outcome. Those four problems remain the buyer's responsibility to solve, and that's where projects tend to overrun.

None of this is a criticism of the specifications. They are scoped deliberately. It is a criticism of how interoperability gets sold, because adopting a protocol is routinely presented as adopting interoperability.

1. 01
   Delegated identity across a boundaryAn agent calling another organization's agent acts on somebody's authority. Whose, with what scope, and for how long, is a question authentication does not answer. Practical consequence: either you over-grant a service identity, or you build token exchange yourself.
2. 02
   Shared semanticsTwo agents can exchange a structurally valid message and mean different things by it. One system's "active customer" excludes accounts in dispute; another's does not. Practical consequence: valid messages producing wrong outcomes, which no protocol check will catch. See data intelligence.
3. 03
   Trust and recourseWhen a partner's agent returns something confidently wrong, or stops responding mid-task, the protocol reports a failed task. It does not tell you what you are entitled to. Practical consequence: commercial terms and fallback behaviour have to be designed alongside the integration.
4. 04
   Accountability for a joint outcomeTwo agents from two organizations produce one result. Each holds half a trace. Practical consequence: reconstructing what happened requires cooperation you may not have, which is a problem the first time a regulator asks. See AI governance.

The layer-four problem is the one most often discovered late. Internally, an agent registry and per-action logging give you a complete record. Across a boundary you have your side and a counterparty's assurance about theirs, and that is a materially weaker position than teams assume when they extend an internal pattern outward.

Why does agent interoperability matter commercially?

Because the alternative is custom integration for every pair of agents, and that cost grows fast as more agents get added. Most large enterprises already have agents running across several different platforms. Interoperability is what stops all this turning into a set of isolated islands, each needing its own separate bridge.

Three arguments carry most of the weight, and they land differently depending on who is listening.

• Integration cost. Connecting agents pairwise means the number of integrations grows with the square of the number of agents. Ten agents fully connected is forty-five bespoke bridges. A shared protocol turns that into ten implementations of one thing.
• Vendor optionality. Agents that speak a common protocol can be replaced without rewriting everything around them. Agents integrated bespoke cannot, which is how a pilot becomes a dependency nobody chose.
• Cross-organization work. The larger prize is agents transacting with suppliers, partners, and customers rather than only with internal systems. That is not reachable with private integrations, because the counterparty will not build to your interface.

There is a fourth argument worth treating carefully, which is that interoperability standards are becoming an enterprise procurement requirement rather than an architectural preference. That is broadly true and is often overstated in vendor material. The defensible version is narrower: an enterprise buying an agent platform in 2026 will generally ask about protocol support, and a platform that cannot answer is at a disadvantage, whatever the technical merits.

How do you evaluate agent interoperability?

Ask five questions of any platform: does it implement both protocols natively, can it govern agents it did not create, whose identity crosses the boundary, how are semantics agreed, and where does the joint audit record live. Protocol support alone answers only the first.

These are ordered so that a weak answer early makes the later ones moot.

• Native or adapter? Ask whether protocol support is the internal model or a translation layer. Adapters work and they lag the specification, which matters as both protocols continue to move.
• Can it govern what it did not build? An agent reachable over A2A but absent from your registry and your policy enforcement is interoperable and ungoverned. That combination is worse than not connecting it.
• Whose identity crosses? Get a concrete answer on what credential the outbound call carries and what scope it has. Vague answers here usually mean a broadly permissioned service account.
• How is meaning agreed? Ask what happens when the two sides define a shared term differently, and whether anything detects it. Usually nothing does, which is worth knowing in advance rather than after.
• Where does the joint record live? Establish what your side captures about a cross-boundary task and what you would need from the counterparty to reconstruct it. Do this before the first integration, not after the first incident.

One piece of sequencing advice. Interoperability is far easier to add to a system that already has a registry, per-action logging, and a governed release path. It is much harder to retrofit onto a system that lacks these, because three of the four layers depend on internal groundwork you either already have, or you will be forced to build under time pressure. Connecting agents is not the real milestone here. Being able to say exactly what a connected agent did, that is.