Short answer
AI vendors change products, prices, terms and models every quarter. In August 2026 alone, OpenAI retired the Atlas browser after nine months and gave notice that Cursor loses access to OpenAI models on November 12 following its acquisition by SpaceX, while Claude Fable 5.1 shipped with breaking API changes. Automations survive this when the prompts, data and logs live outside the vendor, when the model sits behind a swappable layer with a fallback, and when a small test set lets you change providers in an afternoon.
There is a kind of automation that works beautifully until an email arrives from a vendor. This post is about not building that kind.
Three reminders from one month
- Atlas, October 2025 to August 9, 2026. OpenAI's browser with a built-in agent was retired after nine months, with its capabilities folded into ChatGPT and Codex, as OpenAI explained in its help centre. Anyone who had wired a process around Atlas had a summer to rebuild it.
- Cursor loses OpenAI models on November 12. SpaceX completed its acquisition of Cursor on August 14. On August 28 OpenAI announced it would wind down its contract, saying it could not be confident the new owner would honour its terms of service, and gave the maximum notice the contract allowed. Cursor's own developers did nothing wrong. A change of ownership two levels above them removed a supplier.
- Claude Fable 5.1 shipped breaking changes. Anthropic's developer notes for the September 1 release list three: forcing the model to call a specific tool now returns an error, earlier models cannot read the new model's reasoning blocks, and editing earlier turns in a conversation invalidates them. These are reasonable design decisions. They are also the sort of thing that silently breaks an integration written eight months ago.
Add the routine churn, such as models retired from ChatGPT with a few months' notice and price changes in both directions, and the picture is clear. The model layer changes quarterly. Your business processes should not.
Six principles that hold up
1. Own the prompts, the data and the logs
The instructions your automation runs on, the examples it learned from, and the record of what it did are your intellectual property and your audit trail. Keep them in your own repository, database or document store, not only inside a vendor's dashboard. If the vendor disappears tomorrow, you should be able to open a folder and see exactly how the system worked.
2. Put the model behind a layer you control
Every automation should call "the model" through one place in your own system, whether that is a node in n8n or Make, a small function, or a gateway. Swapping providers then means changing one setting, not hunting through every workflow. The assistant on this website runs on a fall-through chain: a primary model, an automatic fallback from a different provider, and a plain knowledge-base tier if both fail. When one provider had an outage this summer, visitors did not notice.
3. Keep a second provider warm
A fallback that has never been tested is not a fallback. Route a small share of real traffic, or at least your test set, through the second provider monthly so that its prompts and formatting are known to work.
4. Keep a twenty-example test set per workflow
This is the same advice we give about upgrades, and it applies doubly to forced migrations. Twenty real inputs and a score sheet turn "we have to switch models by November 12" from a crisis into an afternoon.
5. Avoid vendor-only features in the critical path
Proprietary memory systems, vendor-specific browsers, beta parameters and forced tool selection all have a habit of changing. Use them for experiments. For a process the business depends on, stick to the plain request-and-response pattern every provider supports, and keep state in your own database.
6. Read the terms once a year
The Cursor case turned on a change-of-control clause. Most small companies will never negotiate one, but you can at least know your provider's notice period for retirements and price changes, and what happens to your data if the relationship ends.
Signals that a tool may not last
| Signal | Why it matters |
|---|---|
| Feature is labelled beta or preview | Beta headers and parameters are the first things a vendor changes |
| Product overlaps with the vendor's flagship | Atlas overlapped with ChatGPT. The flagship wins |
| Capability depends on a partnership | Partnerships end when ownership or strategy changes |
| No export of your data or prompts | If you cannot leave, you will eventually be leaving in a hurry |
| Pricing is subsidised or "free during preview" | The bill arrives when the preview ends |
What this looks like in practice
A quote-drafting workflow we would build today reads the inbound request from your inbox, calls a model through a single node with a named fallback, checks the output against your pricing rules in code rather than in the prompt, writes a draft to your CRM, logs every step to your own table, and waits for a person to approve before anything is sent. If OpenAI, Anthropic or Google changed a model tomorrow, one setting changes and the test set confirms it still works. That is the whole design, and it is not more expensive than the fragile version. It is just decided up front.
Frequently asked questions
Why did OpenAI cut off Cursor?
SpaceX completed its acquisition of Cursor on August 14, 2026. On August 28 OpenAI said it could not be confident SpaceX would use its technology within OpenAI's terms of service, citing prior contract disputes with other companies in the group, and gave the maximum notice its contract allowed, with a proposed shutoff of November 12. Cursor's chief executive said OpenAI models were about 5% of Cursor traffic.
What happened to ChatGPT Atlas?
Atlas, OpenAI's browser with a built-in agent, launched in October 2025 and stopped working on August 9, 2026. OpenAI said it was moving browser-based agent features into ChatGPT and Codex instead. Anyone who built a process around Atlas had roughly nine months of product life.
Does using a single vendor's ecosystem save enough time to be worth the risk?
Sometimes, for tools you use interactively. For automations that run unattended and that the business depends on, the saving is usually small and the exposure is not. Keep the model behind an interface you control, keep your prompts and data in your own systems, and the ecosystem lock-in mostly evaporates.
How do we know when it is time to switch models?
When your own test set says so. Keep twenty real examples per workflow and a score sheet. When a vendor announces a retirement, price change or new model, run the set and decide from the numbers rather than the announcement.
