You are three months into a project. The agent has written thousands of lines that work. Then it does something you corrected in week two, and you think: we have done this twenty times, why am I teaching it again?
That is not impatience. It is a measurable failure mode, and it is not new. Every way an AI’s memory goes wrong has a twin in how a human team’s knowledge goes wrong, and people operations has been fixing those on a calendar for decades.
Memory Loss in Vibe Coding Is Real
Writing rules down is not the same as your AI following them.
We built a synthetic memory layer that carries knowledge from one session into the next. Hundreds of documented facts, hard rules and project histories, each tagged with the session that produced it and indexed so it can be found in one search. We keep it in Obsidian so the graph shows us which notes have gone orphaned, the ones nothing links to any more.
It is genuinely good. We still catch it failing.
Take one ordinary, repeatable task in our shop. Pull every rule that governs it into one place and there are thirty-one of them. Some written a year apart. All individually correct, individually documented, individually one search away.
Nobody holds thirty-one constraints from recall. Not a person, not a model. And the ones that slip are never the rules you use daily. They are the ones that matter twice a year.
Being findable is not the same as being checked.
HR Has Been Doing This for Decades, and Calls It Tuesday
Every serious operations team reviews its procedures on a schedule. Not when something breaks. On a calendar. The guidance is consistent: set a regular review frequency so procedures stay current, and treat SOPs as living training documents rather than an archive.
Why, if everything is already written down?
Because three things happen to written knowledge in every organization, without exception:
- The written procedure drifts from what people actually do.
- Two procedures written eighteen months apart contradict each other, and nobody notices until both get followed on the same day.
- Everyone knows the rules they use weekly and has lost the ones they use quarterly.
Read that list again as a description of your AI’s memory directory. It is not an analogy. It is the same failure in a different substrate, which is the good news: the fix is already invented and already boring.
An SOP review and an AI memory pass are the same operation. Retrieve it, check it against reality, correct it, put it back.
Note-takers landed here too. Obsidian ships a filter for orphan files, notes with no links in or out, which sit in isolation and are hard to rediscover, and the community’s own advice is to review the graph every month or two. Three unrelated fields, same answer, arrived at separately.
The Shape of Your Memory Decides Whether It Survives
Here is the most useful number we have measured on ourselves.
We ran three work queues, entire client projects, doing the same job. Two live in database models. One lives as a checklist inside a big text file. I counted how many tasks in each actually get closed out and marked completed:
- Database queue one: 57 percent reported complete.
- Database queue two: 22 percent reported complete.
- Text file queue: 1.3 percent. Eighteen items out of more than thirteen hundred.
Same team. Same discipline. The only variable is where the record lives.
Here is the part that matters. The work was done. Items did not get reported as resolved. That third queue was not neglected on purpose and those tasks were not skipped. Closing an item meant hand editing one line inside a two megabyte file, so nobody did it. The queue kept showing thirteen hundred open items that were not open at all.
Anything painful to update will not be updated, and it rots without announcing it. The binder in the back office versus the laminated card by the machine. Operations worked that out a long time ago.
The Neuroscience Says Both Are the Same Machine
A stored memory is not permanent. Retrieve it and it becomes transiently labile, briefly unstable, and has to be re-stored. That is reconsolidation. As one review puts it, consolidated memories are stable but mutable, and can return to a labile state when activated during retrieval, and that restabilizing window is what lets new information be folded into what is already stored.
That inverts the intuition. Pulling a memory up is the only window in which you can correct it. A memory you never retrieve is a memory you can never fix.
Better still, the cycle does not wear it out. Repeated labilization and reconsolidation strengthen declarative memory in humans.
HR did not land on the annual handbook revisit because someone read a neuroscience paper. They landed on it because it works, for exactly this reason. The rules you never revisit are the rules quietly rotting.
Yes, You Will Get Slower First. HR Budgets for That Too.
This is where most teams quit.
Retrain a team or reconsolidate an AI’s memory and output gets worse before it gets better. That is the J-curve: performance drops after a change, then recovers past where it started. The dip is not waste, it is the cost of unlearning, a valley of high-effort conscious processing before the ascent.
Assume you give up something like a tenth of your throughput for a couple of weeks. You will re-teach things you thought were settled, and some of it will feel insulting, because you did already teach it. Any ops lead who has rolled out a new system plans capacity around exactly this and does not panic in week two.
Then you come out at higher fidelity, because the rules your AI follows are finally the ones that are true. The people who get hurt are the ones who quit halfway through and revert.
What a Monthly Pass Actually Looks Like
This is the SOP review, adapted.
- Retrieve everything on a topic at once. Not the rule you remember. All of them. That is how you find out the number is thirty-one and not five.
- Read them side by side. Conflicts only surface in the assembly. Two rules that are individually perfect can be jointly impossible, and neither knows the other exists.
- Check against reality, not against each other. We once carried a note saying a thing was impossible for a specific technical reason. It was wrong. An earlier session had checked the wrong source and written down the conclusion, and for days every session that read it inherited the same wrong answer with total confidence. A confidently wrong memory is worse than a missing one. A missing one sends you looking. A wrong one stops you looking, and an internally consistent handbook can still describe a company that no longer exists.
- Assemble, never consolidate. Merging twenty notes into one summary and deleting the twenty feels like tidying. It destroys the reason each rule exists. No competent HR team deletes the case file when it updates the policy. Generate a checklist that holds only pointers, so every original stays whole.
- Move anything painful to update. See the 1.3 percent.
- Encode what can be encoded. When a rule can be a check in code, write the check. The document stays; nobody has to hold it in their head. That is building the constraint into the form instead of the training.
One hard-won note on that last point. We wrote a guard, tested it, watched it pass, then found the code path the real work ran through was a second copy of that function in another file. The fix we had just verified would have caught nothing. Verify that your fix reaches the surface that actually failed, not the one that was convenient to test.
Want Me to Look at Yours Today?
Send me whatever you actually have. The memory directory, the rules file, the prompt that keeps growing, or just the one thing your agent keeps forgetting. Do not tidy it first. Tidy is the problem.
I will tell you where it has drifted, which rules now contradict each other, and what a first pass would change. If the answer is that you do not need us and you just need a calendar reminder, I will tell you that and you can have the reminder for free.
Send me your project and I will take a look.
Every system looks like this at month three, including ours. Drift is not sloppiness. It is the default state of anything that learns, which is why HR exists as a function at all.