This started as a request to soften an email. It turned into an audit of my whole setup, and by the end of it AI memory management had stopped being a background convenience and become a maintenance job with a real cost.

Here is what I found. Fourteen workspaces. Eleven of them holding memory files. One hundred twenty-three memory files in total. And one rule, a simple one about when a work log gets written, sitting in nine separate files across seven workspaces under nine different names.

Not one of those nine files was wrong on the day it was written. That is the part that gets you. Every copy started out correct, then the underlying practice changed, and eight of the nine copies quietly stopped matching reality while still reading like authoritative instructions.

If you are running an AI assistant across more than one project, you already have this problem. You just have not counted yet.

What AI Memory Management Actually Is, and Why It Splits Apart on Its Own

Strip away the marketing and an AI memory file is a plain text file the assistant reads. Some load automatically at the start of every session. Some get pulled in when the assistant decides they are relevant. Either way, they are documentation that a machine reads instead of a person.

According to Anthropic's engineering write-up on context engineering, project instruction files get dropped into context up front at the start of a session, while the assistant retrieves other files just in time. That up-front load is deliberate. The file carries the conventions you do not want to repeat every time.

Here is the structural problem underneath everything else I found. Memory is scoped per workspace. A correction you give the assistant inside one project is invisible in every other project you run. Not deprioritized. Invisible. So if you want a correction to hold everywhere, you have to write it everywhere.

The system manufactures duplicates by design. The moment a rule exists in nine places, you have nine files aging independently. Most people do not realize their AI memory is a documentation system until it is already stale. It looks like a feature. It behaves like a wiki nobody owns.

Nine Copies of One Rule, Across Seven Workspaces

The rule itself is boring, which is exactly why it makes the point so well. It says the activity log for a work session gets written once at the end, rather than built up piece by piece as the work goes along.

That is one sentence of policy. It had nine homes and nine different filenames. Some copies said it directly. Some buried it inside a longer procedure. Some described the old behavior, because they were written before the rule changed and nobody went back for them.

What struck me is that there was no way to tell which copy was current by looking at it. They all read with the same confidence. The stale ones were not marked stale. They were just files being read into context at the top of a session, shaping what the assistant did next.

I ended at 95 files, down from 123. Twenty-six of those removals were duplicates of rules that already lived somewhere better.

The Playbook That Told Me Two Opposite Things, 110 Lines Apart

The second finding was worse than duplication. I keep three governing playbook files, one for each of my working contexts, and they are supposed to be identical. They were not. They had drifted apart over months of small edits made in whichever folder I was working in.

One of them contradicted itself. On one line it told the assistant to use a particular file handoff tool. One hundred ten lines later, the same file told it never to rely on that tool.

Both instructions were written by me. Both were true at the time I wrote them. The second one was the correction, and I had added it without removing the thing it corrected.

This is not a hypothetical failure mode. There is a well-circulated example of an agent looping on two conflicting instructions, one telling it to inspect state before acting and another telling it to act immediately, and burning roughly fifty dollars in API calls before anyone noticed. Conflicting rules do not produce an error message. They produce expensive, confident nonsense.

The Worst Finding Was a Procedure I Already Knew Was Dangerous

Two of the three playbooks still told the assistant to move a task between board sections by creating a copy and deleting the original.

That procedure destroys everything attached to the task. Two months before this audit, it permanently wiped a client's task comments and uploaded file attachments. No recovery. A memory file in the setup already recorded that incident in detail.

So the incident was documented, the harm was known, and the instructions that caused it were still sitting in two playbooks telling the assistant to do it again. Knowing about a failure and correcting the instruction that caused it are two completely separate acts, and only one of them had happened.

The fix took three steps. Verify that the safe method actually exists in the current tooling rather than assuming it does. Rewrite the section around it. Then, the part people skip, write the incident into the playbook as the reason. A rule with no stated reason is a rule the next reader quietly reverts because it looks arbitrary.

Then I wrote one canonical playbook to all three locations and verified they matched by comparing MD5 checksums. That check earned its keep immediately. One copy still did not match, because it carried a UTF-8 byte order mark on line one that was invisible in every editor I opened it in. Eyeballing three files would never have caught it.

If you have watched an AI assistant work a problem with you, this pattern will feel familiar. I wrote about a version of it in the malware cleanup that would not stay clean, where the thing that kept coming back was not the infection but the assumption about what had already been fixed.

Why Stale Memory Costs More Than Disk Space

Twenty-eight extra files is nothing on disk. The cost lands on accuracy. According to HappySupport's audit of 30 SaaS help centers, roughly 40% of articles contained at least one factually outdated element relative to the live product. A 40% stale rate becomes a 40% confidently wrong answer rate.

The other cost is attention. According to Chroma's Context Rot report, which evaluated 18 models including GPT-4.1, Claude 4, Gemini 2.5, and Qwen3, performance grows increasingly unreliable as input length grows, even well short of the advertised window. Nine copies of one rule do not make the assistant nine times more likely to follow it. They dilute the context and give it nine chances to read the wrong one.

How I Run AI Memory Management Now

Four rules came out of that audit. None of them are sophisticated. They are what AI memory management should have looked like from my first week.

One canonical file per rule, and only one. If a rule genuinely has to exist in several locations because of how memory is scoped, it is not several rules. It is one rule with copies, and every copy gets written from the same source in the same pass. Never edit one and stop.

Verify copies by checksum, not by reading. If three files are supposed to be identical, prove it with an MD5 comparison and state the result. Your eyes cannot see a byte order mark. A checksum can.

Every rule carries a date and a reason. Not "do it this way." Write "do it this way, added March 12, because the old way destroyed a client's attachments." A rule with a scar on it survives. A rule with no explanation gets optimized away by whoever reads it next, including you in six months.

Delete on sight. When you find a duplicate, remove it in that session. Do not note it for later. Later is how you get to 123 files. The good news is that deletion is the cheapest fix available and it never needs testing.

One habit worth adding on top: audit on a schedule, not on a hunch. I now walk the memory folders the same way I would run a plugin inventory on a client site. It is the same instinct behind using the assistant to audit a WordPress site. Point the tool at the thing, count what is actually there, and stop reasoning from what you remember installing.

A Memory File Is an Observation, Not a Fact

Here is the moment from that session I keep coming back to, and it is the one thing worth taking out of a post about AI memory management.

Partway through, the assistant told me a dangerous procedure was still documented that way. It said so because it had read a memory file about the procedure. It had not read the procedure. The procedure had already been fixed.

The memory file was not lying. It was accurate on the day it was written and it had no way to know the world moved. That is what every memory file is: a point-in-time observation, not current state.

This generalizes way past AI. Your wiki page is a point-in-time observation. So is your runbook, your README, and the comment you left in a config file three years ago. Every one of them describes a world that existed when someone hit save.

Go count your memory files this week. Not skim them, count them. If any rule that matters exists in more than one place, collapse it to one and delete the rest. If you would rather have someone else run that audit across your sites and systems, that is the kind of work I do.

Sources

• Chroma, Context Rot: How Increasing Input Tokens Impacts LLM Performance: https://www.trychroma.com/research/context-rot
• Anthropic, Effective Context Engineering for AI Agents: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• HappySupport, State of Documentation 2026: 30 Stats From 8 Reports: https://www.happysupport.ai/en/blog/state-of-documentation-2026