Agent Control Plane Portability: The Lock-In Hiding Inside the Consensus

Three frontier labs just standardized the agent control plane. Here's why that consensus is the new enterprise lock-in, and the four seams that keep it portable.

Within about a week of each other, OpenAI, Microsoft, and Anthropic shipped essentially the same agent architecture. They split the strategic layer, the control plane where an agent plans, calls tools, and proves compliance, from the execution layer, the sandbox where code actually runs. Anthropic called it decoupling the brain from the hands. The New Stack read the moment correctly: this is design consensus, not coincidence. But the piece it left open is the one enterprises should be asking loudest, and it is the whole point of agent control plane portability: if three vendors agree on where your agents run, what exactly can you take back when you want to leave?

That question is not academic. The control plane is where the durable, expensive-to-rebuild parts of an agent system accumulate: the audit trail, the tool wiring, the policies, the memory. Standardize the shape of that layer across vendors and you have not reduced lock-in. You have relocated it, from the model (which is now nearly commoditized and swappable) to the harness (which is not). Most teams are pricing the model contract and ignoring the harness.

Why does control-plane consensus increase lock-in instead of reducing it?

It is tempting to read architectural agreement as a portability win. If everyone builds the same control-plane/execution-plane split, surely moving between them gets easier. It does not, for the same reason that every cloud offering "object storage" did not make it trivial to leave AWS. The interface converges; the contents stay proprietary.

Consider what actually lives in a control plane once an agent system has been in production for two quarters. Anthropic's session is an append-only log of every model call, tool call, and result, the thing your security team relies on for auditability. OpenAI shipped a Connector Registry inside AgentKit, the wiring that tells agents which tools exist and how to reach them. Governance rules, spend limits, and guardrails sit in the harness too. So does the agent's memory and the contract for how state is passed between steps. None of that is the model. All of it is the part you would have to rebuild to switch vendors, and none of it ports by default.

This is the gap in the consensus story. The labs agreed on the architecture. They did not agree on the formats, the export paths, or whether your session log is yours. That silence is the lock-in.

The Four Seams of Control-Plane Portability

Portability is not a feature you negotiate at renewal. It is a property you engineer at four specific boundaries, the seams where the control plane meets everything else. Keep these four seams in formats you own and you can swap the harness underneath without a rebuild. Let them fill up with vendor-proprietary structure and you cannot leave, whatever the contract says.

Seam 1 — Trace: the append-only event log. Every serious control plane emits a record of what the agent did: model calls, tool calls, results, decisions. That log is your audit trail, your debugging surface, and your compliance evidence. The portability test is simple: can you stream it, in real time, to a store you control, in a schema you can parse without the vendor's SDK? AgentField, an open-source control plane released this month, makes the strong version of this concrete, every execution emits a tamper-proof, offline-verifiable receipt (af vc verify audit.json). You do not need blockchain receipts. You do need the trace to leave the building in a neutral format.

Seam 2 — Tools: the connector registry. The set of tools an agent can call, and the identity and permissions attached to each, is high-value wiring. When it lives only inside a vendor's registry, re-creating it is a migration project. Keep the registry as declarative config in your own repo, MCP server definitions, tool schemas, scopes, and treat the vendor's registry as a cache of that config, not the source of truth.

Seam 3 — Policy: governance-as-code. OpenAI's own agentic-governance cookbook makes the pattern explicit: ship policies as a versioned, installable package rather than as settings clicked into a console. That is the portability move disguised as a governance move. If your guardrails, spend limits, and redaction rules are a Python package in your dependency tree, they travel with your code to any harness. If they are toggles in a vendor UI, they are hostage.

Seam 4 — State: the memory and context contract. How an agent's memory is represented, and how state passes from one step to the next, is the seam teams notice last and regret most. Vendor-native memory stores are convenient and sticky. The portability discipline is to define your own state contract, what a "session" contains, how context is serialized, and keep the vendor's memory as an implementation of that contract rather than the definition of it.

Trace, Tools, Policy, State. If you can export all four in formats you own, the harness is a replaceable component. If you cannot, the harness owns you, and the model contract you spent three months negotiating was the cheap part.

What does the portable version actually cost?

The honest answer: a portability seam costs more up front and pays back the first time a vendor changes pricing, deprecates a feature, or gets acquired. The tradeoff is real, so make it deliberately rather than by default.

The pattern to watch is agent-as-a-service, treating agents as identity-aware callable microservices rather than as embedded library calls into one vendor's runtime. That framing forces the seams into the open: a callable service has an explicit interface, explicit auth, and explicit audit, which is exactly what portability requires. It is also more work than importing an SDK and calling .run(). The Gartner estimate that up to $234 billion in enterprise application spend is exposed to "agentic arbitrage" is the market-level version of the same point: value is moving into the agent layer, and whoever controls that layer captures it. You want that layer to be one you can move.

Note the boundary case. The MCP 2026-07-28 spec, which drops sessions and mandates OAuth 2.1, actually helps portability at the Tools and Trace seams by standardizing auth and statelessness, but it shifts security responsibility onto you. Standards reduce lock-in only when you implement to the standard rather than to a vendor's convenient superset of it.

What I'd actually do

If you are running agents in production or about to, I would not start with model selection. I would run the four seams as an exit test, this quarter, before the control plane fills up.

Pick your current or leading harness and answer four questions honestly. Can I stream the full execution trace to my own store, in a schema I can read without the vendor SDK? Is my tool registry declarative config in my repo, or clicks in a console? Are my policies a versioned package that travels with my code? Do I own the definition of a session and how state serializes? Every "no" is a seam where lock-in is accruing right now, silently, while the system works fine, which is exactly when it is cheapest to fix.

I work with Fortune-level enterprise clients architecting and building agentic frameworks, and the teams that stay portable are not the ones with the best model contract. They are the ones who decided early that the control plane was theirs, and engineered the four seams to prove it. The consensus the labs reached this month is genuinely good news for the industry. Just read the part they did not say out loud: they agreed on the architecture, not on your right to leave it.

Want the enterprise agentic AI playbook, one architecture decision at a time? Subscribe to the newsletter for a weekly, no-hype breakdown of what it actually takes to move agents from pilot to production.