I built an operating system for my AI, then deleted most of it

Every piece of AI configuration I built solved a real problem on the day I built it. That is exactly how the mess started.

An instinct loop so corrections survived between sessions. A voice profile so drafts sounded like me. A persona file so the assistant knew which of my four roles it was helping with. Each one earned its place. None of them knew the others existed, and after four months I had a folder of clever, disconnected files and no idea which of them were still true.

This is what happened next, in both directions: the structure that pulled them together, and the deletion pass a few months later that removed most of the weight.

Part one: the shape

The fix was not more configuration. It was admitting that a collection of files with no relationships between them is not a system, and giving it one.

Five folders, each answering a different question:

identity/     who I am, how I work, how I write
knowledge/    what is true about the estate, and when it was last checked
skills/       procedures the assistant can invoke by name
hooks/        what fires automatically, and when
rituals/      the recurring loops: Monday planning, Friday audit

The split is not arbitrary. Each folder has a different lifetime and a different failure mode. Identity changes slowly and quietly. Knowledge goes stale without telling you. Skills get added and forgotten. Hooks fire whether or not you remember writing them. Rituals only work if they run.

Two things made it a system rather than a tidier folder.

Version control. Everything in one repository with one history. Not for the diffs, though those help. For the audit: when the assistant does something surprising, the question “what changed” has an answer, and the answer is a commit rather than a memory.

The global config file became a router. The one I had written a whole post about, the carefully-tuned instruction set, ended up as a short file that mostly points at other files. That felt like a downgrade at the time. It was the first sign of what part two would confirm.

The payoff was not that the assistant got smarter. It was that I could answer questions about it. What does it know about our estate? Which of those facts were written six months ago? What fires on session start? Before the structure, those questions had no address.

The part nobody builds

Then the knowledge folder started rotting, which is the failure mode nobody warns you about because it is invisible.

A note that is wrong does not throw an error. It gets read, believed, and acted on. And notes about a live estate go wrong constantly: a migration finishes, a service moves, a workaround stops being necessary. The note stays exactly as confident as the day it was written.

So the system needed maintenance it could perform on itself. A linter, run nightly:

• Regenerate the indexes, so navigation never drifts from the files
• Rank every note by recency and confidence, so the assistant reads the freshest thing first
• Report notes untouched for ninety days as decay candidates
• Report broken links between notes

None of that is clever. All of it is the difference between a knowledge base and a pile of markdown, and it is the piece most people skip because it produces nothing on the day you build it.

A note that was true in May and wrong in August is not memory. It is a bug with good formatting.

Part two: the diet

In July, Anthropic published new rules of context engineering for the Claude 5 generation. The short version: these models need far less instruction than we have been giving them, and most configuration is dead weight. Their advice leans radical, close to delete everything and start clean.

I did not delete everything. But I read it while sitting on months of accumulated configuration, and the honest reaction was that they were probably right about most of mine.

Two passes.

Pass one, automated. Claude Code ships a /doctor command that audits the setup. Mine found five plugins, two integrations, and five skills that had never been used, and disabled them. No judgment required: the usage numbers decided. This is the pass worth stealing, and worth repeating on a schedule, because configuration rots quietly and nothing prompts you to look.

Pass two, deliberate. An audit of what the system believed. This was the uncomfortable one.

Parts of the memory were stale in the specific way the linter was built to catch and I had not been reading its reports. Notes describing finished work as in progress. Nothing had forgotten anything, which is worse than forgetting. The system remembered a world that no longer existed and was ready to act on it.

The probe that decided every deletion

The interesting problem is not what to delete. It is how to know.

Every instruction in your configuration is a bet that the model would get it wrong without you. Most of those bets were placed against an older model, and nobody revisits them. So test the bet directly.

Take one instruction and turn it into the question it answers. “Always do X in situation Y” becomes “what would you do in situation Y?” Then ask that question somewhere your configuration cannot leak in:

claude --bare -p "your question here"

--bare loads no config, no memory, no project files. If your setup only allows interactive login, a scratch config directory from an empty folder does the same thing:

export CLAUDE_CONFIG_DIR=$(mktemp -d) && cd $(mktemp -d) && claude

Log in once, then ask.

Compare the answer to your instruction. If they match, delete the instruction. You are paying context for knowledge the model was born with. If the answer is confidently wrong, keep it forever. That is the instruction earning its place.

I ran it on a two-part question: an internal convention that only exists in our organization, and a piece of public tooling behaviour. The empty session answered the public half correctly without being told, so that note was dead weight. On the internal convention it said “I do not know”, which is exactly right, and exactly what configuration is for.

The failure mode to watch for is the third case: confidently wrong. Those are the expensive ones, because a model that is unsure will hedge and a model that is wrong will not.

What it cost, and what survived

Long-term memory compressed by 82 percent. Agent instructions from around 1,500 lines to under 500. Twelve plugins, integrations and skills disabled.

Anthropic is right that these models need far less instruction than we give them. What survived the cut is the part that proves the rule rather than breaking it: organizational facts a fresh model cannot rediscover, trust boundaries where being wrong is expensive, and the specific scars from things that went badly once. None of that is in any training set.

The honest cost: this only works if you keep doing it. A deletion pass is not a state you reach, it is a habit, and mine currently runs when I happen to read Anthropic’s blog. The linter reports decay candidates nightly and nothing forces me to act on them, which is the same gap in a different place.