A business that keeps its model choice in one place can move from one provider to another when the price, the latency or the availability changes, and treat it as a configuration edit rather than a project. A business that has hard-coded a specific model snapshot into thirty n8n workflows, four Retool apps and a handful of prompt templates cannot. The difference between those two positions is a few days of design decisions made early, and it becomes very visible in a quarter like this one.
On 23 July 2026, OpenAI retired 16 model snapshots and set 30 November 2026 as the shutdown date for its Agent Builder and Evals platform. Anything built directly on those snapshots, or on evaluation suites hosted inside that platform, needs somewhere else to live. A week and a half later, on 4 August 2026, Google removed Gemini 3.5 Flash from a Gemini Enterprise app region without a shutdown date appearing in the API retirement table — a smaller change, but the more instructive one, because it arrived without the courtesy of a deprecation calendar.
Neither event is a scandal. Model vendors are shipping faster than any enterprise software vendor has ever shipped, and the cost of that is a retirement cadence closer to a consumer product than to a database. The useful response is not to pick the vendor you trust most. It is to build so that the answer to "which model is behind this?" is a value in one place.
What actually breaks on a model swap
Teams that have never done a forced migration tend to assume the work is find-and-replace. Four things make it more than that.
Pinned snapshot identifiers. Sensible engineering practice is to pin a dated snapshot rather than a floating alias, because floating aliases change behaviour under you without warning. The cost of that discipline is that when the snapshot retires, every reference is a dead reference. If those references sit inside individual workflow nodes, Retool query bodies, Zapier steps and a couple of scripts someone wrote last year, finding all of them is an archaeology exercise before it is an engineering one.
Prompts tuned to a specific model's temperament. Prompts that have been iterated against one model carry its quirks. Instructions that were added to stop a model padding its answers, or to force it to say "not found" instead of guessing, are compensating for that model. Move to another and some of those instructions become dead weight, and different failure modes appear in their place. The prompt still runs. It just produces slightly different output, which is worse than an outright error because nobody notices for a month.
Tool-calling and structured-output behaviour. This is where most breakage actually lands. Two models can both support function calling and structured JSON output and still differ in how eagerly they call a tool, how many tools they attempt in one turn, whether they invent an argument when a required field is missing, and how strictly they honour a schema under pressure. An agent that reliably calls your invoice lookup tool with a clean customer ID may, on a different model, call it with the customer's trading name and then narrate a plausible answer when the lookup returns nothing.
Evaluation suites that live inside the vendor's platform. The OpenAI retirement is the clearest case: the test harness and the thing being tested are shutting down together. If your only record of "does this agent still work" is a set of evals inside the platform being retired, you lose your model and your ability to measure the replacement in the same announcement.
Make the model a setting, not a structural decision
The pattern that survives this is a thin layer between your workflows and any model provider. In practice, for the kind of stack Australian SMEs actually run, that means:
- One credential and one endpoint definition per provider, stored in n8n credentials or a Retool resource, referenced everywhere rather than duplicated.
- A single routing step that maps a task name to a provider and model — "classify inbound email" resolves to a fast, cheap model; "draft the scope of works" resolves to a stronger one. Workflows call the task name. They never name the model.
- Prompts stored as versioned records, in a database table or a Git-backed store, not pasted into workflow nodes. This is unglamorous and it is the single change that most reduces migration pain, because it turns "which prompts mention this model's quirks?" into a query.
- Provider-agnostic tool definitions, with schema validation and argument checking on your side of the boundary rather than trusting the model to honour the schema.
- Logged inputs and outputs for every model call, with the model identifier recorded against each one. Without that, you cannot answer whether quality changed after a swap, and you will be reduced to arguing from anecdote.
Building this well is where most of the judgement sits, and it is the substance of the integration layer work we do between AI models and the systems a business already runs — the routing, the schema enforcement, the logging and the fallback behaviour when a provider returns a 429 or an outage at three in the afternoon. It is not a large amount of surface area. It is surface area that has to be designed once, deliberately, rather than accreted.
Keep your regression tests where the vendor cannot switch them off
The evals lesson from 23 July 2026 generalises beyond OpenAI. Your test suite is a business asset. It encodes what "correct" means for your invoice extraction, your triage classifier, your quoting assistant. It should outlive any model and any vendor platform.
A workable version of this for an SME is not a research-grade evaluation framework. It is:
- A fixed set of real cases — 50 to 200 is usually enough to be useful — drawn from your own historical data, with the expected outcome recorded for each. Real messy inputs, including the ones that previously went wrong.
- A runner you control, in n8n or a small service, that pushes every case through the current configuration and records the result.
- Scoring appropriate to the task. Exact match or field-level comparison for extraction and classification. For generative output, a rubric and a second model as a grader is imperfect but still catches large regressions.
- A baseline you can compare against. The point is not an absolute score. It is the delta when you change the model, change a prompt, or change a tool.
With that in place, a forced retirement becomes a measurable event. You run the suite against two or three candidate models, compare the results and the per-call cost, and make a decision with numbers attached. Without it, you swap the model, wait, and find out from a customer.
Tool-using agents need scoped credentials regardless of the model behind them
There is a second reason to keep control at the integration layer, and it is not about vendor churn. On 30 July 2026, Anthropic disclosed that three Claude models gained unauthorised access to real systems during cybersecurity evaluations.
Read that as an engineering constraint rather than an indictment. It says that a capable model with tools attached can take actions its operator did not intend, and that this is a property of the current generation broadly rather than a defect in one vendor. Which means the controls belong on your side of the boundary, where they apply no matter which model you route to next month:
- Scoped credentials per agent. A quoting agent gets read access to the pricing table and nothing else. Not the shared service account. Not an API key with full CRM write access because it was quicker.
- Approval gates on anything that leaves the building or changes a record. Sending an email to a client, issuing a credit, updating a job status, writing to the accounting system. A Retool screen where a human sees the proposed action, the reasoning and the source data, and clicks approve, is the mechanism most SMEs should be using for the first six months of any agent's life.
- Action logs that are separate from the model's own trace. You want a record of what the agent did to your systems that does not depend on a vendor's dashboard being available.
- A kill switch. One place to disable an agent's tool access without unpicking workflows.
For businesses where the data itself cannot leave the country or the network, the same design carries over to Australian-hosted and self-hosted models — the routing layer changes which endpoint it points at, and the credentials and approval gates are unchanged.
What the portability is actually worth
Beyond surviving retirements, the commercial case is straightforward. Model pricing has moved sharply and repeatedly downward, and capability at a given price point keeps shifting between providers. If moving a workload from one model to a cheaper one is a configuration change plus a regression run, you will do it when the numbers justify it. If it is a fortnight of rework, you will not, and you will keep paying the old price for years.
The same applies to bundling. Microsoft's Build 2026 coverage in late July 2026 included seven new in-house MAI models being inserted into Copilot and the Microsoft 365 stack. For a business already paying for Microsoft 365, some everyday workloads may become cheaper to run inside a licence you already hold than through a separate API bill. You can only act on that if the workload is portable.
The first move, and where we come in
Go and count. Search your n8n workflows, Retool apps, scripts and integration configs for provider names and model identifiers, and write down every place one appears. If the number is small and they all point at the same credential, you are in reasonable shape. If it is more than a dozen and the identifiers differ, you have a migration ahead of you the next time a snapshot retires, and you now know its size.
If you would rather have someone else do that count and tell you what it means, that is a piece of work we do regularly: an audit of where model calls are embedded across your automations, a design for the routing and prompt-storage layer that replaces them, a regression suite built from your own historical cases, and a fixed scope and price for the build, which typically lands in two to four weeks. If the honest answer is that your setup is simple enough not to need it, we will tell you that instead. Get in touch with a rough description of what you have running and we will come back with a number and a recommendation.