Agent Interoperability Standards: A Whitepaper

The first wave of enterprise agents was built as islands: each connected to its own tools, spoke to no other agent, and lived inside one vendor's runtime. That was acceptable when there were three agents. It is not acceptable when there are thirty, built by four teams on three platforms, all needing the same CRM, the same knowledge base, and occasionally each other. Agent interoperability standards are how the islands become an estate.

This whitepaper is written for enterprise architects, platform leaders, and the security and procurement stakeholders who must decide what to commit to. It lays out the three layers of interoperability, the protocols in play, a recommended posture for each, the controls the protocols do not provide, and the governance that keeps an agent fleet coherent. It builds on the Model Context Protocol for the enterprise whitepaper and the primer what is agent-to-agent protocol.

What are the three layers of agent interoperability?

Layer	Question it answers	Maturity	Leading approach
Agent-to-tool	How does an agent discover and use enterprise capabilities and data?	Consolidating	Model Context Protocol over existing APIs
Agent-to-agent	How does an agent find, delegate to, and receive results from another agent?	Emerging	Agent-to-agent protocols; several proposals, one gaining broad backing
Agent-to-host	How does an agent run inside an application, a chat surface, or a workflow engine?	Fragmented	Vendor runtimes and SDKs; standardization is partial

The layers have different risk profiles. The tool layer is where most enterprise value and most enterprise risk sits, and it is the layer where a de facto standard has arrived. The agent-to-agent layer matters for organizations with genuinely multi-vendor agent estates and is still moving. The host layer is largely a runtime choice and should be made reversible through the other two.

What has settled at the tool layer?

Model Context Protocol was introduced by Anthropic in November 2024 as an open standard for connecting AI applications to tools, data, and prompts. During 2025 client support spread across major agent platforms and developer tools, and enterprise adoption followed. Its design fits enterprise needs: servers are thin wrappers over existing APIs, capabilities are described in machine-readable schemas, and every call passes through a client the host controls, which is where enterprise controls attach.

The recommended posture is to standardize on it now, with three conditions: a gateway in front of every server for identity, policy, and audit; thin servers that keep business logic in the systems of record; and protocol versions pinned and managed as dependencies. The comparison with alternatives is in MCP vs API integration and the security model in MCP security risks.

What is happening at the agent-to-agent layer?

Agent-to-agent protocols address a different problem: one agent delegating a task to another, discovering what other agents can do, and exchanging results and status, potentially across vendors and organizations. Google announced an Agent2Agent protocol in April 2025 with broad industry backing and later contributed it to the Linux Foundation; other proposals exist, and the two layers are increasingly described as complementary rather than competing, with agent-to-agent protocols handling collaboration and Model Context Protocol handling capabilities.

The recommended posture is selective adoption behind an abstraction. Most enterprises do not yet need cross-vendor agent delegation; their multi-agent systems run inside one orchestrator, where an internal contract is simpler and safer. Where cross-vendor or cross-organization delegation is a real requirement, adopt the protocol with the broadest backing, isolate it behind an adapter, and keep the decision reversible. Orchestration patterns that do not require an external protocol are covered in the multi-agent orchestration patterns whitepaper.

Question	Internal orchestration	Agent-to-agent protocol
Agents from one platform	Preferred	Unnecessary overhead
Agents from several vendors inside the enterprise	Possible with adapters	Reasonable, behind an abstraction
Agents across organizations	Not applicable	The intended use; requires strong identity and contracts
Discovery of agent capabilities	Internal registry	Protocol-defined capability descriptions plus your registry

Which standards do agents reuse from the existing stack?

Agent protocols sit on top of standards the enterprise already runs, and interoperability breaks when those are ignored.

• Transport and description: HTTP, JSON-RPC, and OpenAPI descriptions for the underlying APIs that servers wrap.
• Identity: workload identity for agents and servers; OAuth-based delegation to carry the user's context, as described in the agent identity and access control whitepaper.
• Authorization: scopes and policy engines applied per tool at the gateway.
• Observability: distributed tracing standards so an agent's call chain across tools and other agents can be reconstructed.
• Schema: JSON Schema for tool inputs and outputs, and structured-output validation on the application side.

