Your most important dependency can be switched off by someone you have no contract with.
This week Anthropic disabled access to Fable 5 and Mythos 5 — globally, after an export-control directive. The model did not change. What changed is that its availability is now a function of state policy, not of your adoption plan. And that policy moves faster than teams can re-architect.
What interests me here is not the specific case. It is the shape of the problem. Across different industries and systems, I have learned that nobody chooses a monoculture on purpose. It accumulates. One provider is more convenient. One type of model is "better on benchmarks." The integration goes a little deeper than it should. And then at some point you simply have no way out — and you did not notice, until the bill arrived from a direction you never priced in.
Resilience is not "keep a backup vendor." It is the right to substitute. A system should be designed so that swapping a provider or a model type does not mean rewriting half the architecture. Boundaries, abstractions, portable context — that is what separates "we can leave in a week" from "we are hostages."
And for a company, this is first of all about control. When a load-bearing dependency is governed by policy, pricing, or decisions you do not influence, you do not own your system. You rent it on someone else's terms. Control here is not the right to the source code. It is the ability to keep operating when the terms change against you.
To be fair: full independence is expensive and not always needed. Not every system has to be multi-stack, and premature abstraction is its own debt. The question is not to avoid dependency at any cost. It is to know where a dependency is load-bearing — and to buy yourself the right to substitute exactly there.
The best time to design the exit is long before someone outside decides you will not have one.