Every Automation You Buy Now Has a Sunset Date

The retirement calendar nobody sent you

For most of the last decade, buying software automation meant buying against stable infrastructure. Business APIs changed slowly, deprecations came with years of warning, and the worst case was a connector that needed re-authorising. The arrival of AI steps inside mainstream automation platforms quietly imported a very different lifecycle, one borrowed from frontier model research rather than from enterprise software.

Anthropic publishes its policy plainly: customers with active deployments get at least 60 days' notice before a publicly released model is retired. In practice, that is exactly what happened. Claude Sonnet 4 and Claude Opus 4 were announced for retirement on 14 April 2026 and stopped being served on 15 June 2026 — sixty-two days. Claude Opus 4.1 was announced on 5 June and retired on 5 August. Claude Haiku 3 was announced on 19 February and retired on 20 April. That is three separate retirement events on one provider inside six months, each one capable of stopping an automation that named the wrong model string.

OpenAI's most consequential 2026 shutdown was not a model at all. The Assistants API reached its sunset on 26 August 2026, and the cut was hard: calls to the endpoints fail, there is no read-only grace period, and OpenAI declined to ship an automated tool for migrating existing threads into the Responses API's conversation objects. Anyone who had built on the assistant abstraction rebuilt it by hand or lost it.

Google's schedule for Gemini 2.5 Pro, Flash and Flash-Lite on its agent platform has been softer but less legible, with discontinuation pencilled in for no earlier than mid-October 2026 and the company's own release notes and lifecycle page disagreeing on whether that is the 16th or the 20th. Google has said a confirmed date will be fixed once Gemini 3 is generally available, with at least six months of notice from that point. In the meantime, the Vertex AI console was removed from Google Cloud on 21 May 2026 and the generative modules of the Vertex AI SDK were scheduled for removal on 24 June. The tooling around the model has its own calendar.

Two ways a sunset breaks what you bought

Buyers tend to imagine a single failure mode: the date arrives, the workflow errors, someone notices. That is the good version. There is a second, quieter one that does more damage precisely because nothing looks wrong.

When OpenAI deprecated a batch of models effective 26 March 2026, Make told its customers that scenarios using those models would continue to run without interruption and that requests would be processed automatically by GPT-4 Turbo instead. Nothing failed. No alert fired. The classification step that had been tuned against one model's behaviour was now being answered by a different one, and unless somebody was sampling outputs, the first signal would be a downstream complaint weeks later. Make handled a different case the other way round: after 10 August 2026, scenarios pointing at the GPT-5.2 and GPT-5.3 "Chat Latest" aliases were told they would simply stop running.

Zapier took the loud path on the Assistants shutdown, deprecating every ChatGPT step built on that API and warning that Zaps using actions such as Conversation With Assistant and Create Assistant would stop working on 26 August 2026. That notice is the correct behaviour, and it is still a notice that lands in an inbox somebody has to read.

Of the four, alias drift is the one buyers most often create for themselves. Pointing a production step at a "latest" alias feels like future-proofing. It is the opposite: it hands the provider permission to change the thing generating your output, on their schedule, with no notification at all.

The same model, three different expiry dates

Here is the detail that catches out even careful buyers. A model's retirement date is not a property of the model. It is a property of the platform serving it.

Anthropic's deprecation page is explicit that its dates apply to Anthropic-operated platforms, and that partner-operated platforms such as Amazon Bedrock and Google Cloud set their own schedules. The gap is not cosmetic. Claude Haiku 3 stopped being served on Anthropic's own API on 20 April 2026. The Amazon Bedrock end-of-life date for the same model was 10 September 2026 — roughly a hundred and forty days of additional runway, purely as a function of where the call was routed. Bedrock also commits to six months of advance notice rather than Anthropic's sixty days, and AWS states that for Bedrock usage only the Bedrock dates apply.

