Your Agent Runtime Needs an Interoperability Contract, Not Another Framework Bet

Most agent programs do not fail because the first framework was foolish. They fail because the first framework quietly became the operating system.

A team starts with the fastest path to a useful demo: a hosted agent API, a coding-agent SDK, a model plus a few tools, or an MCP server wired into an internal system. The prototype works. Then the workflow grows teeth. It can read customer context, open tickets, draft code, query warehouses, update records, or trigger a downstream process. Suddenly the important question is no longer “which model answered best?” It is “what exactly did the runtime guarantee when the agent touched the business?”

That is where many enterprise agent projects are under-specified. They have prompts, tool schemas, eval scores, and a vendor architecture diagram. They do not have an interoperability contract: a small, explicit description of the runtime behaviors that must survive when the team changes SDKs, moves from prototype to hosted infrastructure, adds MCP servers, or swaps observability backends.

The need is visible in the shape of the ecosystem. OpenAI’s Agents documentation now asks builders to compare the Agents API, Agents SDK, and Responses API depending on the application path. Anthropic’s Claude Code Agent SDK is positioned as a way to build production agents with Claude Code as a library, with concepts such as tools, subagents, MCP, permissions, and sessions. The Model Context Protocol specification gives teams a common way to expose tools, resources, prompts, and authorization patterns. OpenTelemetry’s Generative AI work is pushing the industry toward shared telemetry vocabulary, including MCP-related observability. NIST’s AI Risk Management Framework keeps pulling the conversation back to risk that can be governed, measured, and managed.

That is progress. It is also a warning. When platforms mature, they do not become interchangeable by magic. They become powerful enough that their differences matter.

An interoperability contract is not a generic abstraction layer and it is not a bet that every runtime will behave the same. It is a one-page operational agreement that says: if this workflow moves from one runtime surface to another, these semantics must remain true, or the migration is not complete.

Start with tool authority. Do not only list tool names. Specify what authority each tool represents, which resources it can touch, which scopes or credentials it uses, and which calls are read-only versus side-effecting. If one runtime treats a tool call as a simple function invocation and another routes it through an MCP server with authorization boundaries, the workflow owner should still be able to answer the same question: what can this agent actually do?

Second, define approvals and escalations. A human approval button is not a policy. The contract should say which actions require approval, what information the approver sees, whether the agent can revise and resubmit, how long approval state remains valid, and what happens when the approver rejects or times out. This matters because approval semantics often live inside framework defaults, UI affordances, or SDK-specific permission modes. If those semantics change during a migration, you may have changed the risk profile without changing the prompt.

Third, write down session and resume behavior. Production agents rarely run as a single clean request. They pause, resume, retry, inherit context, hand work to another process, or recover after an infrastructure failure. The contract should specify what state is durable, what state is intentionally forgotten, how memory boundaries are enforced, and what evidence must be present before the agent resumes. “The new runtime supports sessions” is not enough. The question is whether it resumes with the same authority, the same user intent, and the same operational constraints.

Fourth, standardize traces before you need an incident review. OpenTelemetry and vendor tracing tools are useful because they create a shared language for spans, model calls, tools, latency, errors, and usage. But the enterprise contract should name the fields that matter to the business: user intent, tool target, approval ID, policy decision, data classification, retry count, external side effect, and final receipt. If a runtime cannot export those fields, the team should know before the workflow is trusted with production work.

Fifth, define failure behavior. Agents are especially dangerous when they respond to uncertainty with improvisation. The contract should say which errors are retryable, which require escalation, which require a compensating action, and which must stop the run. It should also define the difference between model failure, tool failure, policy failure, and environment failure. Without that distinction, a migration can turn a safe abort into an automatic retry loop, or turn a recoverable tool error into a misleading success message.

Sixth, connect runtime changes to release evidence. If the workflow moves from a local SDK to hosted infrastructure, from a custom connector to MCP, or from one tracing stack to another, the release gate should not be “the demo still works.” It should include targeted probes: permissions, approvals, trace completeness, resume behavior, failure handling, and representative business tasks. This is where NIST-style risk management becomes practical. Governance is not a binder next to the agent. It is the checklist that says the runtime still enforces the controls the organization believes it has.

The point is not to avoid vendor platforms. Good platforms are how teams ship. The point is to prevent the platform from becoming the only place where critical behavior is defined. Hosted agent APIs, embedded SDKs, MCP servers, and observability standards can all be part of a healthy stack. They just need a contract above them that names the invariants the business depends on.

A useful interoperability contract is short. It should fit in a design doc, live next to the workflow, and be tested during release. For each agent workflow, write the answer to six questions: what authority does it have, when does it need approval, what state can it carry forward, what trace evidence must exist, how does it fail safely, and what proof is required before runtime changes ship?

That document will not make agent runtimes identical. It will do something more valuable: make the differences visible before they become incidents.

The next time a team says it wants to “standardize on an agent framework,” push for the missing artifact first. Standardize the contract. Then pick the runtime that can honor it.