This is Part 6 of Building the AI Foundation, a series for IT and business leaders. Read the whole series at menonstack.com/s/building-the-ai-foundation.
On August 28, 2026, OpenAI announced it would stop supplying its models to Cursor, the AI coding editor, and proposed November 12 as the end date. Its stated reason: after SpaceX acquired Cursor, OpenAI "cannot be confident that SpaceX will use our technology within our terms of service."
I’m staying out of that dispute. Two companies have a disagreement and each has its own account of it. What interests me is what happened to the people in the middle.
A team picked a coding tool. Under that tool sat a supply contract between two other companies. The contract changed because of a deal the team had no part in. They didn’t touch a setting, sign anything or miss an email, and their tool changed anyway.
I’ve lived this one. At a previous company, long before AI, we partnered with a firm for SAP maintenance, and then they got acquired. The new owner’s roadmap pushed the very service we relied on down the list. Nobody did anything wrong. But our risk had quietly become somebody else’s lower priority.
Same shape as the Cursor story. Different technology.
That’s the subject of this part. Parts 1 through 5 built the foundation: the context layer, the system of record, the control plane. This one is about the layers on top, the tools people actually use, and why I think every one of them should be replaceable.
What happened with Cursor
SpaceX agreed in June to acquire Cursor’s parent company, and Cursor said the deal closed on August 14. OpenAI then said it would wind down the contract that supplies its models to Cursor and would not provide future ones. Part of OpenAI’s reasoning rests on its reading of past conduct by companies tied to the buyer. Those are OpenAI’s assertions. I haven’t verified them and I’m not repeating them as fact.
Cursor's CEO, Michael Truell, said OpenAI models account for about 5% of Cursor's user traffic, and that Cursor was talking to OpenAI to resolve it. Anthropic co-founder Tom Brown wrote that Claude would stay in Cursor and that Anthropic would keep adding compute for it. Reporting on OpenAI's help pages says developers who want to keep OpenAI models can bring their own API key. It works for some features, like local chat and agent. It doesn't work for others.
For most Cursor customers the effect is small, since other models stay available. Fine. But the episode showed something. A tool you chose for its editor came with a model supplier you never evaluated, and that relationship could change on someone else's schedule, because of a transaction.
It’s a pattern, with different causes
Everything below is documented. The causes differ and I’m not suggesting intent behind any of them. What they share is that something underneath the tool changed and the customer had little say.
Look at the last row. Not every change is a shock. When a vendor publishes a retirement date you get months, and that’s workable. The trouble sits where nothing is scheduled: ownership changes, capacity decisions, policy defaults, government orders.
One more thing I noticed while reading. Exposure followed the account type and the surface more than the vendor. The API stayed put when ChatGPT removed models. Business tiers sat outside the Copilot training default. People with their own keys kept access, at least for some features, where the bundled contract ended. Whoever holds the account and the contract absorbs the shock, or avoids it.
The swap test
I ask one question about every tool-facing layer. Replace this tool, or the model under it. What breaks?
If the answer is a day of re-testing, the layer is swappable. If the answer is our prompts, our approvals, our audit trail and half our workflows, then the tool has quietly become part of your foundation. It shouldn’t have.
Layers 5 to 7 in this series, the context layer, the system of record and the control plane, should change slowly and on purpose. Layers 1 to 4 are the tools. They should change fast, whenever something better, cheaper or safer shows up. If swapping a top-layer tool forces you to touch the bottom three, you built it backwards. A reasonable peer might say some tools are worth the lock-in for what they give you. Sometimes that's right. Then treat it as a decision, with an exit plan, and not as a default.
Four doors
A tool stays swappable when it comes into your environment through four doors you control, not through connections it set up on its own.
Identity. Whose account, key and contract is the capability under? A company-held enterprise account or API key can be moved. A personal sign-up can’t.
Context. What travels when the tool changes? Prompts, rules files, project instructions and test cases belong in your repositories and systems of record. Not inside one vendor’s interface.
The gate. What decides which content may reach which model? Data classification, retention and approvals should be enforced by you, and not inherited from whatever a tool’s default happens to be this quarter.
The gateway. Where do routing, budgets and logging live? A layer between your tools and the model vendors lets you change the model without changing the tool. It also gives you one place to see spend.
Four layers by four doors makes a grid. Each cell is a question you can answer about a specific tool.
You won’t have strong answers everywhere. That’s fine. The point is to know which cells are weak.
What “delegated” means
The third row is the newest and the least understood, so a short detour.
There are three ways people work with AI, and what separates them is who’s holding the wheel. With an assistant, you ask, it answers, you decide. You see every output before anything happens. With an interactive tool, the AI works inside your editor while you watch, and you accept or reject each change. You’re there for every step. With a delegated agent, you hand over a task and leave. It plans the work, uses tools, runs commands, checks its own output and comes back with something finished, usually a proposed change for you to approve. You weren’t watching.
The word to notice is tools. A delegated agent doesn’t only write text. It can read your repositories, run code, call internal systems and change files, normally inside a sandbox and under a set of permissions. That makes it useful. It also makes it a different kind of risk than a chat window.
A few illustrations, to make it concrete.
A security notice requires a library update across forty repositories. An agent opens a branch in each, makes the change, runs the tests, fixes what it can, and submits forty proposed changes for review by morning.
A nightly build breaks. An agent reads the logs, finds the likely cause and proposes a fix with the evidence attached.
A team has custom reports in an old ERP environment with no documentation and no tests. An agent reads the code, writes plain-language notes and drafts test cases. A person checks them against how the business actually runs.
A queue of small tickets, label changes and config tweaks, goes to an agent and comes back as pull requests.
Products in this category include the coding agents from GitHub, OpenAI and Anthropic, and the background agents inside tools like Cursor. The details differ. The pattern is the same: assign, wait, review. And you review outcomes, not steps.
The four above are illustrations. This one isn’t. I run a swarm of agents that manage my homelab. They watch for updates and apply the low-priority ones themselves. They check the disks. They watch for network outages. Some of it they just handle. The rest they bring to me first.
Small environment, no customers, low stakes. Same shape, though. Where they stop and ask is the gate, the same auto-or-ask split from Part 5. And I still have to answer the other questions in the grid for them: which credentials each one holds, where its instructions live, what a runaway loop would cost
That’s why the doors matter most here.
Why delegated agents tighten every door
When a person uses an assistant, they notice a model getting worse or a feature disappearing. When an agent runs unattended for hours, a model change doesn’t announce itself. The work just comes back different.
So each door gets heavier. An agent needs its own identity so you can revoke or re-point it without touching anyone’s personal account. Its instructions and state belong in your systems, with the harness only reading them. The gate has to be explicit, because nobody is watching each step. And budgets belong at the gateway, because an agent stuck in a loop turns a pricing or quota change into a budget event overnight.
Swapping the model under a delegated agent is also a change in behavior, and not only a configuration edit. You need a fixed set of tasks to run before and after, so you can see what shifted. For a human-in-the-loop tool that’s good practice. For an unattended agent it’s the minimum.
You don’t need a gateway on day one
Most organizations can’t build a model routing layer when they start, and they shouldn’t try. Beginning with one bundled tool is a sensible call. The mistake is making choices that rule out a routing layer later.
Plan for it. Early on, a few moves cost almost nothing and remove most of the risk. Keep prompts, rules and project context in your own repositories. Put accounts and billing under company identity. Write down how you’d leave each tool. Later, bring your own keys where tools allow it, then put one workload behind a gateway, then route the rest. The more work you delegate, the sooner the gateway moves from someday to this quarter.
When you evaluate a new tool, one question tells you a lot: can it move up that ladder? Does it accept your keys or an OpenAI-compatible endpoint, let you export its configuration, and leave your context in your hands?
Try it on Monday
Pick one tool-facing layer your organization uses today. It takes about thirty minutes.
Write the tool’s name at the top of a page and copy the four questions from its row in the grid.
Answer each: yes, partly or no. Be literal. Partly means you could, but haven’t.
For every no or partly, write what it would cost, in days, to change the tool.
Finish this sentence: if this vendor changed its terms next month, we would...
If you can finish it calmly, the layer is swappable. If you can’t, you’ve found where your next quarter goes.
Where this leaves things
The vendors in this piece each had reasons for what they did, and I'm not judging them. That isn't the question. Treating AI vendors as neutral infrastructure was comfortable until August. The tools on top will keep changing hands, prices, terms and models, and you can't stop that. You can decide how much of it reaches your business.
Subscribers get access to three working files below this article: the swap scorecard (the four-door grid for each layer), an exit-plan page, and the Monday worksheet. If you're not subscribed yet, use the button below. It's free.
Next in this series: Part 7, how to make a swap safe. The routing layer, the tests that tell you whether a swap changed behavior, and what delegated agents need before you let them run.