Founders are optimizing for AI features when they should be building for AI fragility

On June 12, 2026, Anthropic launched Fable 5 and Mythos 5. Three days later, the U.S. Commerce Department issued an export control order and Anthropic had to kill them. For every customer. Globally. Immediately.

Anthropic's own words: "the net effect of this order is that we must abruptly disable Fable 5 and Mythos 5 for all our customers to ensure compliance."

This was not a bug. This was not a data breach. This was a government order that reached into production systems and flipped a switch. Stripe integrations, Mozilla workflows, Amazon Bedrock deployments. All of it, gone overnight.

If your product depends on an AI model and you are reading this, that sentence should bother you.

This Did Not Come Out of Nowhere

The political backdrop matters. In February 2026, the Trump administration ordered federal agencies to stop using Anthropic models after Anthropic refused Pentagon contract terms. The sticking point was a requirement that the models could be used for autonomous weapons systems and mass domestic surveillance. Anthropic said no. The federal government said fine, we are done with you.

That was a signal. The relationship between AI labs and the U.S. government is not stable. It is actively contested. And in that contested environment, your product roadmap is a hostage.

Then came June 13. The Commerce Department export control order did not just affect federal agencies. It hit every paying enterprise customer Anthropic had, worldwide. The labs that refused to compromise on ethics still got caught in the crossfire. Good intentions did not protect the customers.

And if that were not enough, Anthropic also reversed a billing overhaul on June 15, pulling back changes on the exact day they were supposed to go live. They are also currently being sued over misleading usage limits.

A model shutdown. A pricing reversal. A lawsuit over usage claims. In the span of one week.

The Illusion of Stability

81% of enterprise leaders say they are concerned about AI vendor dependency. I believe them. I also believe they are signing longer contracts, going deeper on API integration, and training their teams on model-specific tooling every single quarter. The concern is real. The behavior does not match.

Most founders I talk to have the same mental model: pick the best model, build fast, iterate on features. The assumption baked into that model is that the foundation is solid. That the API will be there tomorrow. That pricing is predictable. That access is a given.

June 13 broke that assumption in public, in real time, for some of the most well-resourced engineering teams in the world. Stripe did not see it coming. Amazon Bedrock integrations did not see it coming. If they could not absorb that shock gracefully, what happens to your startup?

The real risk is not that AI models get worse. They are getting better. The real risk is that they can be switched off, repriced, or legally constrained overnight. You are building on infrastructure that a single government order can make illegal to use. That is not a technology risk. That is a political and regulatory risk, and it compounds fast.

What Building for Fragility Actually Looks Like

I am not saying stop using AI. I am saying stop building as if the model will always be there.

Model abstraction layers are not a nice-to-have. They are table stakes. Your application logic should not know which model it is talking to. It should call an interface that can route to Claude, GPT-4o, Gemini, Llama, or a fine-tuned open-source model depending on what is available and what is compliant at that moment. That routing layer should be part of your architecture on day one, not a migration project you do after the first outage.

Fallback routing needs to be real, not theoretical. I have seen teams build a fallback that technically works but has never been tested in production. When a model goes dark, your on-call engineer should not be the one figuring out whether the fallback actually handles edge cases. It should already be battle-tested.

Open-source contingency is not about cost savings. It is about sovereignty. Models like Llama 3 and Mistral exist, they run on infrastructure you control, and no export control order issued in Washington can disable them at midnight. You do not have to run entirely on open-source. But you should be able to, for your most critical flows, within hours if you need to.

None of this is exotic engineering. Teams have been building multi-provider redundancy for payments, for cloud infrastructure, for messaging. The same logic applies here. The question is whether you treat AI as infrastructure or as a feature. If it is infrastructure, you architect for failure. If it is a feature, you build until it breaks.

The Founders Who Will Be Fine

The founders who come out of this period well are not the ones with the best prompts or the most sophisticated model fine-tuning. They are the ones who treated the AI layer as inherently unreliable from the start.

They have a model router. They have tested fallbacks. They have identified the three or four flows where model availability is existential, and they have open-source options ready for exactly those flows. They have not over-indexed on model-specific capabilities that would disappear if they had to switch providers.

That discipline costs something upfront. It slows the first sprint. It feels like over-engineering when the API is responding fine and the model is improving every month. It is exactly the kind of thing founders deprioritize when they are moving fast.

But June 13 happened. And it will happen again, in some form, because the regulatory and geopolitical environment around AI is not stabilizing. It is getting more complicated. Export controls, usage litigation, pricing disputes, government pressure on labs to do things the labs do not want to do. This is the environment. Build for it.

Build for Fragility, Not Features

If you are a founder with AI at the core of your product, here is what I want you to take away from this.

Stop optimizing purely for capability. The model will get more capable whether you focus on it or not. Start optimizing for resilience. Your architecture should be able to absorb a sudden model disappearance without a production incident that takes down your product.

Ask yourself today: if the model I depend on became unavailable at midnight tonight, what would break, how long would it take to recover, and do I have a tested path to something else? If you cannot answer that with confidence, you have a fragility problem, not a feature problem.

The founders who ask that question now, and build the answer into their architecture, are the ones who will still be running when the next government order drops.