Agent Interoperability and Tool Protocols: What Actually Needs to Be Standardized

A protocol standardizes the shape of a call. It does not standardize what the call means, who is allowed to make it, or what happens when it fails.

The Integration Tax Nobody Budgets For

Wire an agent to three tools and it works. Add a fourth and the week disappears.

Not because the fourth tool is hard. Because every previous integration was hand-written. Each one carries its own authentication flow, its own schema translation, its own retry policy, its own logging format, and its own way of telling you that something broke. The agent logic sits on top of a pile of bespoke adapters, and each adapter is a small liability that only becomes visible when it fails.

This is the documented state of the current function-calling ecosystem. Tool definitions tend to be static, so agents must be re-initialized whenever an API is added or a schema changes. Security boundaries — tokens, rate limits, access control — are ad-hoc and framework-specific. And because each framework ships its own metadata conventions, tools rarely move between them without a new adapter. The survey literature on agent interoperability protocols names this directly: ad-hoc integrations are difficult to scale, secure, and generalize across domains.

The default belief is that this is a protocol problem, and that picking the winning protocol makes integration free. Grant the narrow case where that holds. If you are building a single-vendor prototype against one tool, with a short lifespan and no compliance surface, a protocol buys you very little and costs you a dependency. That case is real. It is also not the case most teams are in.

For everyone else, the belief breaks on a specific confusion. A protocol standardizes the shape of a call. It does not standardize the meaning of the result, the trust boundary around the caller, or the recovery path when the call half-succeeds. Two systems can exchange perfectly well-formed messages and still disagree about whether "archive this record" is reversible.

The handle I want you to carry through this article is the integration boundary: the one seam you control between your agent and everything it touches. Protocols live on one side of that seam. Your semantics, your policy, and your failure handling live on the other. Confusing the two is where most of the wasted effort goes.

Three Layers of Interoperability, Only Some Standardizable

Interoperability is not one problem. It is three, stacked, and they have different economics.

Layer 1 — transport and invocation. How a call is framed, how a tool is discovered, how the result comes back. This is the layer where standardization pays off most, because the problem is genuinely identical across vendors. A JSON-RPC client–server interface for tool invocation does not care whether your agent runs on one framework or another. Neither does a peer-to-peer task handoff over HTTP. When the shape of the exchange is the whole problem, a shared grammar removes real work.

Layer 2 — capability description. What a tool does, what its input schema looks like, what side effects it produces, what it costs. This layer is partially standardizable. You can agree on a schema format. You cannot agree on whether a given tool's description is accurate, complete, or honest about its blast radius. A schema tells you the shape of the arguments. It does not tell you that the tool will silently truncate at ten thousand rows.

Layer 3 — trust, identity, and policy. Who the agent is, what it may touch, and under what conditions. The envelope is standardizable — a unique agent identifier, a policy template, a risk-based access decision. The policy itself is not. It is organization-specific by definition, because it encodes what your business is willing to risk.

Here is the ladder in plain terms: a protocol is a shared grammar, not a shared understanding. Two systems can speak the same grammar and still disagree about what "delete" means, whether a retry is safe, or which of them owns the consequences.

The honest gap is that clear, universally adopted standards remain nascent. Metadata conventions still differ across frameworks, which is exactly why bespoke adapters keep reappearing even in teams that have already adopted a protocol. The protocol solved Layer 1. Layers 2 and 3 came along for the ride and did not get solved.

What the Emerging Protocol Landscape Actually Covers

The protocols you keep hearing about are not competing products. They occupy different tiers, and the practical question is which tier your system actually needs. Treat the taxonomy below as an emerging framing from survey research, not a settled map.

Tool and context invocation. The Model Context Protocol (MCP) is a JSON-RPC client–server interface for secure context ingestion and structured tool invocation. If your problem is "my agent needs to reach a defined set of tools and data sources through a consistent interface," this is the tier that addresses it.

Agent-to-agent task outsourcing. The Agent-to-Agent Protocol (A2A) is a peer-to-peer framework that uses capability-based Agent Cards over HTTP and server-sent events for enterprise-scale task orchestration. This tier matters when one agent needs to hand a task to another agent it does not control.

REST-native and multimodal messaging. The Agent Communication Protocol (ACP) introduces REST-native messaging through multi-part messages and asynchronous streaming, aimed at multimodal agent responses. The distinguishing feature is the message shape, not the orchestration model.

