On 28 August 2026, OpenAI told Cursor it was ending the contract, with a wind-down date of 12 November. The trigger wasn’t anything Cursor did. It was who bought them: SpaceX had completed its $60 billion acquisition of Anysphere, Cursor’s parent, and a change-of-control clause in OpenAI’s agreement opened a short window to cancel once ownership changed hands.
One decision cut a mature, self-built product off from its model supply. Teams had built their own harnesses to escape vendor lock-in, and owning the code felt like owning the exit. But owning the harness changes which vendor you depend on; it doesn’t remove the dependence itself. The model is capability you rent per call; the harness is where your workflow, context and history accumulate, and the supply chain beneath it belongs to someone else.
This article is about where dependence lives across the stack, and the control plane and meta-harness layers forming above it. By the end you’ll see why the harness layer decides outcomes.
Why does building your own harness not actually remove vendor dependence?
Building your own harness moves your dependence up the stack, from a harness vendor to a model supply chain you don’t control. Every harness depends on model APIs, context formats and runtime semantics owned by someone else, so ownership relocates the dependence; it doesn’t remove it.
Nearly every vendor claims to be model-agnostic, and most of them are telling the truth. The claim is real and also beside the point, because nobody lets your agent definitions, context and workflow leave the harness. Model-agnostic is easy; the harder, unkept promise is harness-agnostic.
Cursor is a live example. What breaks when a model leaves your editor is tab completions, prompt tuning and session history; your code, your rules and your MCP (Model Context Protocol) configs keep working. You plan to exit a harness vendor; the exit that tends to arrive is from a model provider.
Which is safer long term, a proprietary managed harness or an open-source SDK? Neither, by default. Open source removes licence lock-in but not supply-chain risk; your code stays portable, but it still calls a model API someone else controls. A proprietary managed harness adds data and runtime gravity. Anthropic’s Claude Managed Agents shows the trade-off: it decouples the session, harness and sandbox, which is optionality at the runtime layer, but context, permissions and history accumulate inside a provider-hosted runtime, the stickiest layer of the stack. “Managed” can become “captured”, because exit cost rises with every session you store. That’s why the harness is now the layer that decides outcomes. If the harness now decides outcomes, the question becomes who governs many harnesses at once.
What is a control plane, and why is it emerging above individual coding agent harnesses?
A control plane is the layer that routes, governs and observes agents across multiple harnesses and models. It owns identity, policy, observability, audit and cost, but not the agent loop itself. A harness defines how an agent runs; a control plane governs what agents do across all of them.
It’s emerging because a single harness is no longer a sufficient unit of control: it doesn’t know about your other agents, doesn’t enforce organisation-wide policy, and gives no unified audit trail. Run many harnesses across many providers, and governance has to live a level up. The same gap repeats beyond coding, in support, finance and operations agents, wherever each harness keeps its own rules.
That’s why Forrester splits the enterprise agentic stack into build, orchestrate and control, with governance sitting outside the build and orchestrate planes. It’s also why this is the next competitive frontier: Databricks (Unity Gateway and Omnigent), Microsoft (Foundry Agent Service, Agent 365 and Entra Agent ID), Google (Gemini Enterprise Agent Platform) and AWS (Bedrock AgentCore) are each racing to become your control plane, with Microsoft already leading adoption at 38.6%.
The plumbing beneath it is open standards. MCP connects agents to tools, and A2A handles multi-agent coordination. Model-and-harness routing is what makes switching practical. But portable agent identity and policy propagation are still maturing, so a control plane can become the next lock-in layer if you choose it carelessly. That’s the point of governing across a control plane. One level further up, a second layer is forming, one that manages the harnesses themselves.
What is a meta-harness, and how is it different from a single agent harness?
A meta-harness is a layer above individual harnesses that composes, interchanges and governs agents across models and frameworks. A harness of harnesses. A single agent harness is the scaffolding around one model: tool connectivity, context and memory, the agent loop, guardrails and runtime.
It exists because each harness only understands its own sessions; to combine, govern and share agents, you need a layer above the harness. Databricks’ Omnigent is the leading open-source bet, an Apache 2.0 composition layer, and Anthropic’s Managed Agents the leading managed one. Both break the agent into swappable pieces.
The meta-harness overlaps and competes with the control plane. A control plane governs; a meta-harness composes and orchestrates. Whether the control plane or the meta-harness wins the ownership question is still open.
A meta-harness preserves optionality by relocating sessions, policies and skills above any single vendor’s harness, so switching harnesses stops meaning a rebuild. It does to harnesses what routers did to models: it moves the ownership question up a layer without answering it. Whether your routing policies live in an open runtime or a managed console decides whether your orchestration stays portable or ends up trapped on another platform. That’s where ownership and optionality are decided.
Where the dependence actually settles
Owning the harness moved dependence up the stack; it did not remove it. The layer now forming above the harness is where it will settle next, so architect for exit at every layer, not just the one you can see.
A control plane and a meta-harness restore optionality through routing, governance and open standards instead of ownership. The meta-harness moves the ownership question up a layer; it does not settle it. When you evaluate Databricks, Microsoft, Google, AWS and Anthropic, apply one test first: do their open interfaces and routing let your agents leave, or do they become the next dependency?
Lock-in doesn’t go away; it moves to whichever layer you don’t control. The only durable defence is optionality you architect before you need it.
Frequently Asked Questions
Why did OpenAI cut Cursor off, and what does that mean for teams running their own agents?
OpenAI’s 28 August 2026 notice cut Cursor’s model access after SpaceX acquired Anysphere and triggered a change-of-control clause, with the wind-down completed on 12 November. For teams running their own agents, it proves a self-built harness is only as portable as the model supply chain beneath it. The exit you planned for (a harness vendor) is not the exit that actually happens.
Proprietary managed harness vs open-source SDK: which is the safer long-term bet?
Neither is safe by default. An open-source SDK removes licence lock-in but not supply-chain risk: your code is portable, yet it still calls a model API someone else controls. A proprietary managed harness adds data and runtime gravity on top of that. The safer bet is whichever one gives you a real exit path, tested before you need it, not whichever carries the friendlier licence.
What’s the catch with Claude Managed Agents?
Anthropic’s Claude Managed Agents decouples session, harness and sandbox, which is genuine optionality at the runtime layer. The catch is convenience: context, permissions and conversation history accumulate inside a provider-hosted runtime, the stickiest and most compounding layer of the stack. That means “managed” can quietly become “captured”, because your exit cost rises with every session you store there.
Is a control plane the same thing as an agent orchestration platform?
Not quite. An orchestration platform coordinates how agents run, while a control plane governs them across harnesses and models: identity, policy enforcement, observability, audit and cost. The two overlap and compete, and the boundaries are still forming. Treat “control plane” as an abstraction and optionality play rather than a settled product category, because the market and the standards have not converged yet.
What is MCP, and how does it help reduce vendor lock-in?
MCP (Model Context Protocol) is an open standard for connecting models and agents to tools and data sources through a common interface. It reduces lock-in because tool and data integrations become portable across harnesses instead of being rewritten for each vendor. It is necessary but not yet sufficient on its own: portable agent identity and policy propagation are still immature, so MCP opens the door without guaranteeing you can walk through it.
Does open source guarantee portability?
No. Open source removes licence lock-in, not supply-chain or operational lock-in. You can read and modify the code, but the harness still depends on model APIs, context formats and runtime semantics controlled by someone else, and your accumulated context and customisations keep you anchored. Portability comes from open interfaces and routing underneath the harness, not from the licence alone.
What happens to my context, memory and session history if I switch harnesses?
In most harnesses, they stay behind. Context, memory and session logs accumulate inside the vendor’s runtime, so switching means starting over unless the meta-harness relocates sessions, policies and skills above any single vendor. That is exactly why context is the stickiest layer: it raises exit cost at the same rate it grows. Check where your history is stored before you commit.
Why does the cost of switching harnesses get higher the longer I wait?
Because lock-in compounds through your own accumulated work. Every session stored, workflow built and permission configured inside a harness deepens the integration and widens the gap between staying and leaving. Unlike a licence fee, this cost is invisible until you try to move. That is why you architect for exit before you need it, when switching is still cheap, rather than during a forced migration.
How do I evaluate whether a control plane vendor will let me leave?
Test the exit, do not trust the promise. Ask whether your agent definitions, context and routing rules can export cleanly, whether the vendor supports open interfaces like MCP and A2A, and whether model-and-harness routing actually works across providers. Apply one criterion first across Databricks, Microsoft, Google, AWS and Anthropic: do their open interfaces let your agents leave, or do they become the next dependency?
What is a change-of-control clause, and can I negotiate it out?
A change-of-control clause lets a vendor terminate or renegotiate your contract if the other party is acquired or changes ownership. It is what turned Cursor’s model access from a commercial relationship into an existential supply risk overnight. You can sometimes negotiate carve-outs or notice periods, but the durable defence is architectural: assume any single supplier can be severed and build routing and fallbacks before that happens.
Is vendor lock-in always a bad thing?
Not always. Deliberate, bounded lock-in can buy speed, integration and lower cost, and a managed runtime often earns its convenience. The danger is unintentional lock-in you did not price: dependence you cannot see, cannot measure and cannot exit. The question is never “is there lock-in?” but “do I know where it lives, what it costs to leave, and have I kept an exit open?”
How do I architect for exit before I need it?
Keep dependence shallow at every layer rather than owning one layer outright. Route models and harnesses behind an interchangeable interface, keep context and agent definitions in formats you can export, favour open standards like MCP and A2A, and monitor exit cost as a standing metric. The goal is not to avoid dependence, since that is impossible, but to leave each supplier quickly and cheaply when the moment arrives.