None of the agent protocols replaces these. The practical rule is that a protocol endpoint without identity, authorization, and tracing in front of it is not ready for production, whatever the protocol.

What should the enterprise commit to now?

Decision	Commit now	Keep reversible
Tool layer protocol	Model Context Protocol behind a gateway	Specific client libraries and versions
Server ownership	System owners build thin servers; platform team runs the gateway and registry	Server implementation frameworks
Agent-to-agent	Internal orchestration contract; a registry of agent capabilities you own	Any external protocol, adopted behind an adapter
Identity and authorization	Workload identity, delegated user context, per-tool scopes at the gateway	Policy engine product
Observability	Tracing across agent, tool, and model calls	Tooling vendor
Host runtimes	Whatever fits each team, provided tools and identity go through the shared layers	The runtime itself

The theme is optionality: the enterprise commits to the layers that give control and keeps vendor-specific choices swappable. This is the same logic that governs model choice in the multi-model strategy whitepaper.

How should protocols be governed?

Protocols are dependencies with lifecycles, and they need the same governance as any platform component.

1. An owner in the platform team accountable for the gateway, the registry, and protocol versions.
2. A registry of servers, agents, capabilities, classifications, owners, and versions, which is also the security inventory.
3. A review process for new servers and new agent-to-agent connections, covering identity, scopes, classification, tests, and documentation.
4. A deprecation calendar for protocol and library versions, with regression testing before upgrades.
5. Contract tests for every server and every agent interface, run in CI, so a change in one does not silently break the fleet.
6. A capability classification marking every tool as read, reversible write, or consequential write, which drives approval gates regardless of protocol.

Organizational guidance for the tool layer is in how enterprise IT should govern MCP.

How do you test that the estate stays interoperable?

Interoperability decays without tests, because every server, agent, and library evolves on its own schedule. Four kinds of test keep the estate coherent.

Test	What it verifies	When it runs
Contract tests per server	Every tool accepts its declared schema, rejects invalid input, and returns the declared output shape	On every server change, in CI
Conformance tests per client	The agent runtime handles discovery, errors, timeouts, and streaming per the protocol version	On runtime or library upgrade
Fleet regression	A representative set of agent tasks runs end to end across the gateway, servers, and models	Nightly and before any platform release
Failure drills	A server is degraded or removed; agents must fail safely and escalate rather than improvise	Quarterly, and before adding consequential tools

Version upgrades deserve a rehearsal: upgrade the protocol libraries in a staging estate, run the fleet regression, and only then promote. Treat a passing fleet regression as the definition of "interoperable"; a document that says the standards are adopted is not evidence that the agents still work together. The evaluation discipline behind this is described in AI regression testing.

What are the failure modes?

1. Protocol as security. Endpoints exposed without a gateway; the protocol becomes an attack surface.
2. Bespoke integrations persisting alongside the standard, so the inventory is never complete.
3. Premature agent-to-agent adoption for systems that run inside one orchestrator, adding complexity for no benefit.
4. Thick servers carrying business logic that belongs in systems of record, making the server the new legacy.
5. Unpinned versions. Library updates change behavior; agents fail silently.
6. No registry. Nobody can answer which agents reach which systems, which is the first question a regulator or auditor asks.

How does FISTA Solutions help?

FISTA Solutions is an official Anthropic partner and designs agent interoperability layers as part of its AI enablement practice: the gateway, the registry, the identity and authorization model, the contract-test discipline, and the governance process. Our forward deployed engineers build the first servers and the orchestration contracts with your system owners, and every AI agent FISTA delivers uses the shared layers so it can be replaced or moved without rework. FISTA has delivered 150+ projects for 50+ companies across 12+ countries.

If your agent estate is becoming a set of islands, talk to FISTA on WhatsApp about an interoperability assessment, or start with how to build an MCP gateway.