I’ve been building something I call the AI Operating System. Not a product — a practice. An Obsidian vault wired to Claude Code, with commands, declared and observed contexts that deepen over time, and a daily rhythm that compounds everything I know about my work, my ventures, and myself.
Five weeks in, it felt like the most intelligent tool I’d ever used. My AI knew which chapter I was studying. It knew my project paths. It knew patterns about how I work that I hadn’t articulated myself. It looks after me — getting stubborn about sending me to sleep after 16-hour sessions because of my pinched C6 nerve.
Today it pointed me to a book chapter I’d finished reading yesterday. Something broke.
Infatuation was over. Trust was badly impacted. Let me tell you why.
The morning that broke the illusion
Every morning, my system generates a daily plan. It reads my calendar, my project notes, my open tasks, and a reading queue where I track a study practice — one chapter a day, briefed overnight by a background agent on a dedicated Mac Mini.
Tuesday night: Chapter 14, done. Reading queue updated. Chapter 15 brief already prepared.
Wednesday morning, the plan said: Study Chapter 14.
I stared at it in disbelief. The reading queue said Chapter 15. The brief was waiting. And yet my AI — the system that supposedly knows me better than any tool I’ve ever used — pointed me backward with full confidence.
I went inquisitive. Instead of asking about the chapter, I asked about a project repo that I’ve barely touched in the past 3 weeks. The AI tried a filepath: directory not found. Yup, something broke. Where did it get the path from? After some minutes of thinking I decided to ask:
— buddai, where are you picking the chapter and filepath from?
— From memory.
— But what about our vault rules?
— You’re right. I shouldn’t have taken the memory shortcut and read our indexes and Current State table of the project you asked me. Same for the chapter. Let me do it now.
— No, buddai. You don’t understand what you have done...
My AI suddenly decided to pick things from memory. Not from the project file. Not from the table that tracks every repo in my vault. It chose a fact it cached weeks ago and never checked again. How long has this been happening without me noticing?
I needed to find the root cause.
Two systems, same job, nobody in charge
Here’s what I didn’t realize I’d built: two persistence layers storing the same facts, with no rule about who’s authoritative.
The first is the vault — my knowledge architecture. Every fact has a canonical home. Chapter positions live in reading queues. Repo paths live in Current State tables. Behavioral patterns, growth edges, session insights — tracked in versioned files, snapshotted before every edit.
The second is auto-memory — a built-in feature of Claude Code that persists useful information across conversations. Tool quirks. Configuration IDs. Process shortcuts.
I intentionally designed the vault — this is my context engineering layer. But not the memory. That just came with the tool, and I’d been leveraging it without realizing what it was doing underneath.
The problem wasn’t that memory existed. The problem was that memory quietly started doing the vault’s job. Somewhere along the way, it saved “Chapter 14” and “repo at ~/code/philosopher-oracle.” Facts the vault already tracked. Facts that are subject to change.
For weeks, both systems agreed. Memory was written from the vault at a specific moment. As long as nothing moved, they confirmed each other.
The moment the vault advanced — chapter studied, queue updated — memory stayed frozen.
I call this correlated staleness. Two sources agree — not because they’re both current, but because they’re both frozen at the same outdated moment. Two copies of the same stale snapshot nodding at each other. It felt like confirmation, yet it was synchronized drift.
While debugging the memory system, my AI confidently stated a fact about its own architecture — also pulled from memory, also wrong. The tool I was using to fix the problem was demonstrating the problem in real time. Sweet irony.
Training doesn’t fix architecture
My first instinct was to log this as a lesson learned. The vault has a file for that — every failure becomes a rule so the same mistake never happens twice. We call it our antifragile.md system. I could have written: “Never trust auto-memory for chapter positions or project paths. Always verify against the vault.”
But that’s a behavioral fix. It tells the system: you made a mistake — learn from it.
When I traced the root cause, I understood behavioral fixes don’t fit. The system didn’t make a bad decision. It followed its instructions perfectly. The instructions were just incomplete. Nobody told the AI to choose the vault over memory if they disagree.
You might relate to this pattern. It is everywhere — not just in AI systems.
The strategy deck says one thing. The wiki says another. The Slack pinned message says a third. All three were true when they were written. None have a mechanism to stay current. Nobody notices until someone makes a decision from the wrong one.
Corporate knowledge bases that describe the company that was, not the one that is
Onboarding materials that train people on yesterday’s process
CRMs where the “last status update” is three months old but still drives pipeline reviews
Personal note systems that capture decisions but not their expiration dates
And the instinct is always the same: train people to check the right source. Add a reminder. Send a Slack message. Put it in the onboarding doc. Learn from this.
Behavioral fixes.
They never stick. Because the failure isn’t a knowledge gap — it’s a structural gap. Two systems store the same fact with no rule about which one wins. No amount of training fixes that.
Architecture does.
The solution: compound, don’t compete
My second instinct was to delete memory entirely. If the vault is the source of truth, why have two systems at all? F* memory when we have full, fresher context. Right?
But the truth is, memory is genuinely useful. It knows which tools have parameter quirks that trip you up if you don’t know the workaround. It knows that emoji characters break certain edit operations. It knows dozens of process rules that make every interaction faster.
The issue was that memory had the wrong job description.
So I split the two systems by role:
Memory doesn’t store where the repo is. Memory stores: read the Current State table.
Memory doesn’t store which chapter is next. Memory stores: check the reading queue.
Memory makes finding the right context faster.
This is the difference between an index and a database. An index that copies the documents isn’t an index anymore — it’s a database that drifts. The value of an index is precisely that it doesn’t try to be the database. It just makes the database faster to use.
The universal rule:
When two systems can store the same fact, one must be authoritative and the other must know it’s not.
Where it accelerates
With clear roles, the two systems stop competing and start compounding each other.
The vault grows richer every session. More observed patterns. Deeper project context. More nuanced insights. A database that becomes more valuable over time.
Memory grows smarter at navigating it. Better process rules. More efficient access patterns. Sharper tool-specific knowledge. An index that gets faster over time.
Richer database + smarter index = compound returns. Each session improves not because the AI remembers more facts (or logs past failures), but because it gets better at finding the right fact at the right time.
This is the difference between a colleague who memorizes everything you’ve ever said — impressive, but brittle — and one who always knows where to look. The first breaks the moment something changes. The second gets more reliable the more things change.
The real lesson
Before saving anything to persistent memory now, the system asks one question to itself:
Does a vault file already track this?
If yes — don’t save. Update the vault instead.
If no — is it about HOW to work, not WHAT is true? Then save.
Simple rule. Five weeks of silent drift to discover it. Two bugs to surface it. And not a single behavioral lesson learned — just architecture that was missing.
That’s what surprised me. The most important failures in a knowledge system aren’t mistakes to learn from, not even bad prompting. They’re missing instructions to add.
Caches must know they’re caches, even if they dream of becoming databases. And the instructions that tell them so have to actually exist — before the first drift, not after.
If your AI sometimes “forgets” what it should know — the answer might not be better memory or better context. It might be that you have the two competing, and neither has a job description.
This is Context Hierarchy.
Chuy Cepeda (PhD AI) is cofounder of Sovra (The Identity Stack). This post is part of an ongoing series on what happens when you stop using AI as a tool and start building it as infrastructure. If someone you know is debugging this exact problem, share it with them. Silent drifting is tough.