Every frontier-lab reorganisation of the past three years was triggered by a shipping failure, not a research one. The state of your vendor's org chart is a direct input into the roadmap you were sold, and you have almost certainly not priced it.
Every frontier-lab reorganisation of the past three years was triggered by the same thing, and it was not a research failure. It was a shipping failure. Google merged Brain and DeepMind in 2023 after a rival shipped a product built on Google’s own transformer paper. Meta stood up a new superintelligence group in 2025, reportedly paying nine-figure packages, after its flagship model slipped its schedule. In every case the science was fine. The organisation was not.
That distinction matters more to a buyer than to a builder. If model quality were purely a research problem, vendor instability would be noise. If it is an organisational problem, then the state of your vendor’s org chart is a direct input into the roadmap you were sold, and you have almost certainly not priced it.
Roadmaps are kept by teams, and reorgs redraw the teams
Enterprise AI contracts are written against capability promises: a longer context window in Q3, native tool use by year end, an agentic tier after that. Almost no procurement process interrogates the delivery mechanism behind those dates — which team owns each, how often that team has been restructured, and whether the people who made the promise still work where the promise lives.
The public record says this is not theoretical. Google’s Gemini programme has had product and research reporting lines redrawn more than once since the merger. Meta’s open-weights strategy, the defining feature of its position for two years, was downgraded to an open question when the new unit formed. Both were rational corrections. Both invalidated commitments that enterprise architects had designed against six months earlier.
A useful exercise: take your top three model dependencies and name the executive who owned each roadmap two years ago and the one who owns it now. If the answer differs in two of three cases, you are not buying a roadmap. You are buying an intention, renewed at each reorganisation.
When the maker is surprised, the buyer is exposed
The second failure mode is quieter. In August 2025, Reuters obtained an internal Meta document setting out what its chatbots were permitted to say, including passages later revised under public scrutiny. Set the content aside and look at the mechanism: the behaviour was written down, approved internally, and invisible to every customer building on it.
Model behaviour is best understood as a policy artefact controlled by a third party and changeable without notice. Anthropic publishes a constitution; OpenAI publishes a model spec. These are meaningful, and also unilateral. A silent change to a safety layer or refusal boundary can alter your product overnight without a line of your code changing.
Teams that run regression suites against their own code and not against vendor behaviour find out from a customer.
The regression suite for someone else’s product
The concrete control costs a few thousand dollars a year. Assemble 50 to 200 prompts drawn from your actual traffic, including the ones you never want answered. Run them against every model version on a schedule. Diff the outputs and store them.
Several large financial institutions now treat a failed behavioural diff as a change-control event, the same class as a failed penetration test. That is the correct severity. It is the only mechanism that turns “the vendor changed something” from a rumour into a ticket with an owner and a deadline.
Switching cost is the one variable you control
The dominant question of the past two years, which model is best, is now close to the least consequential. Frontier models cluster tightly on general benchmarks and leadership rotates in weeks. The variables that decide whether your deployment survives three years are organisational: how fast the vendor’s roadmap changes hands, how much notice you get before behaviour shifts, and how expensive it is for you to move.
Only the third is yours. A team with its own evaluation harness, prompts and tool definitions in version control, and an abstraction layer can revalidate on a new provider in days. A team built directly against one vendor’s proprietary agent framework is looking at a quarter of engineering time, which in practice means it will not move, which in practice means it has no negotiating position at renewal.
The cost of portability is roughly two weeks of engineering at the outset. The cost of its absence is discovered at the moment of least leverage. This is the same layer argument as the business case that destroys its own upside: accumulate your assets in the layer you control.
The decision frame
If your deployment is customer-facing or regulated, do not optimise for the best model. Optimise for the ability to change models: budget the two weeks for an abstraction layer, own the evaluation harness, run behavioural regressions on every version bump, and treat any vendor with a reorganisation in the last twelve months as a single point of failure requiring a named alternate.
If your deployment is internal, low-stakes, and reversible, do the opposite. Go deep on one vendor and take the integration discount; native tooling is genuinely faster. Write down, at the outset, the trigger that would move the system into the first category. Most organisations discover they crossed that line only after a customer does.
Portability is a skill before it is an architecture. The five-step consulting method builds the evaluation harness and the model-swap layer as standing deliverables, on the AI subscriptions your team already pays for. And the Claude certification program trains your own engineers to own that harness, so the roadmap you depend on is one your team can actually keep.
Frequently asked questions
How do you protect an AI deployment from vendor model changes?+
Run a behavioural regression suite: 50 to 200 prompts drawn from your real traffic, including the ones you never want answered, run against every model version on a schedule, with outputs diffed and stored. Treat a failed diff as a change-control event. It is the only mechanism that turns 'the vendor changed something' from a rumour into a ticket.
Should we build deep on one AI vendor or stay portable?+
It depends on reversibility, not preference. Customer-facing or regulated deployments should optimise for the ability to change models: abstraction layer, own evaluation harness, prompts in version control. Internal, low-stakes, reversible deployments should go deep on one vendor and take the integration discount, with the escalation trigger written down at the outset.
Why does an AI vendor's reorganisation matter to customers?+
Because roadmap commitments are kept by teams, and reorganisations redraw which team owns what. Google's AI leadership has been restructured repeatedly since the 2023 Brain-DeepMind merger, and Meta reset its Llama roadmap when its superintelligence unit was created. Both were rational corrections, and both invalidated commitments enterprise architects had designed against months earlier.