The man who couldn't forget

In the 1920s a Moscow newspaper editor noticed that one of his reporters never took notes. Every morning he read out the day's assignments, a long string of addresses and names and instructions. Solomon Shereshevsky just sat there listening. When the editor asked him why he wasn't writing anything down, Shereshevsky repeated the whole briefing back, word for word. The editor sent him to a young psychologist, Alexander Luria, who studied him for about thirty years. Luria tried tables of numbers, lists of 70 words, verses of Dante in Italian (which Shereshevsky didn't speak) and a meaningless formula. He remembered all of it. Years later he could still recite lists from their early sessions. Luria's book about him is mostly the story of a man struggling: he found it hard to follow a story, because every word brought a crowd of images with it and the point got lost underneath them. Faces confused him, because a face changes with every expression and he kept a separate memory of each one. He tried writing down things he wanted to forget and burning the paper. It didn't work.

I think most AI memory tools are building Shereshevsky: save every session, search the pile later. It feels safe because nothing is ever lost. Then the model has the same problem Shereshevsky had: ask it about deploys and it gets back every conversation that ever mentioned deploying, including the ones where we changed our minds. It has to work out which one still counts. You pay for all of them in tokens (the units AI providers charge by), on every turn.

When I built ns-brain I chose one fact as the unit: a short title and a body. A fact looks like this: "We deploy from the release branch, because main broke twice in October." Forty minutes of chat (deploy, fail, bugfix, re-deploy...) went in and one sentence came out. The title does most of the work: it's the spine of a book on a shelf, the part that actually gets searched. The body can be as long as it needs to be. A memory titled "deploy notes" is a book with a blank spine. It's on the shelf and nobody will ever find it. Two habits in ns-brain came out of that:

Each memory holds one fact. If one memory held five facts together (a note called "server notes" with the deploy branch, the server name, the test command...) and one of them changed, you would have to rewrite the whole note to fix one fact. With one fact per memory, a correction replaces exactly that fact and nothing else.
Nothing goes in that the code already says. The code is already the record of what the code does (function names, settings, folder layout...). A copy of it in memory goes out of date the first time someone changes the code. From then on the memory lies. ns-brain keeps what the code or the usual comments on the code can't tell you: why we chose something, what broke last time, what the team agreed, who to ask.

This has a real cost: someone has to decide what the fact is. In ns-brain that's the AI agent itself (Claude Code, Codex, Cursor...) while it works. Take a normal session: you tell the agent "John at ABC Ltd says our invoices show the wrong VAT. Check the invoice code, fix it, run the tests." The agent changes the rounding. You look at the result and say: "No, this approach is not working. Try a different one." The agent finds that the VAT rate was read from the customer's country instead of ours, fixes that and runs the tests. You say: "OK, perfect, commit." Until that moment nothing was worth keeping, because nothing was settled (the first fix was a guess, the second one was not approved yet). "Commit" (or any other word of approval: "perfect", "ship it", "done"...) is the signal that the work is finished and you accepted it. Now the agent writes two facts:

"Wrong VAT on invoices (reported by John, ABC Ltd): the rate was read from the customer's country instead of ours. Fixed by always reading our own rate."
"Changing the rounding does not fix wrong VAT totals: tried on the ABC Ltd bug and rejected."

The second fact is the one people forget to keep, but it is the one that stops the next session from trying the same wrong fix again. ns-brain also helps the agent during the session: a hook reads your messages for corrections and rules ("no, not like that", "from now on...") and reminds the agent to store them. If a session ends without storing anything, the next session is told so. It is still a judgement made by a model, so sometimes it keeps the wrong thing or misses the right one. I still prefer a memory that chooses over a memory that keeps everything. ns-brain keeps those facts on your laptop. Its Hive edition keeps them on a server instead, so the same facts reach every machine you work on and everyone on your team. Part 2 tomorrow: why "staging is down" should fade within days while "we chose Postgres" never should.