My coding agent keeps memory in flat markdown files. One fact per file, a frontmatter header, an index that loads at the start of every session. Ninety files, two weeks old, twenty five sessions.
Every one of those files makes claims about my machine. This path holds that project. This command exists. This credential lives under that id. Claims decay, and nothing in the format tells you when one goes bad. So I wrote a script to walk the memory and check each claim against the machine as it is right now.
That number was wrong, and the way it was wrong turned out to be the interesting part.
Not everything in a memory file can be verified. "The user prefers short answers" is not falsifiable by a script. But a surprising amount is: filesystem paths, checked with os.path.exists command names, checked with shutil.which credential ids, checked by asking the password manager whether the object still exists dates written as a shelf life, checked against today internal links between memory files, checked against the set of filenames
Memory files are written by an agent for an agent, and they use backticks the way prose uses italics. So the auditor reported these as missing commands:
Those are not commands. comprehensive and robust are words that file bans me from writing. webdev and fastapi are tags. One file about frontend geometry contributed h-11 and h-7, which are Tailwind classes.
The fix was to stop treating a lone word as a command. A command is a name plus an argument, and the name has to either be one I know is a CLI or carry a real flag:
A hardcoded allowlist feels like cheating. It is not. The alternative is a tool that reports sql duplicate as a missing binary, and a tool that does that gets ignored within a day.
The path check matched anything that started with a slash. Memory files are full of API routes:
Neither is a file. Both are endpoints on someone else's server, and os.path.exists will say no about them forever.
Relative paths came out entirely. ./scripts/gate.sh was reported dead, and the file exists. It sits in a project directory, and the auditor was resolving it against its own working directory. A relative path is a claim about a context the checker does not have, so it cannot be checked. Guessing at it produces exactly one outcome, which is a wrong answer delivered confidently.
The date check flagged anything in the past. But a memory file is allowed to talk about the past. A note recording that something happened on the sixth of August is correct forever. A note saying a document is valid until the sixth of August stops being useful the moment that day passes.
I also moved these out of the rot count entirely. An expired shelf life is not a false statement, it is a statement that has stopped being actionable. Mixing the two categories inflates the scary number, and the scary number was already doing enough damage.
The credential one looked serious. A file about my project's secrets vault referenced an id, and the password manager said no such item.
I checked it by hand before believing it. The id names a vault, not an item. The vault is alive and holds six credentials. My script asked op item get, got a failure, and concluded the object was gone, when the correct question was whether the id resolves as either kind of object:
Three real findings out of ninety files. Two directories that no longer exist, and an application path off by one word, /Applications/Telegram.app where the disk holds Telegram Desktop.app.
Earlier the same day, before any of this existed, I hit what looked like textbook rot. A stored instruction told me a key lived in a specific vault under a specific id. I ran it and got:
Deleted or archived. I read that as deleted, wrote off the record as stale, and went looking for where the key had moved.