Fable 5 came out from Anthropic. Their next-gen model. Everyone I know spent the first few days doing the same thing, throwing work at it to see how capable it really is.
It’s really capable.
Here’s the catch. You only get it for a short window before it goes back on the shelf and is only reachable through the API. So you have a choice about how to spend that time. Most people used it to build more, faster.
I spent most of my window pointing it at my own systems and asking it how to upgrade them.
The best thing to do with a powerful new model is point it at the system it plugs into and make that system stronger. Keep a memory any model can read. Run more than one model, from more than one company, so none of them grades its own work. Own your files so the whole thing stays portable. Do that, and the next frontier model makes you better in an afternoon instead of forcing a rebuild. The model is 10 to 20 percent of the work. The rest is the system, and the system is what survives the swap.
Below are the questions founders keep asking me about this, and what I actually run.
A new AI model just dropped. Should I rebuild my workflow or upgrade my system?
Upgrade the system. Don’t rebuild the work. A better model is the small part, roughly 10 to 20 percent of what makes your output good. The other 80 percent is the memory it reads, the files it writes to, and the review gates it passes through. When a new model lands, you point it at that same system and it’s better the same day. No migration project.
I learned this the hard way, before there was a name for it.
Early this year I was running six AI tools. Claude, ChatGPT, Gemini, TypingMind, Genspark, Manus. Every one of them held a different or outdated version of my business. I was re-explaining who I was and what I did at the start of every session, in every tool. It felt like a memory problem. It was a missing system.
So I built the system that was missing. One private git repo as the single source of truth. Structured markdown, split by domain, services, marketing, SOPs, brand, me. Any tool loads only the part it needs. I skipped the easy option of keeping it all in Notion, because Notion lacks real version control and portability. I wanted the durable substrate under the work.
The reframe I keep coming back to: treat your business knowledge the way developers treat code. Version-controlled, modular, improved a little at a time. That’s what compounds. Marketing problems are usually infrastructure problems wearing a costume.
When Fable 5 showed up, I didn’t rebuild any of that. I handed it the same repo and asked where it was weak.
What happens to my work if the AI app I use shuts down tomorrow?
If your work lives inside an app, it leaves when the app does. If it lives as files you own, it stays. That is the whole answer, and it is the one I keep coming back to.
I made the full case for this at the leadership level in AI Vendor Risk Is a CAIO Decision, Not an IT Ticket. The short version: a remote model your operation runs on is a single point of failure, and the fix is to own your knowledge as portable files instead of renting it inside someone’s product. That piece carries the continuity argument. I am not going to re-run it here.
What I will add is the founder-scale move that makes it real. Get onto the terminal. When you work with something like Claude Code or Codex, your work saves to your desk as actual files, not rows in a vendor’s database. Most of my clients are not developers and it still matters, because the day a newer model ships they point it at the same files and keep moving. No migration. The work is already sitting there.
Can I trust one AI to check its own work?
No. A model grading its own homework is structurally biased toward its own answers, so the check has to come from a different model family. In the MT-Bench study on using models as judges, GPT-4 rated its own answers about 10 percent higher, and Claude-v1 rated its own about 25 percent higher. The researchers called the numbers preliminary. The direction is the point, and it matches what I see every day.
This is the part of the week with the frontier model that taught me the most. I didn’t just ask it to grade my systems. I ran it next to the models I already use and watched them disagree about my own business. Six tools reading the same source material, coming back with different calls on it. That spread is not noise. It is the signal. The moment you have more than one strong model in the room, you can see which parts of an answer are solid and which parts were one model’s habit talking.
Here is why that happens. Each model is a different school of thought. They are built differently from the ground up, so they research, analyze, write code, and write prose differently. Point several of them at the same material and each one catches something the others miss. If you want something reviewed well, you want the review coming from a genuinely different mind than the one that made it.
It’s the same reason students don’t grade their own papers. They wrote it, so they can’t see the holes. So why have a Claude agent write the code and then a second Claude agent review that same code? You can dress the second one up with a different persona and squeeze out a little more, but you are still inside one school of thought, hitting the same blind spots. A different persona is not a different mind.
My version grew up over time. Early on it was one model doing most of the QA. Then I added a second, usually Gemini, running its own pass, so I had two reviewers standing in different places. What I run now is a three-model council. And I don’t just point it at the code. I point it at the plan.
Before we build anything, the council reviews the PRD and the roadmap. What are we building, why, and how. Then I run that same council against the task breakdown, the full list of what the project is supposed to do, and ask whether it’s actually right. Get the source document tight and the final output comes out right. Most of the quality lives upstream, in the document everything else is built from. That is where the review should start, not at the end when a mistake is expensive to pull out.
The rule underneath all of it is simple. Never let the model that made something be the only one that approves it. Different families, checking each other, on the plan before the build. That one discipline has done more for what my teams ship than almost anything else I’ve tried.
Is my AI memory trapped inside one tool, and can I take it with me?
If your memory lives inside ChatGPT or Claude, you can’t take it with you, and that’s by design. Keep it in plain files any model can read and it becomes infrastructure you own.
There’s a story the market tells about AI memory right now. Memory is the moat. It’s the thing that keeps your customers from leaving, because their history is trapped inside your product. That framing is aimed at people building apps, and it’s about locking users in.
Flip it. Portable memory is how you avoid being the one who’s locked in. The same feature that walls a customer inside a product will wall you inside a tool. So don’t wait for ChatGPT or Claude to hand you memory portability. Keep your memory in files any model can read, and you already have it. Same own-your-ground instinct as the files argument above, pointed here at the one asset most founders never think to move.
Here’s what that looks like for me. My business brain is a segmented store, split by client and by project, so multiple agents and sessions read from it and write to it without stepping on each other. This quarter’s moving pieces live in a working folder, separate from the stable reference like philosophy and offers, so temporary state never pollutes what’s always true. And because it is memory a council can read, every model in the review gets the same picture of the business, not one tool’s private copy of it.
Get that part right and everything downstream gets fast. Spinning up a chatbot. Pulling the right material to write a piece of content. Feeding a design job. Onboarding a client. All of it moves quickly, because the model is plugging into a brain you built.
How do I avoid AI vendor lock-in as a small company, without an enterprise budget?
Make multi-model a discipline you practice. You don’t need an AI gateway. You need a rule: never marry one provider, and never let the model that made something also approve it. Provider flexibility is power, and it is cheap, because you are using tools you already have.
When a big company asks this, the answer turns into a procurement project. Abstraction layers, gateways, contract clauses, migration-effort percentages. A founder running a 5 to 50 person shop has no team for any of that and does not need one. Owning your knowledge as portable files handles the continuity half of the problem. This is the other half: not leaning on any one model’s judgment either.
I run across 70-plus models from different providers, OpenAI, Anthropic, Google, xAI, DeepSeek, through OpenRouter. Not to collect them. To match the model to the task and to keep myself from depending on any single company. Expensive, powerful models for hard debugging and architecture. Cheaper, faster ones for iteration and interface work. I don’t marry a model. I route.
Part of this started practical. I didn’t want to burn all my Claude tokens on review, so Gemini and Codex run in the terminal alongside Claude and share the load. The bigger payoff was independence. When the frontier model showed up for its week, adding it to the rotation was a config line, because nothing in my setup is built around one provider. That is the whole point of routing instead of marrying: a new model is something you plug in, and a failing one is something you swap out, and neither is a crisis.
How do I build an AI system that survives a model update, or the vendor disappearing?
Stop building around a model and build a system the model plugs into. Four pieces make it durable: a memory any model can read, multi-model review, files you own, and the habit of adopting the next model in an afternoon instead of rebuilding. Together they’re one operating system. The model is a part you can replace. The system is what you keep.
This is where the four answers above become one thing.
A portable memory means your business brain stops being stranded in someone’s product, and it means every model in the room reads from the same picture. Multi-model review keeps any single vendor, or any single model, from becoming a point of failure in your quality. Files you own mean the work outlives the tool, which is the continuity case I make in full at AI Vendor Risk Is a CAIO Decision, Not an IT Ticket. And because all of it lives as files, adopting a new frontier model is fast. You point it at the system and it’s better today.
I stopped thinking about AI as autocomplete a while ago and started treating it as a workforce. Two teams built like real teams, a dev team and a marketing team, each modeled on roles I used to manage with people. The content side runs on staged gates, version control, and scoring, with my judgment at the points that matter. It’s not a content calendar. It’s a content operating system. The real product is the methodology.
The models will keep changing. A new frontier model will land, get its short window, and go back on the shelf, and another will take its place a few months later. What you keep is the system underneath.
That’s what I have the next powerful model look at when it shows up for a week.