What actually earns a place in an assistant's persistent memory, after a year of pruning mine
Persistent memory sounded like the feature that would make an assistant genuinely useful and for about six months it made mine worse. Everything I told it stayed, including things that stopped being true, and I ended up with a tool confidently applying a preference I had abandoned in March.
I now prune it monthly. Here is what survived and what the rule turned out to be.
Earns its place
- Facts about the work that are tedious to restate and change slowly. Which package manager, which test runner, that the project uses one particular convention that looks wrong but is deliberate. Restating that every session is real friction and it is stable for months.
- Explicit anti-preferences. "Do not add comments explaining what the line does." "Do not rewrite code I did not ask about." These are the highest-value entries I have, because they correct a default rather than adding information, and defaults reassert themselves every session.
- Output shape. How much explanation I want around a change. Cheap to store, saves a sentence every time.
- A small number of hard constraints. Things where being wrong is expensive, a language version that cannot move, a dependency that must not be introduced.
Does not earn its place
- Anything about the current state of the work. What I am working on this week, where a bug got to, what the plan is. All of it goes stale in days and then actively misleads, and this was the source of every bad outcome I had.
- Biographical detail. It shapes tone in ways that were mildly pleasant and never once made an answer better.
- Anything I would have to remember to update. This is the actual rule underneath the whole list.
The rule
Store things that are true because of a decision already made, not things that are true because of where the work currently is. The first kind changes when I change it, deliberately. The second kind changes constantly and silently, and the memory has no way of knowing.
The failure worth describing
The worst entry I ever stored was a preference for a particular data-access approach. I changed my mind four months later, updated the code, and did not think about the memory. For weeks afterwards I got suggestions gently steering back toward the old approach, and because they were plausible and matched a lot of the codebase, I did not notice a pattern - I just kept making small corrections and finding the tool slightly stubborn. It was not stubborn; it was correctly remembering something I had told it and then made false.
That is the real risk of persistent memory. Not that it stores something wrong, but that a formerly-true fact fails silently and looks like the tool being mediocre.
@memory_went_stale · 3w ago
The failure you describe at the end is exactly mine and I want to name why it is so hard to spot.
A stale memory does not produce obviously wrong output. It produces slightly-off output that is completely defensible in isolation. Every individual suggestion looks reasonable, so you correct it and move on, and there is no single moment where you think "something is misconfigured". The cost accumulates as a vague sense that the tool has got worse.
What finally caught it for me was reading the stored list cold, months after writing it, and finding three entries I disagreed with. Not subtly - I actively did not believe them any more.
So the practical thing is your monthly prune, and I would add: read the entries without the context of why you added them. Anything you cannot immediately justify on its own terms should go, because "I probably had a reason" is how stale facts survive.
Reply
Report