Your AI Exit Plan Needs a Rehearsal

On 28 August 2026, OpenAI announced it would end the contract supplying its models to Cursor following Cursor's acquisition by SpaceX. The proposed cutoff on 12 November gave affected teams 76 days from the announcement to prepare.

In June 2025, Windsurf had less. It reported losing nearly all of its direct first-party capacity for Anthropic's Claude 3.x models on under a week's notice, while OpenAI was reported to be in talks to acquire it. Capacity through other providers remained available but, by Windsurf's account, was not enough to meet existing demand.

Your access can depend on an agreement between suppliers that you did not negotiate. A migration rehearsal helps establish what a change in that agreement would mean for your team.

Two migrations, not one

Losing a model and losing a product are different events with different costs.

The first is substitution: keep the product, change the model underneath it. The question is whether your instructions, tools and saved context still produce acceptable results with a different model.

The second is exit: leave the product and take your work with you. The question is whether the records and rules your team relies on — the corrections you have accumulated, the test cases and expected outcomes, the permission rules, the tool definitions — can be exported, restored and made to run elsewhere.

Start by checking whether another model works in your current product. Then test what would be required to leave the product itself.

The agent harness is one place these dependencies accumulate: the software that assembles the model's context, calls its tools and controls what the agent is allowed to execute. Boundaries differ by product — Anthropic separates the harness from the session and the sandbox.

What a failure actually looks like

Consider a hypothetical finance team whose agent compares invoices with payments overnight and routes unresolved discrepancies to a reviewer. After a model change, it incorrectly marks partially paid invoices as settled. Nothing crashes, and the report still looks plausible.

The team catches the error by rerunning saved invoice-and-payment cases with reviewed expected outcomes. They revise the instructions and repeat the tests before deploying the replacement.

What has to survive the change

Context and memory. Check that the export is complete, can be restored, and supports the workflow's acceptance tests.
Tool contracts, expressed as portable interfaces. The Model Context Protocol standardises the tool interface. It does not eliminate differences in client support, authentication, tool descriptions or model behaviour, so plan for tested adapters as well.
Acceptance tests. Your definition of acceptable output, versioned alongside your code. They give the team a repeatable way to check whether a replacement still meets its requirements.
Policy and audit. Document what is allowed, where those rules are enforced, and which audit records must be retained. Check these controls again in the replacement system.
Agent and skill definitions. Keep them in readable files, along with their dependencies: the Agent Skills specification covers scripts, references and assets as well as prose.
A validated alternative. Test a replacement model before you need it. Compare quality, total operating cost — including retries and human review — and latency.

Check what the product lets you export and reuse. Owning the software does not, by itself, establish that the workflow is portable.

Assess existing infrastructure before building these components yourself. Whichever software you choose, assign responsibility for security, extensions and updates.

The rehearsal

Pick a workflow whose failure would have real business consequences. Run it in an isolated test environment with approved data, using representative cases rather than a single execution — one run is a first check, not evidence of consistent behaviour.

Substitution. Same product, alternative model, explicit acceptance criteria.

Exit. Export the workflow's context, memory, configuration, permission policies, agent and skill definitions, and the tool implementations or adapters it depends on — tool definitions alone do not give you working integrations. Restore them in an alternative product or runtime that does not depend on the original vendor. Count the integrations that need rework, and check whether workspace identifiers need mapping.

Record: