The Model Should Be Replaceable
The worker should be replaceable. The knowledge shouldn't be.
I was solving the wrong problem
This week I found myself doing something slightly ridiculous. I was trying to figure out how to keep working after the AI I was using hit its limit. Then another one hit its limit.
So naturally, I started looking at separate accounts, different machines, local folders, alternate models, remote workers, and increasingly creative ways to keep the assembly line moving. At some point I realized I had stopped solving the thing I was building and started solving access to the thing helping me build it. That seemed backwards. And it exposed a much bigger problem.
If your entire system stops working because one AI tool becomes unavailable, you don't really have a system. You rented a brain.
How much of the operation lives inside the relationship
I've been guilty of this. Over the last year, AI went from something I occasionally used to something sitting in the middle of nearly everything I build — strategy, research, code, writing, operations, prospecting, documentation, planning. Some days it feels less like software and more like having several extremely capable employees sitting next to me.
Which is incredible. Until one of them goes home. Or hits a usage limit. Or changes pricing. Or gets worse at something it used to be great at. Or argues with me about what time it is — apparently we've reached that stage of the relationship. Or I decide a different model is better for the job.
Then you discover how much of your operation was quietly living inside that relationship. That's the dangerous part.
More capacity doesn't fix the architecture
I originally thought the answer was simple: get more access. Another account. Another model. More usage. More capacity. And sometimes that is the answer — if you're doing real work with these systems every day, you need enough horsepower.
But more capacity doesn't fix the underlying architecture. It just delays the problem. Because the important question isn't which AI should do the work? It's what survives when that AI is gone?
What should survive
That question changed how I've started thinking about the systems I'm building. The code should survive. The decisions should survive. The customer history should survive. The research, the task list, the reasoning behind major decisions, the current state of the project — all of it should survive. The AI shouldn't be the place where those things live. It should be able to walk into them.
Think about a normal company. If your best employee quits, that's painful. But the company doesn't forget what it sells. The CRM still exists. The files still exist. The processes, the customers, the operating history still exist. A new person can sit down, learn the environment, and continue the work. Sometimes badly. Sometimes slowly. But the company itself survives the employee.
That's what I want from an AI system. The worker should be replaceable. The knowledge shouldn't be.
The business should know the business
This became very real for me while working across Claude, Codex, and MacK Jr., my OpenClaw Chief of Staff. At first I was thinking about them almost like individual systems. Claude knows this. Codex knows that. MacK Jr. needs access to this folder. This account has the context. That instance built the feature.
Then I realized that was exactly the wrong mental model. Claude shouldn't be where the business knows the business. The business should know the business. Claude should be able to read it. Codex should be able to read it. MacK Jr. should be able to read it. Whatever comes next should be able to read it. That's a completely different architecture.
The second worker inherited the work
One little discovery made this obvious. I realized I could have a different coding instance work against the same local project folder. Nothing magical happened. The second worker didn't inherit the first worker's brain. It inherited the work. The files were there. The code was there. The documentation was there — or is supposed to be there. The current state was there.
That sounds stupidly obvious once you say it out loud. But I think we're going to see a lot of companies make the opposite mistake over the next few years. They're going to build around whichever AI vendor they picked first. Their prompts will live there. Their context will live there. Their workflows and their history will live there. Their institutional knowledge will slowly become dependent on a tool they don't control. That makes me nervous.
The point is portability
This is also why I've become increasingly obsessive about what I call the Intelligence Estate. Not because I want a beautifully organized pile of notes. I couldn't care less about prettier folders. The point is portability.
The Estate is where the company remembers. Projects. Decisions. Research. Customers. Lessons. Failures. Ideas. Plans. The stuff that makes tomorrow smarter than yesterday.
Once that exists outside the model, something interesting happens. You stop caring quite as much about which model is currently the smartest. You can use the best worker for the job. One may be better at coding. Another may be better at research. Another may be cheaper, or faster, or may not even exist yet. Fine. Let them compete. The Estate stays.
Important work has to leave the conversation
There's a practical consequence to this that I'm trying to enforce in everything I build now: important work has to leave the conversation. If an AI helps me make an important architectural decision, that decision can't remain buried 700 messages deep in a chat. If we discover something about a customer, it has to make its way into the customer record. If a coding agent changes how part of the system works, that needs to show up in documentation. If I have an idea worth keeping, it has to land somewhere durable. If we learn something painful, the next worker shouldn't have to learn it painfully again.
This sounds like documentation. It isn't. Documentation tells you what exists. Memory tells you why.
Build the durable thing around the unstable thing
There's another reason this matters. Models are getting better incredibly quickly, which means today's favorite probably won't be tomorrow's favorite. I don't know which model I'll be using most a year from now. I don't think anyone does.
But I'll still care about the decisions I made this week. I'll still care about customer history, the architecture, what worked, what failed, and why. So I'm trying to build the durable thing around the unstable thing. That's the part I control.
The better question
A lot of people are asking the wrong question right now. They ask: which AI should we standardize on? I think the better question is: what would happen if we changed it tomorrow? If the answer is chaos, you have some work to do.
Because the model is not your institutional memory. It's a worker. An extraordinarily capable worker — maybe the best one you've ever had. But still a worker. And workers change.
This started with me trying to get around usage limits. It ended with a much more useful realization. I don't want to build a company that depends on one AI remembering everything. I want to build a company that any capable AI can walk into and understand.
The smartest worker in the room should never be the place the company keeps its memory.
If this idea resonates, read Every Conversation Starts Over next.