Decentralized discovery. The Agent Network Protocol (ANP) targets open network coordination — a different tier again, where the hard problem is finding counterparties you have no prior relationship with.

Lightweight convention files. AGENTS.md is a Markdown convention that gives coding agents a predictable source of project-specific guidance — build steps, conventions, testing requirements — across repositories and toolchains. It is not a wire protocol at all. It is a shared file location, and that turns out to be enough to make agent behavior more predictable across different tools.

Two cautions before you build on any of this. First, treat protocol surveys as signals of direction, not proof of mainstream adoption. The survey literature itself frames these as emerging and complementary, and notes that universally adopted standards remain nascent. Second, the governance picture is still forming. The Agentic AI Foundation was created under the Linux Foundation as a neutral home for developing and extending agent interoperability standards, with AGENTS.md among the donated artifacts — a sign that the ecosystem recognizes fragmentation as a real cost, not a solved one.

Where Standardization Stops Paying Off

The temptation after reading the previous section is to standardize everything. Resist it. The decision boundary is sharper than it looks.

Standardize these: invocation framing, capability discovery, the auth envelope, and the shape of telemetry events. These are the contracts that make a tool swappable. If two implementations can sit behind the same contract without your agent logic noticing, the contract earned its place.

Do not standardize these: domain semantics, business rules, evaluation criteria, and escalation policy. This is where your product actually differentiates. A generic schema for "approve refund" tells you nothing about your refund policy, and pretending otherwise just moves the complexity somewhere less visible.

The cost of adopting a protocol is not the adoption. It is the abstraction you now have to debug through. A protocol that hides the real mechanism makes failures harder to isolate, and you will pay that cost at the worst possible time — during an incident, at speed, with incomplete information.

There is a specific failure mode worth naming. Teams adopt a protocol, discover it does not cover their case, and then rebuild the same bespoke glue inside the protocol's extension points. They end up with the original adapter plus a layer of ceremony, and no additional portability. The integration tax did not go away. It got a new name and a new place to hide.

My rule: standardize a layer only when you can name at least two implementations you intend to swap behind it. One implementation is not a contract. It is a dependency with extra steps.

The Minimum Contract at the Boundary

The categories above are easy to agree with and hard to implement. Here is what the smallest useful boundary has to preserve, and the failure each item prevents.

Identity and authorization context. Every call carries who the agent is acting as, on whose behalf, and under what policy. Without it, you cannot answer "was this allowed?" after the fact — only "did it happen?"

Idempotency and retry behavior. The contract states whether a call is safe to repeat. Without it, a timeout on a payment or a send becomes a coin flip between a duplicate and a silent drop.

Timeout and cancellation semantics. The contract states what happens when the caller gives up. Without it, a cancelled request may still be executing side effects you believe you stopped.

Normalized result and error classes. Transport failure, capability failure, and policy denial are distinct classes with distinct handling. Without them, every error looks like every other error, and recovery logic becomes guesswork.

Correlation identifiers. A single ID threads the agent decision, the tool call, and the result. Without it, you reconstruct causality from timestamps and hope.

Side-effect disclosure. The contract states whether the call is reversible, and what it touches. Without it, "archive this record" and "delete this record" look identical at the wire level.

Each item maps to one swap test: replace the implementation behind the boundary and confirm nothing above it changes. If a field is missing, the swap will surface it — usually in production.

The Security Surface Protocols Do Not Close

Interoperability expands reach. Reach expands attack surface. The protocol is not the control.

The clearest example is indirect prompt injection: hidden instructions embedded in external data that hijack agent behavior. A more interoperable agent consumes more external data by design, so the exposure grows in proportion to how well the interoperability works. Security researchers have documented this pattern, and it is the reason an agent with deep system access and no vetting is a genuinely dangerous object.

The supply-chain analogy is the one I keep coming back to. Drivers are signed before they load into the kernel, because the kernel is where the damage happens. Skills, plugins, and MCP servers largely are not signed, and the same lesson has not been applied. As one security founder put it, the mechanism is the same and the lesson has not been learned. That gap is visible enough that vendors are now building vetting products around agent skills, plugins, and MCP servers — a signal of perceived demand, not proof that a trusted default is missing or that a market has formed at scale.

Identity and least privilege are being positioned as the enforcement layer, not the protocol. The pattern is consistent across vendor materials: require every agent to carry a unique identifier, enforce policy templates from day one, apply risk-based access decisions that respond to real-time context, and keep agents operating with least privilege. That is a control-plane problem, and it sits above whatever wire format you chose. Treat the pattern as vendor positioning worth studying, not as independent evidence of what every enterprise needs.