That last row deserves emphasis. If your automation calls a model through Zapier, Make, Power Automate or a self-hosted n8n instance, you are not reading the provider's notice. You are reading the platform's summary of it, on the platform's timeline, with the platform's chosen fallback behaviour. Two customers running an identical prompt against an identical model can get different outcomes on the same date because they bought through different intermediaries. This is a specific, underrated flavour of the problem covered in how to avoid automation vendor lock-in: the lock-in is not only in the connectors, it is in who controls your migration schedule.

It is not only models — entitlements expire too

The second half of this story has nothing to do with AI research cadence and everything to do with licensing. Microsoft is removing the seeded AI Builder credits that have been bundled into Power Platform licences, effective 1 November 2026. Capacity moves to Copilot Credits, and there is no automatic conversion between the two. Customers who purchased or renewed an eligible licence before that date keep their seeded entitlement through the applicable contract term, and agreements that started before 1 November 2025 are honoured for their duration — but from the cut-over, no new or renewed licence carries the bundled capacity.

For a buyer, this is the same event as a model retirement wearing different clothes. A document-processing flow that has been running inside an included allowance becomes a flow that consumes purchased capacity. The automation did not change. Its unit economics did. If you bought that automation on a business case built around an included entitlement, the business case expires on a calendar date even though the workflow does not.

What it costs when the date lands on you

Migration is rarely a find-and-replace. Swapping a model changes output distribution, formatting habits, refusal behaviour, latency and cost per run all at once. A step that reliably returned clean JSON under one model may start wrapping it in prose under another. A summarisation prompt tuned to be terse may become verbose. None of that is a bug; it is the reason providers version models in the first place.

Enterprise adoption data gathered through 2026 puts numbers on the gap between teams that plan for this and teams that do not. Roughly 41% of organisations reported at least one production rollback of an AI agent in the preceding twelve months for reliability reasons. Broken out by testing maturity, the spread is stark: agents running without automated evaluations showed a rollback rate near 47%, while those with full evaluation coverage sat around 9%. And only about 38% of production agents had automated evaluations running on every prompt change — which is precisely the discipline a forced model migration demands.

The practical translation for a buyer is simple. The cost of a model retirement is not the hour it takes to change a dropdown. It is the cost of knowing whether the change was safe: a saved set of representative inputs, the previous outputs kept for comparison, and somebody willing to say the new results are acceptable before the switch goes live. If nobody owns that, the retirement date becomes a quality incident with a delay fuse.

Seven questions to ask before you buy

None of this argues against buying AI-dependent automation. It argues for asking a different set of questions than the ones buyers asked in 2023. Work through these with the seller before money changes hands.

1. Which exact model IDs does this depend on? Not "it uses GPT" — the specific string in the step. A seller who cannot answer has not read their own build.
2. Which platform serves those calls? The provider's direct API, a hyperscaler, or a no-code platform's built-in AI step. This determines whose calendar governs you.
3. What is the published retirement date for each? If the answer is "not announced yet", ask where it will be announced and who is subscribed to it.
4. Does this platform fail hard or substitute silently? Ask for the specific behaviour, in writing. The answer changes how you monitor.
5. Are any steps pointed at a "latest" alias? If so, ask why, and whether pinning is an option. Aliases move without notice.
6. Who performs the migration, and at what cost? Is it included in a maintenance agreement, billed hourly, or entirely your problem?
7. What test set proves the migration worked? Ask for the saved inputs and expected outputs to be delivered with the automation, not reconstructed under time pressure later.

The seventh question is the one that separates a serious seller from a hobbyist, and it is worth paying a premium for. A frozen set of twenty or thirty real inputs with their approved outputs turns a migration from a judgement call into a check. It is also the artefact that makes the automation transferable if you ever change providers. For a wider view of what a maintenance relationship should actually cover, see do you need automation maintenance.

What to put in the agreement

