The agent I use on this site loads two kinds of written memory at the start of every session: a memory directory (12 topic files and an index, each file carrying the id of the session that wrote it) and the repo's CLAUDE.md. Three entries across them were wrong when I checked, and in all three the check came from outside the memory. A deployed model does not update its weights during a session, so everything it knows about my work comes from text somebody wrote earlier.
Two places a fact lives
Context window: the text the model can see in the current session. When the conversation outgrows it, the oldest turns drop out, and any fact stated there goes with them.
the window holds the most recent turns. as the conversation gets longer it pushes the oldest turns off the top, fact and all.
External storage: files, databases, vector stores, anything the agent reads back at the start of a session. Mine is plain markdown. It persists, and it is as current as the last time someone checked it.
Three notes that went stale
Pull requests marked merged. On 06-07 a workflow I ran wrote my open-source pull requests into the notes as merged. I checked each against GitHub the same day: two were open, inspect_sandboxes #33 and MCP registry #1339. The corrected entry says the workflow had "wrongly labeled" them merged and that they were "actually OPEN/in-review". On 10-20 I checked again. #33 had merged on 06-09, two days after my correction, and the file still says open. #1339 is still open, 137 days after I created it on 06-05. That note was wrong when written, right for two days, then wrong again.
A file list. The repo's CLAUDE.md listed six essays under thoughts/. I ran ls on 10-20: three of the six names pointed at nothing: things-i-think-about, democratize-or-forget and the-org-chart-on-your-laptop. Two of them were deleted on 05-30 (commit 22f6384), the third on 06-03 (bf76f71). The file was last edited on 05-08, 165 days earlier, and three files on disk were not on the list. I replaced the list on 10-20 for the redesign (commit 36a70b1) and found the gap while doing it. I did not check whether any session acted on the old list.
Two names filed as internal. One note told the agent that two names in a public README were internal codenames to keep out of public copy. The review of 06-09 found that one of them is a public third-party repository. The other is internal. I will not print either name here. The note gave a verdict and no source, so it could not tell me which half to doubt.
What caught them
Claude Code's own instruction for recalled memories says they "reflect what was true when written", and that if one names a file, function, or flag, the agent should "verify it still exists before recommending it". That rule catches the file list with one ls. It says nothing about the state of a pull request or the status of a name, and those are two of my three.
For those two, what helped was a date and a place to look. The note from 06-07 said #33 had been "open since 06-03", so I knew when its claim was made and which repository to query. The note about the names had neither. A date and a source make a note checkable.
Forgetting depends on the same two fields. With dates I can put a number on each stale entry: the file list was 165 days past its last edit, and its wrong entries had been wrong for 143 days (two of them) and 139 days (the third). A rule like "recheck any note older than N days" can then be written and scored. I have not picked N. Two of the three rechecks took one command each, gh pr view and ls, so the cost of looking is small once the note says what to look at.
What I have not measured
I did not audit all 12 files, and I have no count of how many entries are still true. These three are the ones I know about. I did not sample at random, so they say nothing about how often a note goes stale. I have not tested forgetting either: no run where an agent drops a note and I count what it gets wrong afterward. Tessera, my reliability eval, scores provenance on retrieved company knowledge and does not cover memory recall yet. The third case cannot be reproduced from this page, since I left the names out.