Stop Building AI Memory. Build an AI Memory Layer Instead.

Over the past few weeks, I have been moving between frontier AI systems more than usual: ChatGPT, Claude, Codex, Kimi, Gemini, and whatever new tool the timeline decides is inevitable by lunch.

At first I asked the same question everyone asks when they start living across multiple assistants: which AI has the best memory? It feels like the obvious question. One product remembers preferences. Another has projects. Another reads repository instructions. Another can swallow a giant context window and make you feel, for one brief moment, that forgetting has been solved.

But the more I used them, the more the question started to feel wrong. Not just incomplete. Wrong in direction.

The better question is: why should my memory belong to any AI provider at all?

Every serious AI platform is converging on the same idea: persistent context. Both ChatGPT and Claude combine Memory with Projects. Codex uses repository instructions like AGENTS.md. Cursor and Windsurf use project rules and workspace context. Kimi is investing heavily in long-context reasoning, while Gemini blends memory with its broader ecosystem. Different implementations, same destination: helping users avoid repeating themselves.

Individually, each of these systems is useful. The problem appears when you use more than one.

You explain who you are in one place. Then again in another. You describe what you are building. You repeat your coding preferences. You restate your product philosophy. You paste the same background into a new project. You remind the next assistant of decisions the previous assistant helped you make.

After a while, you realize you are not using AI memory. You are maintaining six half-memories, each locked inside a different product.

The issue is not that provider memory is bad. Some of it is genuinely good. The issue is ownership.

If my context lives inside one provider, switching becomes expensive. If I pause a subscription, change tools, move from a writing assistant to a coding agent, or decide a new model is better for a task, my memory does not come with me cleanly. I can export pieces. I can copy instructions. I can rebuild. But the center of gravity is still inside someone else's product.

That is backwards. My context is not a model feature. It is infrastructure. It should be portable, inspectable, versioned, and mine.

The model should be replaceable. The memory should not be.

I have stopped thinking about AI memory as something each assistant needs to own. I now think about it as a layer underneath all assistants.

Instead of asking, "Which AI remembers me best?" the better operating question is: how can every AI remember me equally well?

That means separating memory from the model. The assistant becomes the execution layer. The repository becomes the memory layer. ChatGPT can reason against it. Codex can edit inside it. Claude can write from it. Kimi can explore visually with it. Gemini can summarize or research from it.

Same memory. Different engines.

The simplest version is a Git repository. Not a database. Not a SaaS subscription. Not a secret second brain with a custom UI you will stop maintaining in three months. A boring repository full of Markdown files.

Mine is called ai-os, because that is how it feels: a small personal operating system for AI. It is not trying to be clever. It is trying to be durable.

The folders are deliberately plain:

The memory/ folder holds durable context: who I am, what I care about, how I like to communicate, my product taste, my design taste, my coding standards, my current focus.

This is different from saving every conversation. Most conversations are not memory. They are work. They contain half-formed thoughts, temporary constraints, bad guesses, and context that expires quickly. If you store all of it, you do not get memory. You get sediment.

A good memory layer should be edited. It should be opinionated. It should contain the facts and preferences future assistants actually need. The point is not to remember everything. The point is to remember the things that prevent you from explaining yourself again.

The skills/ folder holds reusable modes of work. Principal Product Manager. Startup Founder. Senior Software Engineer. UI/UX Designer. Technical Writer. Research Analyst. Data Analyst. Career Coach.

This matters because most prompting is really role setup. Before the real task begins, you spend tokens explaining how the assistant should think. What quality bar to use. What workflow to follow. What output format is helpful. What mistakes to avoid.

A skill turns that setup into a reusable artifact. Any model can load it. The skill is not trapped in a Claude project or a ChatGPT custom instruction. It is just a Markdown file in a repository. Portable, editable, reviewable.

The projects/ folder is where the system starts feeling less like note-taking and more like an operating system. Each project has its own vision, roadmap, architecture, requirements, tasks, research, notes, competitors, designs, changelog, and decisions.

That means switching context becomes a folder change, not a re-onboarding ceremony. The assistant reads the project before acting. It sees what has already been decided. It knows the current direction. It does not need to reconstruct the project from scattered chat history.

This is especially important for coding agents. The difference between an agent that reads a project workspace and one that only sees the current prompt is the difference between a collaborator and a very fast intern with amnesia.

The most valuable folder might be decisions/.

Every important product or architecture choice should leave a trace: context, alternatives considered, rationale, trade-offs, consequences, owner, and date. Not because documentation is virtuous. Because future work depends on knowing why the current shape exists.

Months later, an assistant can answer a better question than "what does this code do?" It can answer "why is it this way?" That is where memory becomes leverage. A system that remembers outcomes but not reasoning still forces you to relitigate the past.

This is the part that changed my relationship with model choice. I have stopped looking for one best AI.

ChatGPT is useful for product strategy, brainstorming, UX thinking, image generation, and broad research. Codex is strong for repository-wide software work, architecture, and implementation. Claude is still excellent for long-form writing, code review, system design, and documentation. Kimi is interesting for creative visual exploration, modern landing pages, and large-context reasoning. Gemini has its own strengths in research and ecosystem workflows.

The point is not that one of them wins forever. The point is that the same memory layer can support all of them.

When memory is portable, model choice becomes tactical instead of existential.

Today's best model will not be tomorrow's best model. That is not a prediction anymore. It is the operating condition of the field.

If all of your context lives inside one provider's memory feature, every model switch has a hidden migration cost. You do not feel it on day one. You feel it when you have to rebuild your preferences, restate your projects, recover old decisions, and teach a new assistant the same working style from scratch.

If your knowledge lives in a portable repository, changing models becomes almost boring. Point the assistant at the repo. Load the relevant memory, skill, and project. Work continues.

That is the future I want: not one assistant that remembers everything, but an AI operating system that any assistant can boot into.

I do not think personal AI systems will be defined by the model alone. Models will matter, obviously. But the durable advantage will be the layer beneath them: portable memory, reusable skills, version-controlled knowledge, project-aware context, and decisions that survive the conversation that produced them.

The best AI may change every year.

Your knowledge should not have to.