Most automation purchases are governed by a short scope document rather than a negotiated contract, which is fine — the clauses below fit in a page and cost nothing to include.

Budget for the cadence, not for the incident

The pattern through 2026 is clear enough to plan against. Between February and September, one provider alone retired three model families on its own API; a major API surface was shut down outright in August; a second provider's tooling and console were removed in May and June; a third left a discontinuation date provisional for months; and a licensing change removing bundled AI capacity is queued for November. Nothing about that cadence suggests it slows down in 2027.

So price it in. An AI-dependent automation should carry an annual maintenance line that assumes one to two forced migrations, each consisting of re-pointing the affected steps, re-running the saved validation set, comparing results against the approved baseline, and shipping the change deliberately rather than at 11pm on the night the endpoint starts returning errors. That is a modest, predictable number. The alternative is not a smaller number; it is the same work done badly, under deadline pressure, by whoever happens to be available.

Buyers who internalise this end up with a real advantage. They ask sellers for dependency lists and test sets, which filters out the sellers who build throwaway work. They keep a register of expiry dates, which turns a recurring surprise into a quarterly half-hour of admin. And they stop treating an automation as a finished object, which it stopped being the moment a model with a retirement date appeared anywhere inside it.

FAQ

What is model deprecation and why should a buyer care?

Deprecation is the moment an AI provider announces that a specific model will stop being served, with a retirement date attached. Buyers should care because any automation that names that model in a step will either fail or quietly change behaviour once the date passes, and the automation you paid for is the thing that stops working.

How much notice do AI providers actually give?

It varies by provider and by platform. Anthropic commits to at least 60 days' notice before retiring a publicly released model on its own platforms, and in practice gave 62 days for Claude Sonnet 4 and Opus 4, which were announced on 14 April 2026 and retired on 15 June 2026. Amazon Bedrock gives six months' notice for the same class of change. Google has said it will confirm a Gemini 2.5 discontinuation date once Gemini 3 reaches general availability and give at least six months from that point.

Does a workflow always break loudly when a model retires?

No, and the quiet case is the dangerous one. When OpenAI deprecated a set of models on 26 March 2026, Make told users that affected scenarios would continue to run and that requests would be processed automatically by GPT-4 Turbo instead. Nothing errored and nothing alerted, but the model producing the output had changed. A hard failure at least tells you something happened.

Can the same model have different retirement dates?

Yes. Partner-operated platforms set their own schedules. Claude Haiku 3 stopped being served on Anthropic's own API on 20 April 2026, while the Amazon Bedrock end-of-life date for the same model was 10 September 2026 — roughly a hundred and forty days apart. Which date applies to you depends entirely on which platform your automation calls.

What else expires besides models?

Whole API surfaces and licence entitlements expire too. OpenAI's Assistants API was shut down on 26 August 2026 with no automated migration path for existing threads, which took out Zapier steps such as Conversation With Assistant. Microsoft is removing the seeded AI Builder credits bundled into Power Platform licences from 1 November 2026, with no automatic conversion into the replacement Copilot Credits.

What should I ask a seller before buying an automation?

Ask which model IDs and API surfaces the automation depends on, which platform serves them, what the published retirement date is for each, whether the platform fails hard or silently substitutes, who performs the migration when a date lands, and what that migration costs. A seller who cannot name the model IDs has not thought about the problem.

How do I budget for this?

Treat model migration as a scheduled cost rather than an incident. Providers have been retiring models on a rolling cadence through 2026, so an AI-dependent automation should carry a maintenance line covering at least one or two migrations a year: re-pointing the step, re-running a saved set of test inputs, and comparing the new output against the old before the change goes live.

Is a deterministic automation safer than an AI one?

On this specific risk, yes. A workflow that moves data between two stable business APIs has no model retirement calendar attached to it. That is not an argument against AI steps, but it is a reason to keep the AI confined to the steps that genuinely need judgement, so that a retirement affects one node rather than the whole process.