What breaks when the model in your workflow retires?

The workflow has been running quietly for months. Then the model it depends on disappears from the product’s supported list.

The replacement has better scores. That still leaves a practical question: does your work finish correctly when the replacement runs it?

A model retirement is a dependency change with a deadline. Give it an owner before it becomes an interruption.

A specific deadline, within a specific product

GitHub’s September 18 Copilot notice schedules selected model deprecations for October 19, 2026 across Copilot experiences and lists suggested alternatives.

This is a Copilot notice. It does not announce that those model families disappear from every provider or direct API on that date. Check the service your workflow actually uses before assuming the deadline applies.

The broader operating lesson is useful even if your team uses a different vendor: a working integration can have an expiring component underneath it.

Find the dependency people cannot see

Start with recurring jobs, not a list of subscriptions. Which job drafts the customer reply? Which one classifies incoming requests? Which one reviews a software change?

For each relevant job, identify the product, the configured model or selection policy, who can change it, and what happens if it is unavailable. If the vendor chooses the model automatically, record that fact rather than inventing a fixed version.

A compact dependency record can answer four questions:

Question	Useful evidence
Where is the model selected?	The actual product or integration setting
Who owns the change?	One accountable person
What counts as acceptable output?	The workflow’s existing acceptance cases
What happens if it fails?	A tested fallback or manual operating path

Do not paste credentials into that record. Link to the approved configuration location and describe the required access.

Test the behavior that the business relies on

Imagine a hypothetical team using AI to classify service requests into a few queues. Its acceptance rule includes a visible unresolved state when the request does not contain enough information.

A replacement that returns valid output every time can still be worse if it confidently assigns ambiguous requests to the wrong queue. Passing the output-format check would conceal the operating regression.

Use a sanitized set of accepted historical cases, including ambiguous requests and an unfamiliar category. Compare the replacement against the answer set the team has independently checked. Keep the prompt, tools, and input records stable while testing the model change.

Inspect false assignments, unresolved cases, human correction time, latency, and the actual cost of a completed job. Do not make a purchasing decision from a token price or a benchmark alone.

If a change requires a new prompt or tool configuration, record that as another change and evaluate it visibly. Otherwise, you cannot tell which adjustment produced the result.

A fallback is also a product decision

Sending failed requests to another model can preserve availability while changing the quality or behavior of the workflow. It can also change where information is processed. Verify that the alternate route fits the same task and access rules.

For some jobs, the better fallback is a human queue with an explicit waiting status. For others, a simpler deterministic rule may cover a narrow subset. Avoid turning uncertainty into a guessed answer merely to keep a green indicator on the dashboard.

Choose the fallback before cutover and test the transition in an isolated environment. Record which system is active so the team can explain a result after the change.

Make the deadline a small release

The next move is to inspect one important recurring job and identify its actual model dependency. If a retirement applies, name the owner, the acceptance cases, and the fallback in the same record.

For the wider vendor relationship, see When Your AI Vendor Walks Out the Door. A scheduled retirement is the smaller, more manageable case: there is time to rehearse if someone owns the date.

Source and scope

GitHub’s Copilot model-deprecation notice, September 18, 2026; October 19 is the announced future date as of this article. Scope is Copilot, not all provider APIs. The classification example and migration exercise are illustrative recommendations.