Disclosure: I use Claude every day. This piece is not about Anthropic being risky. It's about what happened to them being impossible to see coming, no matter how good they are.
Four separate shocks hit the same AI vendor in six months. Not one of them was a bug.
In February, the Pentagon labeled Anthropic a supply chain risk and directed every federal agency, not just defense, to stop working with them. In May, a shift to token-based pricing ran one customer's spend up 7x on day one. On June 12, a Commerce Department export control directive took two of their newest models offline for every user on the planet within hours, three days after launch, because the order barred access by any foreign national anywhere and nobody could verify nationality in real time. On August 27, a federal judge threw out the February designation as unlawful, arbitrary and capricious, and retaliatory.
Go back through that list and find the technical defect. There isn't one. The software worked the entire time.
That's the part practitioners need to sit with. Every risk framework we run assumes the risk lives in the thing we're assessing. Architecture review, vendor questionnaire, penetration test, SOC 2 report, code scan. All of it points at the product. Four times in six months, the product was fine and the outcome was the same as if it hadn't been.
Why I stopped saying "replaceable"
I wrote earlier this year that replaceability is the most important non-functional requirement in enterprise AI. I still believe the argument. I've changed the word.
"Replaceable" is soft. Worse, it's binary, and binary questions in an architecture review get binary answers. Ask a team "is this replaceable?" and you'll get a yes, because technically everything is replaceable. Check the box, move to the next item, ship the design. The question created an excuse instead of a finding.
Ask "quantify the fungibility of this component in the stack" and something different happens. Nobody has a reflexive answer. Somebody has to go look. Half the room isn't sure what you mean, which is exactly the friction you want, because the conversation that follows is the one that produces the design.
Replaceable is a boolean. Fungible is a measurement. That's the whole reason for the word.
The slot, not the component
A purist will tell you fungible means equivalent, one unit substituting exactly for another, like dollars or barrels of oil. And they'll point out that models obviously aren't equivalent, that different models are good at different things, that this is the entire reason you run seven of them instead of one.
They're right about the models. They're aiming at the wrong object.
The thing you're making fungible isn't the component. It's the slot. You're declaring that a given position in your architecture accepts fungible units, and that declaration is what forces you to define the contract that makes them substitutable. The components stay different. The slot doesn't care. That's the difference between an abstraction layer you meant to build and an abstraction layer you actually specified.
If your development harness isn't married to a single frontier model, you're fine. You watch the news, you swap, you keep shipping. If you're married, your options are to accept a risk you didn't choose, take the innovation hit and freeze, or find some middle position that's still bad. Three doors, all worse than the one you'd have had if you'd priced the swap up front.
We solved this already, in a different department
There's a story that gets told in operations circles. A manufacturer's revenue slumps every fourth quarter and nobody can explain it. Demand is healthy, orders keep coming, product keeps going out the door, and then it doesn't. Somebody finally maps the bill of materials against component lead times and finds it: one cheap part, one supplier, one annual holiday shutdown, a two or three week hole in the calendar, and no safety stock because the company was buying that supplier's entire output. The fix was a second supplier at a higher unit cost, contracted only for the volume needed to bridge the gap. A rounding error against the revenue it unblocked.
I've heard versions of that story for twenty years and I've never been able to source the original, which probably means it's happened more than once.
The mechanism is real and it has a name. Allon and Van Mieghem formalized it in Management Science in January 2010 as tailored base-surge: replenish continuously at a constant rate from the cheap offshore source, and fire the expensive fast source only when inventory drops below target. Operations research solved this sixteen years ago and published the policy.
Nobody in manufacturing calls dual sourcing over-engineering. They call it Tuesday. We only call it over-engineering when the component is a model.
Your Center of Excellence is aimed at the wrong target
Almost every AI Center of Excellence conversation I hear is about operationalizing use cases, publishing standards, and defining the golden path. That work matters. It's also not the hard part, and it's not what makes a CoE valuable.
Think about the other CoE. The Army Corps of Engineers was probably a hard sell at the start. Why fund civil engineers for an operation where everything moves and everything is transient? The answer turned out to be that logistics is the one capability no other military can match, and it came from building things correctly and to endure rather than awarding to the lowest bidder. And when the mission changes, the output of the Corps changes with it. That's the model.
Your AI CoE should be running skunkworks against your own stack, continuously, on purpose. Not pilots of new use cases. Attacks on your own dependencies. Model, harness, skills and agents, input and output handling, second brain, data systems, and compute across local, remote, and API.
I do this myself and the returns are not theoretical. Reviewing model selection and the input system at a prior company produced a 95% cost reduction in April, and output quality went up at the same time. That's what testing your own stack buys you.
It buys something else too, and this is the part nobody warns you about. You can't test a system without a firm grasp on which inputs and outputs are good enough for your business. So the testing forces you to define good enough, use case by use case, and you find out what you actually needed instead of what you assumed at kickoff. Perfection is impossible. Getting closer is not.
What you actually measure
If fungibility is a measurement, you owe your architects a number. Five to start:
- Swap time. Wall clock from decision to production on the alternate.
- Interface coupling. How much application code knows the vendor's name.
- Data gravity. What has to move, and who bills you for moving it.
- Contractual exit. Notice periods, minimums, and what you forfeit walking away.
- Eval portability. Whether your evaluation suite runs against the substitute unchanged, or you rebuild trust from zero.
Score them per slot. Publish the scores. Argue about the ugly ones.
What to do about it
TO EXECUTIVES: Say out loud that fungibility is non-optional, and fund the swap path in the same breath as the deployment. Your architects already want to do this work. Right now they're absorbing the political cost of asking for it, and losing, because it looks like waste on a budget line and there's no incident to point at yet. There will be. Give them air cover before it shows up.
TO ENTERPRISE ARCHITECTS: Stop asking whether a component is replaceable. Quantify the fungibility of the slot it sits in, define the contract that makes any qualified unit substitutable there, and put the score in the design review. A number survives a steering committee. An assurance does not.
TO AI CENTER OF EXCELLENCE LEADS: Standardization is half your job. Stand up the skunkworks for the other half, point it at your own stack, and report swap readiness the way you report uptime. If you can't tell your CIO how fast you could move off your primary model, you don't have a CoE. You have a style guide.
Design for the state of flux, because flux is the steady state now. Have a backout plan, which is not a backup plan and has nothing to do with restoring data. And price the second supplier before the holiday, not during it.