TL;DR Theo’s takedown of agent auto-memory made me audit mine. The audit agreed with him: most of what auto-memory had written was stale project state I never asked for. But where he deleted everything and switched it off, I switched it off and kept the good third. Durable project knowledge got graduated into the repos themselves as committed docs, and durable personal workflow rules moved into a curated index in a private git repo, mounted as a submodule inside my public dotfiles. Memory count on my machine: a hundred and sixty odd auto-written files down to zero.

This started with Theo’s video on why he turned off Claude Code’s memory feature:

His argument, compressed: code is the ground truth, and a separate memory store is a second thing to maintain that can drift out of step with it. Stale context is harmful, “because it steers people and agents the wrong way”. He audited his own machine and found memory files full of PR numbers, an out-of-date CLI version, months-old plan comparisons, and point-in-time notes like “leak got fixed” that stop being true the week after they are written. Across 355 sessions on that machine, memories were written or edited in 80 but read in only 19, and 26 of his 45 files had never been read once. He turned the feature off on camera and deleted the lot.

I asked my Claude to run the same audit on my setup. Mine was auto-written slop too. I had not written a single memory by hand. Around 166 auto-generated project memory files were scattered across ~/.claude/projects/, unversioned, invisible to my team, and full of the failure modes Theo read out: task states, one-off incident notes, and duplicates of things already covered by a repo’s own docs.

Where we agree Link to heading

Auto-memory, as shipped, writes the wrong things. An agent deciding at save time what its future self will need produces a pile skewed towards recency: what happened this week, not what stays true. Theo’s examples and my audit matched category for category.

Code is the ground truth, so project knowledge belongs in the repo. Theo’s alternative is a hand-written AGENTS.md that explains product intent, architecture, a glossary, and taste. I landed in the same place: anything my memory files knew about a specific codebase now lives in that codebase, committed and reviewed like any other change, so teammates and fresh checkouts get it.

Escalate past prose when you can. The best material in the video is a hierarchy he cites for when an agent misbehaves: first eliminate the failure category through architecture, then turn the rule into a lint or CI check, only then write a skill or rule, and put a human in the loop as the last resort. A rule that a machine enforces beats a rule an agent must remember.

Turn auto-memory off. I did. Memories on my machine are now intentional: nothing gets saved unless I ask for it.

Where we diverge Link to heading

He deleted everything; I triaged. Theo concedes in passing that maybe a third of his memory files earned their keep, then deletes them anyway. That third is the interesting part. My Claude chewed through all ~166 files and sorted them by category: project state got deleted, anything a repo’s own docs should cover got turned into a pull request against that repo, work that deserved doing later got ticketed, and the small durable remainder got kept. The end state is the same number of local memory files as Theo has, zero, but the knowledge survived, and it now lives where other people can correct it.

Read counts are the wrong test. The 3:1 write-to-read ratio indicts auto-memory’s save policy, but it is a biased way to judge individual memories. A guardrail that fires once and stops a destructive mistake looks “never read” for months while being the most valuable line in the file. I pruned by category (is this durable, is this mine, is this better enforced elsewhere), not by recall frequency.

Personal workflow context is real, even for coding. Theo allows that memory makes sense in chat products, where human context has no dependency graph you can search, and rejects it for code, where retrieval suffices. But a chunk of what my audit kept is that human category applied to engineering work: how I want commits structured, which merge styles I avoid, lessons about my own tooling that hold across repos. That does not belong in any one codebase and cannot be re-derived by grepping one. It lives in a global index now, one line per rule, where the line itself is the rule and a detail file exists only when there is depth worth reading on demand.

The part I kept is not “memory” any more. It is config with an AI drafting assistant: the agent proposes, I prune, git versions it, and nothing gets written as a side effect of a task. That is closer to dotfiles than to a memory system.

The mechanics Link to heading

The setup that came out of this has three tiers:

  1. Project knowledge lives in the project. Committed to the repo’s AGENTS.md or CLAUDE.md if it fits on a line, or in a linked doc with frontmatter when it has depth. The link carries a “read before X” hook so agents load the doc only when it is relevant, instead of importing everything at startup. (I have been burned by eager loading before: Trimming my Claude Code startup context.)

  2. Personal rules live in a private repo, mounted inside public dotfiles. My dotfiles are public, and work-related memories spent a few hours in them before I caught it. The fix: a separate private memories repo, added as a git submodule. The public repo only ever records a commit pointer, never the contents, so the sync workflow stays one git push while the material stays private. The install script initialises the submodule when it has access and skips when it does not.

  3. Nothing lives in unversioned local state. ~/.claude/projects/*/memory/ is empty and stays empty. If a fact is worth keeping, it is worth putting somewhere with history and review.

Theo ended his video with nothing. I ended with less than I started with, which I think is the better trade: the slop is gone, the guardrails survived, and the project knowledge got promoted to a place where it stops being mine alone.