Agent Interoperability: One Control Plane for Any Framework

What Is Agent Interoperability?

Agent interoperability is the property that the pieces of an agent stack, the framework, the model, and the tools, can be mixed and swapped without the governance around them breaking. An agent built on one framework can call the same tools as an agent built on another, both can reach the same models, and both are subject to the same identity, access, and audit rules.

It has two halves that are easy to conflate:

• Build-time interoperability. You are not locked into one framework or one model provider. You can build one agent in LangGraph, another in CrewAI, and a third as a plain HTTP service, and adopt a new model without a rewrite.
• Run-time interoperability. Those agents speak shared protocols to reach tools and each other, so a tool written once is usable by any of them, and governance applies uniformly no matter which framework made the call.

Without the second half, the first just spreads the fragmentation around. Interoperability that matters is the combination: freedom to choose, plus one consistent control plane underneath.

Why Open Standards Are the Foundation

Interoperability is only real if it rests on open standards rather than one vendor's proprietary connectors. Two standards carry most of the weight for agents today.

‍

• MCP (Model Context Protocol) standardizes how an agent reaches a tool. A tool exposed as an MCP server can be called by any MCP-aware agent, regardless of the framework it was built on. Instead of N frameworks times M bespoke integrations, you get one protocol.
• A2A (Agent-to-Agent) standardizes how one agent calls another. An agent that implements A2A exposes a machine-readable agent card, and other agents can discover and call it without custom glue.

A platform that speaks these standards can sit in front of any agent and any tool and still understand what is happening. A platform that relies on proprietary wiring can only govern the parts built its way. That difference is why the MCP vs A2A distinction matters: one is how agents reach tools, the other is how agents reach each other, and a vendor-neutral control plane needs to handle both.

How TrueFoundry Delivers Vendor-Neutral Interop

TrueFoundry's role is to be the control plane that every framework, model, and tool passes through, so choice at the edges does not become chaos in the middle.

A framework-agnostic Agent Registry

Whatever an agent is built on, Bedrock, Vertex AI, LangGraph, a custom HTTP service, an A2A agent, or a copilot embedded in a SaaS product, it enters governance by being registered in the Agent Registry, with nothing to move or rewrite.

For A2A agents specifically, the registry resolves the agent card at its well-known endpoint, proxies calls through the gateway, and records the JSON-RPC request and response in every trace. So an A2A agent and a LangGraph agent look different at build time but are governed identically at run time: same registry, same identity, same audit trail.

One unified interface for models and tools

On the model side, every provider sits behind a single OpenAI-compatible API, so any framework can reach any of 1,000+ models by pointing at the gateway and overriding its base URL. You do not adopt a TrueFoundry SDK to get this. You keep your framework and change one setting.

# Any OpenAI-compatible framework or app becomes portable by overriding the base URL.
from openai import OpenAI

client = OpenAI(
    api_key="your-truefoundry-api-key",   # a gateway token
    base_url="https://gateway.truefoundry.ai",
)
# LangChain, CrewAI, AutoGen, LlamaIndex, or a custom loop:
# set the same base_url and they all route through the one control plane.

On the tool side, the MCP Gateway fronts any MCP server and standardizes access to it, so a tool registered once is reachable by every governed agent. TrueFoundry's ecosystem spans 116+ integrations across categories like coding assistants, frameworks and apps, and guardrails, all reachable through the same gateway.

‍

Product screenshot, TrueFoundry docs: the Agent Harness runtime.

Pluggable extension points instead of a closed marketplace

Where some platforms ship a proprietary "agent plugins" catalog, TrueFoundry's extension model is open by design. Tools plug in as MCP servers. Safety and policy logic plugs in as custom guardrails, which are just HTTP services that follow a simple request and response contract, so you can add domain-specific validation or mutation without waiting on a vendor to build a connector. The result is the same benefit a plugin marketplace promises, extensibility, without the lock-in of a closed one.

‍