One of our most senior data scientists couldn't stop talking about Fable. She'd been testing it against Opus on her own work, and the gap wasn't subtle: faster answers, and on her tasks roughly eighty percent better. I haven't spent enough time with Fable myself, but I gladly take her word for it. And for someone who spends her days deep in hard problems, that eighty percent isn't a nice-to-have. That's a different working day.

A day later, it was gone. The US government issued an export control directive, Anthropic had to disable the model for everyone, and the best tool she'd used all year simply stopped existing. No warning, no migration path, no appeal.

In her case, the loss was survivable. She went back to Opus, lost some speed, and her work continued. The tool got better and then worse, but the way she worked never depended on it. That detail is easy to miss in the noise about which model is ahead this month, and it's the whole point.

Now move that same event into the middle of a core business process. Not a model helping a person work faster, but a model doing a step the business now runs on: pricing, fraud checks, customer service, replenishment. When that model vanishes or changes, there's no quiet fallback. The old way of doing the work is usually gone, because replacing it was the goal.

This is the asymmetry that matters. You can roll back AI that makes people more effective. They'll complain, they'll be slower for a while, but the previous way of working is still there to return to. You cannot roll back AI you've wired into a process that depends on it. There's no previous way left.

And you don't need a government for this. The more likely threat is cost, and it's already arriving. Over the past year Amazon, Walmart, Cisco, Uber and Meta pushed their people to use AI, some even ranking employees on how much they used. Now the same companies are capping that usage [Paywal], because the bills surged once chatbots gave way to agents that keep running on their own and pricing moved from flat subscriptions to paying by the token. One company's AI spend reportedly jumped sevenfold in a single day when its plan switched.

Notice what those examples share: they're capping people, not processes, and that's the easy case. Helping individuals work faster is useful, but its impact is bounded, which is exactly why it's painless to roll back when it gets expensive. The prices behind all of it are subsidized, the labs lose money serving them, and it isn't permanent. I've argued that AI's strategic value lies in what falling costs unlock. That same threshold also moves back up, and a use-case that adds up today can stop making sense when the price corrects.

The hard case is the process. There's no cap-and-carry-on when a core process gets too expensive. You can't pull the model out of pricing or fraud checks because the bill tripled, and unlike an employee, the process has nothing to fall back on. You've become a price-taker on a capability you don't own.

This is where most AI strategies fall down. A lot of them amount to giving everyone a frontier model license and calling it a plan: a mile wide and an inch deep. That buys associate effectiveness, which is worth having, but it's the bounded, reversible part. The harder question is the one they skip: when you put AI inside a mission-critical process, how do you keep it running if the price climbs or the access changes?

What I'm working on now is how to govern and combine frontier and open-weight models so the workloads that matter aren't hostage to one vendor's pricing or one government's directive. As Daniel Mügge argues, a great deal of real AI work doesn't need the enormous compute the frontier labs assumes. Owning that layer isn't a downgrade. It's a different trade, and for a process that you depend on, often the better one.

Every model you build into a process that can't stop is a dependency you're choosing. Right now most organizations choose theirs by accident: by enthusiasm, by whatever happened to be best the week the project started. Fable was best for three days. The question worth asking before you embed any model that isn't yours isn't which one is best today. It's which dependencies you can still live with when today is over.