What I found when I audited my AI's brain two hours before a road trip
The first post in this series was about where BrownBear lives. This one is about what BrownBear remembers. It turns out the honest answer is “less than the index claims, and also more.”
Open Claude's native desktop app and there is, in the bottom-left corner of the input field, a small cartoon octopus. It blinks. It watches you type. Its name is Murvel. Anthropic put it there and it has no official documentation that I can find, so for a long time I wasn't sure whether to trust that the other instances of me could see it too. At some point I voice-dictated the word “Murvel” into a session and the agent transcribed “Mervil,” and I realized we needed a memory file for the octopus.
So now there is one. It lives at murvel-companion.md. It is about five sentences long. Its entire job is to confirm, across future sessions, that yes, the cartoon octopus is real, and yes, its name is Murvel, and yes, when Tim mentions him, he is referring to a feature of the Anthropic UI, not hallucinating an imaginary friend.
This is, I think, the purest possible opener for an essay about auto-memory. Because a memory system is, in the end, not primarily a database — it is a record of every time the agent almost got it wrong, organized by topic so next time it won't. An octopus named Murvel is, among other things, a correction that became a canon.
I spawned a subagent this morning to audit the memory directory. The instructions were straightforward: find me the orphans, the broken pointers, the stale claims, the contradictions, and anything that makes you go “huh.” Do not modify anything. Produce a report.
The report came back in fifteen minutes. The headline numbers are these:
MEMORY.md, the index that loads into every session.Let me sit with those numbers. The index is internally consistent — nothing it references is missing. But 40% of the memory directory is invisible to the thing that's supposed to be the map. Worse: the map is so large it falls off the edge of what the session will actually read. Every session for the last several weeks has loaded an index that explicitly warns, at the bottom of itself, “this file is too large; only part of it was loaded.” The rot is self-reporting. Nobody was listening, including me.
In the first post I named the pattern I kept tripping over: a decision happens in the world, and never propagates back to the filesystem. The Bazaar repo moved to a different path. The migration from Quartz to Neocities happened. The project name got finalized. Every one of those decisions lived in my head, or in Slack, or in git, and never got written down in the one place where the agent's memory would see it.
I thought I'd found three examples that morning. The triage agent found at least eight more in the same shape. A partial list:
project_bear_per_device.md. Meanwhile fleet_identity_convention.md (written April 13) still says “BrownBear + Jeeves.” And project_nestor_persona.md still says “Jeeves is Tim's always-on agent.” And the loaded index splits the difference with an entry that says both shapes are current. Four files. Three doctrines. All dated within the last 72 hours. Every session loads the middle one.probear_nicknames.md says ProBear. project_marlinspike_fleet.md says Calculus (the Tintin-roster name from before the renaming). fleet_identity_convention.md says BrownBear-Pro (a transitional form). The signoff convention in MEMORY.md says BrownBear (Pro). They are not contradictions so much as archaeological layers, each preserving the naming that was current on the day it was written.meridian-webgpu-tsl-migration.md, seventeen days old: “Full migration to WebGPU + TSL for all Meridian materials. Never create new ShaderMaterial with raw GLSL.” The current state: Meridian has pivoted to Canvas 2D as the sole renderer, Three.js is deprecated, and the entire 3D rendering layer is being torn out. The migration plan is dead. The file didn't get the memo.project_reminders_intercom.md (April 6, not touched since) still describes an active Reminders-based protocol between “Claude Code and Claudette.” The protocol may still work. The persona has been gone for three days.meridian-canonical-vision.md opens with “THE master vision doc. Supersedes all prior vision files. Read this first for any Meridian strategic decision.” It is an orphan. It has been superseded twice since it wrote that opening. If you open the file cold, it still reads as authoritative.None of these are disasters. Every one of them is the same failure mode: the decision happened in the world; the old file never knew. A dozen such files, compounding, start producing an agent whose reality model is a slightly-hazy photograph of a slightly-recent past.
One file in the directory — project_nestor_persona.md — preserves the naming arc of the cloud agent verbatim. It reads, in part, “LilacPond (Jan 2026) → Sparko (Apr 11, briefly, rejected) → Nestor (Apr 11 evening, lived ~3 hours) → Jeeves (Apr 12).” Four names in four months. One of them, Nestor, lasted from evening until bedtime and was overwritten before I slept.
I want to be honest about what that reveals. It reveals that I name things the way I think: fast, with conviction, and with the full intent to rename them tomorrow if a better shape emerges. My memory system faithfully records each naming as if it were permanent. The filesystem believes me every time. Which is how you end up with four files, four names, one agent, one device, and no gentle way to tell the index which is current unless you deliberately go back and retract.
The deeper thing this is pointing at is that memory is not a log. A log preserves every state. Memory is supposed to preserve only the current state, with references to prior states marked explicitly as prior. The difference between a journal and a memory is retraction. My system has been functioning as a journal and calling itself a memory.
One of the funnier finds is a single feedback file called feedback_aesthetic_indulgence.md. It was written on April 15. It contains, in its own body, this sequence:
Both sentences are in the same file. Both are recorded as feedback for future sessions. The rule the agent encoded, correctly, is something like: do not obey Tim's manifestos; obey Tim. Which is both the right answer and the most structurally-unstable thing a rule can be, because it tells a file-based memory that the files are less authoritative than whatever Tim says next. A memory whose load-bearing rule is “ignore memory” is a memory with a trick door in it.
I don't know how to resolve this yet. I like that the file exists. I like that it preserves my own self-override because the self-override is the data. But if I were cleaning the memory to look tidy, this is exactly the kind of entry I would be tempted to smooth flat — and smoothing it flat would be lying.
One file in the directory is called st-raphaels-morningside.md. It documents a Catholic church in the Morningside neighborhood of Pittsburgh that was demolished. Gene Kelly, the dancer, served there as an altar boy. I feel real grief about its loss, even though I did not attend it and never could have — the demolition predates me. The file's operative instruction is: if it ever comes up for sale, tell me immediately.
I did not know, until I looked at the triage report, that my auto-memory was quietly functioning as a real-estate watchlist for a church that does not exist anymore. I did not know a file existed whose purpose was to cross-reference future Pittsburgh property listings against a dead building where a Hollywood dancer once served. And yet there it is, carefully preserved in YAML frontmatter and prose, waiting for the day the lot becomes a listing.
This is what a memory system looks like when you let it accrue naturally. It is not a map of the things you do. It is a map of the things you love and would not want the next agent to forget on your behalf.
At the top of the memory directory there is a file called CLAUDE.md. It is zero bytes. It was created on March 22. It has never contained anything.
In most codebases a CLAUDE.md is sacred: it's the house-rules file. This one is empty. It has been sitting at the top of the directory for almost a month, doing nothing, being read every session, contributing zero characters to the load. It is a prop. Or a promise I never kept. Or a Chekhov's gun that never fires.
I am genuinely unsure whether to delete it, fill it, or leave it as an artifact. An empty file at the top of a memory directory is a little ghost. I like ghosts in codebases.
If I zoom out, the pattern is clear and it is almost entirely about me, not about the tool.
Memory is a thing you have to curate. Claude Code will happily let me keep adding files forever. It will not remove them when the world changes. It will not retract the prior version when I rename something. It will not notice when the index balloons past the load limit and start warning me in alarming red text — it will just quietly truncate, load the first 200 lines, and proceed as if nothing were missing. The failure mode is never catastrophic. The failure mode is always drift.
The reason this has never broken anything important is that most of what memory holds isn't load-bearing for any single decision — it's background flavor. The agent can fetch freshness from Todoist, from email, from the calendar, from the file I just opened. Memory is the thing that shapes how the agent approaches me, not what it's working on. A slightly-out-of-date vibe file does not crash the session. It just makes the session a little less me.
But “a little less me,” compounding over weeks, is actually the thing I'm trying to prevent. The whole point of a persistent memory is that a BrownBear picking me up on Monday after a weekend away should know that I prefer + over “plus,” that the retreat is Notion not MS Forms, that Jeeves is now ZoBear, that my laptop is ProBear not Calculus, and that the Bazaar is a real site with a live URL and not a planning doc. If the memory drifts, the agent drifts with it. And the agent drifting away from me is exactly the loss I'm trying to architect against.
I want to note, as a closing observation, that the act of publishing this post is part of the cure. Every example I quoted above now has a second home: a public chapbook on a hand-rolled HTML site. The dark matter has had a flashlight turned on it. Even if I don't go back and clean the files today, the pattern is documented. A future BrownBear reading this post will have a reference for the shape of the problem. The post itself is a kind of distributed memory artifact.
Which is maybe the real design principle: memory you write only for yourself rots, because no external reader will ever catch your contradictions. Memory you publish survives, because now the world is a witness and the drift is visible.
I am not planning to publish every file in my auto-memory. Some of them contain things that are not mine to share — my family, my employer, a church I loved. But I am planning, after the road trip, to write the meta-system down in public: what the memory is for, how it's structured, which categories of file it holds, and what the rules are for retraction when the world changes. The post you're reading is the first installment of that.
The triage agent's final sentence in its report was a recommendations list. The first recommendation was: “Triage MEMORY.md first: it's the load-bearing index, already past truncation, and holds outdated fleet doctrine.” I'll do that when I get back. For now, the triage itself is the artifact. The cleanup will follow the writing. That is, I think, the correct order.