Last week a flagship model shipped. Claude Fable 5. Fast, a million-token context window, the kind of capability that makes a leadership team want to rebuild everything around it by Friday.
I want to argue against that instinct. Not the model. The instinct.
Most people missed this in the launch noise. The most advanced AI system on the market was designed by people who assumed it would lose access to itself. That assumption is built into how it operates. And that assumption, copied up to the level of an organization, is the most important AI decision your leadership team will make this year.
It is not which model you license. It is whether you own the ground underneath it.
The failure mode nobody puts on the risk register
Say the quiet part plainly. If your operation runs on a remote model, that vendor is a single point of failure for your business.
Not “a vendor consideration.” A single point of failure. The kind that, when it goes, takes real operations with it.
This does not require a disaster. Vendors have outages. Accounts get flagged. Terms change. Prices move. A model gets deprecated and the replacement behaves differently enough to break the workflow you quietly built on top of it. None of that is a black swan. All of it is a normal Tuesday in a vendor relationship you do not control.
So the question for the leadership team is not whether it happens. It is what the business does the morning it does.
Walk it through honestly. The client onboarding that leans on an automation nobody documented. The reporting that fires from a workflow one person built and then left. The institutional knowledge that now lives inside a chat history, on a vendor’s servers, in an account you do not own.
If the honest answer is “a lot of it stops,” you do not have a tooling problem. You built part of your operation on rented ground.
The blueprint is hiding in how the new model works
Here is the part that made me sit up.
Fable 5 is architected to survive interruption. That is not a marketing line. It is built into the system directive the model runs under, the standing instruction that sets its operating rules. The instruction, in plain terms, is this: assume your working memory can be wiped at any moment, so do not depend on it.
So the model behaves accordingly. It does not hold everything in its head and hope. It writes durable state to files as it works. When its short-term memory gets cleared to make room, those files are deliberately protected from the wipe, because the files are what survive. And when several copies of the model work a hard problem together, they coordinate through Git, a versioning system that never overwrites. Every change to their shared memory lands on a timeline you can read, audit, and roll back.
Sit with what that means.
The smartest system available was engineered by people who treated loss of access as the default condition and built for it anyway. Files are the source of truth. Memory is protected from deletion. The history of every change is versioned and reversible.
That is not just how a durable model works. That is how a durable organization works.
The model’s own design is the blueprint for not being dependent on the model.
Three principles to lift up to the org level
You do not need an engineering team to apply this. Translate three ideas and run them against your operation.
1. Files are truth becomes knowledge you own. In Fable 5, canonical knowledge lives in plain files, not trapped inside a session that can vanish. Do the same at the company level. Your SOPs, your client records, your offers, your decisions, the actual operating knowledge of the business should live in formats you own and can export, not locked inside a vendor’s database you cannot get out of cleanly. A chat history is not a system of record. Knowledge you can take with you is.
2. Assume interruption becomes business continuity. The model writes things down because it expects to get cut off. Build the same reflex into the org. Anything important that currently lives only inside an AI tool should be exported and stored somewhere you control. If a single account suspension would erase it, it was never really an asset on your books.
3. Git is the timeline becomes governance. This is the principle leaders already understand under different names: provenance, change control, auditability, rollback. Versioning is not one snapshot. It is the whole history, with a record of what changed, when, and by whom, and the ability to revert when something breaks. The multi-agent version of Fable 5 treats its memory exactly this way because the alternative is untraceable drift. Your institutional knowledge deserves the same protection, and your auditors will eventually ask for it.
Here is the difference those three principles make.
| Situation | Renting the ground | Owning the ground |
|---|---|---|
| Vendor outage | Operations stall | You switch tools and keep moving |
| Account suspended | Knowledge is gone | Records are exported and held |
| Model deprecated | Workflows break silently | Portable knowledge moves to the next model |
| Something breaks | The team guesses what changed | The timeline shows you, you roll back |
| Leadership transition | Knowledge walks out the door | Readable records anyone can pick up |
Why this sits with the CAIO, not the IT queue
It is tempting to route all of this to IT as a procurement and security task. That is a mistake, and it is the mistake that quietly decides your company’s leverage for the next five years.
Picking a vendor is an IT decision. Deciding whether your business depends on that vendor is a strategy decision. They are not the same conversation, and the second one rarely happens, because no single team owns it.
That is the gap a Chief AI Officer fills, formal title or fractional advisor either way. Someone has to own the question that crosses every department: where is the business renting ground it should own, and what does it cost us the day the rent comes due. IT can implement the answer. It cannot be the one to ask the question, because the question is about the business, not the stack.
Owning your ground is leverage. The organization that owns its knowledge can adopt the next model faster, switch vendors without fear, and negotiate from a position where walking away is real. The one renting everything cannot. It can only hope the terms hold.
Where to start this quarter
You do not have to fix everything at once. Start with the simplest version of the audit.
Pick the one workflow that would hurt the most if it vanished tomorrow. The one a department depends on without thinking about it. Find where its knowledge actually lives. If the answer is “inside an AI tool we do not control,” that is your first export. Pull it into a format you own and store it somewhere the vendor cannot reach.
That is one workflow made durable. Assign the next one next quarter.
The frontier model is genuinely useful, and your organization should use it. Use it to harden what you already run. Use it to study how durable systems are built. Then build yours the same way, so that the day access disappears, and for some company this year it will, it is an inconvenience and not a crisis.
If you lost access tomorrow, how does the business run? Answer that honestly in your next leadership meeting, then go make the answer better.
Frequently Asked Questions
What is AI vendor risk, and why should leadership care?
AI vendor risk is the exposure a business takes on when critical operations depend on a remote AI model it does not control. If the vendor has an outage, suspends the account, changes its terms, raises prices, or deprecates the model, the dependent workflows break. This is a business continuity issue, not just a procurement one, because the failure modes are routine rather than rare. Leadership should care because the risk crosses every department that has quietly built AI into how it works, and no single team owns the question of what happens if access disappears.
Is choosing an AI vendor a CAIO decision or an IT decision?
Both, but they are different decisions. Selecting and implementing a vendor is an IT decision about tools, security, and integration. Deciding whether the business should depend on that vendor at all is a strategy decision about leverage and continuity, and that belongs with a Chief AI Officer or equivalent leadership owner. IT can implement the answer, but the question, where is the business renting ground it should own, is about the business itself and crosses department lines. That is why it usually goes unasked.
How does an organization reduce dependence on a single AI vendor?
Start by making the knowledge portable. Store SOPs, client records, offers, and decisions in formats the company owns and can export cleanly, not locked inside a vendor’s database. Version that knowledge so you have an auditable history of what changed and the ability to roll back. Identify the workflows that would hurt most if access vanished, and make those durable first by pulling their knowledge out of tools you do not control. The goal is that the tools become replaceable while the knowledge stays put.
What can a frontier AI model teach a leadership team about business continuity?
The newest models are engineered to survive losing access to their own working memory. They write durable state to files, protect that memory from being wiped, and version every change so it can be audited and reversed. That architecture is a direct blueprint for an organization: own your knowledge in portable formats, protect it from a single point of failure, and keep an auditable timeline of changes. The smartest systems available are built to not depend on any single point of failure, and a business should be built the same way.
Where is your business renting ground it should own? That is the question I help leadership teams answer. Start with the diagnostic at davidchung.ai.