The New Model Is a Blueprint for Surviving Without It
I got access to Fable 5 and the first question was obvious: what can I build? Then the clock showed up. And the question shifted. If I only have two weeks with this, how do I make it last? That question changed everything I did with the time.
A new flagship model dropped last week. Claude Fable 5. It is fast, it has a million-token context window, which means it can hold roughly a full workday of material in mind at once, and it can keep a goal in view across that whole day without you babysitting it. The benchmarks are real. People are already rebuilding their whole stack around it.
I want to argue against that instinct. Not the model. The instinct.
Here is what happened to me first, before any of the excitement. I got access. And the first instinct was the obvious one: what can I build?
Then the clock showed up. The access is metered, the window is finite. And somewhere in the first few days of using it, the question shifted. Not what can I build. If I only have two weeks with this, how do I make it last?
That question changed everything I did with the time.
The window is expensive and short, so don’t spend it on toys
When a model like this lands, the temptation is to build something flashy. A new agent. A new demo. The clever thing you can show people. And the access is metered and pricey, so you feel a clock running, which makes you want to spend the cycles on something impressive.
Resist that.
Spend the expensive cycles hardening what you already run. Review your actual systems, find the brittle joints, improve the workflows that real money already flows through. A flashy new build is one more liability you have to maintain. A hardened existing system is value you already paid for and rarely go back to claim.
The most valuable thing you can do with a frontier model is not build a new thing. It is to understand how the thing is built, and steal the architecture for your own setup.
The failure mode nobody plans for
Let me say the quiet part plainly. If your business runs on a remote model, that model is a single point of failure for your business.
Not “a risk.” A single point of failure. The kind that, when it goes, takes the whole thing with it.
I have not been burned by this yet. That is exactly why I am thinking about it now, while the lights are still on. Because none of it is exotic. Vendors have outages. Accounts get flagged. Terms change. Prices move. Models get deprecated and the new one behaves differently. None of that is a black swan. All of it is Tuesday.
The question is not whether it happens. The question is what your business does the morning it does.
So ask yourself the uncomfortable one. If you lost access to your AI tomorrow, how does your business run? Walk it through. The client onboarding that quietly leans on an automation. The follow-up that fires from a workflow you forgot you built. The knowledge that only lives inside a chat session you can no longer open.
If the honest answer is “it mostly stops,” you do not have a tooling problem. You built your operation on rented ground.
The fix is hiding in how the new model actually 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 baked into the system directive the model runs under, the standing instruction that sets its operating rules. The instruction reads, almost word for word: assume interruption. Your context may reset at any moment. In plain terms, when the model’s short-term working memory fills up and gets cleared to make room, it has to be ready to lose what it was holding.
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 that working memory gets cleared, the memory files are explicitly excluded from the wipe, because those files are what survive the reset. And when several copies of the model work together on a hard problem, they coordinate through Git, a kind of save button that never overwrites: every version is kept, stamped with what changed and when. Every change to their shared memory lands on a timeline you can read, roll back, and audit.
Sit with that for a second.
The most advanced AI system available was designed by people who assumed the worst-case interruption and built for it anyway. Files are the source of truth. Memory is protected from being wiped. The timeline of changes is versioned in Git.
That is not just how a good model works. That is how a durable business works.
The model’s own design is the blueprint for not being dependent on the model.
Three moves to copy from the architecture
You do not need to be an engineer to apply this. Translate the three ideas and run them on your own operation.
1. Files are truth. In Fable 5, the canonical knowledge lives in plain files, not trapped inside a session that can vanish. Do the same. Your SOPs, your client notes, your offers, your decisions, the actual content of your business should live in files you own and can open without anyone’s permission. A chat history is not a system of record. A folder of readable files is.
2. Assume interruption. The model writes things down because it expects to get cut off. Build that same reflex. Anything important that currently lives only inside an AI tool should be exported, written down, and saved somewhere you control. If a single account suspension would erase it, it was never really yours.
3. Git is the timeline. This is the move most people skip, and it is the one that separates “I have a backup” from “I have a system.” Git gives you a versioned history of every change. Not one snapshot, but the whole timeline, with the ability to see what changed, when, and to roll back when something breaks. The multi-agent version of Fable 5 treats its memory exactly this way. Your business knowledge deserves the same treatment.
Here is the difference those three moves make, in plain terms.
| Situation | Renting the ground | Owning the ground |
|---|---|---|
| Vendor outage | Operations stop | You switch tools, keep working |
| Account suspended | Knowledge is gone | Files are local and backed up |
| Model deprecated | Workflows break silently | Portable files move to the next model |
| A change breaks something | You guess what changed | Git shows you, you roll back |
| New team member or agent | Tribal knowledge in someone’s head | Readable files anyone can pick up |
What this looks like for a normal operation
I run an AI-native business, so I am already partway down this road. My team’s shared knowledge lives in markdown files, which are just plain readable text files. Those files are versioned in Git, so every change is saved as a numbered, reversible point in a timeline, and I have a record of every change to how the business thinks and operates. The AI tools read from those files, but the files do not depend on the tools. If a model disappears tomorrow, the brain of the business is still sitting on disk, backed up, and ready for whatever comes next.
That is the whole point.
The tool is a tenant. The files are the property.
You do not have to do all of this at once. Start with the simplest version.
This week, pick the one workflow that would hurt the most if it vanished. The one you depend on without thinking about it. Find where its knowledge actually lives. If the answer is “inside an AI tool,” pull it out into a file you own, and save that file somewhere a vendor cannot reach.
That is one workflow made durable. Do the next one next week.
The frontier model is exciting, and you should use it. Use it to harden what you already run. Use it to study how durable systems are built. And then build yours the same way, so that the day the rug comes out, and for someone it will, losing access is an inconvenience and not the end of your business.
If you lost access tomorrow, how does your business run? Answer that honestly, then go make the answer better.
Frequently Asked Questions
What is the biggest lesson from Claude Fable 5 for business owners?
The model is designed to survive interruption. Its system directive tells it to assume its context can reset at any moment, so it writes durable state to files, protects that memory from being wiped, and versions changes in Git. That same discipline, files as truth and a versioned timeline, is exactly what makes a business durable if it loses access to AI.
How do I make my business durable if I lose access to AI?
Stop storing critical knowledge only inside AI tools. Export your SOPs, client notes, offers, and decisions into plain files you own. Back those files up somewhere a vendor cannot reach. Version them in Git so you have a full timeline of changes you can roll back. Then your tools become replaceable and your knowledge stays put.
Should I rebuild my stack around every new AI model?
No. New frontier access is expensive and short, and a flashy new build becomes a liability you have to maintain. Spend the cycles hardening the systems real money already flows through. The highest-value use of a new model is studying how it is built and applying that architecture to your own operation.
Why use Git for business knowledge instead of just a backup?
A backup is one snapshot. Git is the whole timeline. It shows you what changed, when, and lets you roll back when something breaks. Anthropic’s own multi-agent setups coordinate shared memory through Git for exactly this reason: provenance, rollback, and an auditable history. Your business knowledge deserves the same protection.
What does “files are truth” actually mean for a non-engineer?
It means the canonical version of your business knowledge lives in readable files you control, not inside a chat session or a tool’s database you cannot export. The AI can read and update those files, but the files do not depend on the AI. If the tool disappears, the knowledge is still yours, on disk, ready for the next tool.
Want a second set of eyes on where your business is renting ground it should own? That is the kind of thing I help leaders sort out. Start with the diagnostic at davidchung.ai.