The regulatory reality check is that standards bodies are still early. ETSI released its baseline cybersecurity requirements for AI models and systems in December 2025 — a high-level standard that does not yet address the nuances of agentic threats. The EU AI Act's own AI Office has acknowledged that regulatory strategies for AI agents remain preliminary.

And the open question is genuinely open: who holds authority to approve, suspend, and revoke an agent's access? Platforms, device makers, and third-party certifiers all have a claim, and the answer is currently contested. If you are building anything that grants an agent real authority, assume that question will be answered by someone else, later, in a way you will have to adapt to.

Designing a Small, Observable Integration Boundary

Everything above converges on one design decision: keep the boundary thin, and make it inspectable.

One adapter interface per capability, not per vendor. The interface describes what the capability does — search_documents, send_message, read_record. Vendor specifics live behind it. When you add a second provider for the same capability, nothing above the boundary changes.

Every tool call emits a structured event. Tool name, arguments, result, latency, cost, error class. The point is not dashboards. The point is that the seam becomes inspectable rather than inferred. When something breaks at 2 a.m., you want to read the trace, not reconstruct it from logs that were never designed to be read together.

Pair calls with results explicitly. Observability tooling is converging on this pattern: clearer pairing between a tool call and its result, file changes surfaced as focused diffs, command activity that is easy to inspect, and long-running background tasks that stay visible alongside the conversation. That convergence is a signal about what actually matters in practice.

Treat the boundary as replaceable. The test is simple: if swapping a model provider or a tool server requires touching agent logic, the boundary is in the wrong place. The agent should not know which vendor answered.

Here is the proof I would run before trusting any of this. Take one real task. Run it through the boundary. Then break a tool deliberately — return a malformed result, or make it time out. From the trace alone, can you name which layer failed? Transport, capability, or policy? If you cannot, the boundary is decorative.

I would start here: build the adapter and the event schema before choosing a protocol. The protocol then becomes an implementation detail behind a seam you already understand, and swapping it later is a contained change instead of a rewrite.

Fleet Governance Is the Same Boundary at Scale

One agent with a clean boundary is a design problem. Fifty agents is an operational one — but it is the same problem, scaled.

At fleet scale, the local contracts you already own become shared infrastructure. Identity becomes a registry. Authorization context becomes access control. Correlation IDs become audit trails. Side-effect disclosure becomes the input to policy. Nothing new appears; the same fields just have to be consistent across every agent instead of correct in one.

Vendor control planes are converging on a similar set of capabilities — registry, access control, visualization, interoperability, and security. That convergence is a useful signal about what enterprises are asking for, even if you never buy one of those platforms. Interoperability at this level is framed as freedom of choice: the same agent working across vendor platforms, open-source frameworks, and partner clouds. That framing is accurate and useful. It also means your governance has to span vendors, because your agents will.

The operational gap that gets less attention is shift changes. Persistent agents need mechanisms for escalation, supervision, and ownership transfer. Without them, you do not get a fleet. You get a collection of personal agents whose state disappears into individual environments the moment the person who created them goes on vacation.

The open question is whether governance consolidates into a few control planes or stays federated across independent vetting layers. Both are plausible. The decision affects where you invest, so it is worth watching rather than assuming.

What to Learn and Build Next

Three ordered actions, in the sequence that actually transfers.

Read one protocol spec end to end. Not a summary, the spec. You cannot evaluate a contract you have only seen described.

Implement one minimal client and one minimal server. Instrument the call path before you add a second tool, because the second tool is where the missing instrumentation becomes expensive.

Build the smallest useful artifact: one adapter interface plus a structured event log, exercised against two interchangeable tool implementations. Two, not one. The second implementation is what proves the boundary is real.

Evaluation is the next discipline, not an afterthought. A boundary you cannot measure is a boundary you cannot trust, and the measurement work is substantial enough to deserve its own attention. The same is true of deployment and risk management once agents leave your laptop, and of orchestration once more than one agent is involved.

The decision rule to carry forward is short. Adopt a protocol when it removes a contract you would otherwise maintain. Reject it when it only renames the glue.

Interoperability is not a checkbox you adopt. It is a boundary you own. Standardize the wire, own the semantics, instrument the seam — and build the thin adapter and the event schema before you commit to anything else.