← memoryrot.com · field notes

Memory rot: why long-running agents get dumber

Last year the conversation was about context rot — the way LLM performance degrades as you stuff more tokens into the context window. Chroma’s research put a name on something practitioners had been feeling for months, and once it had a name, everyone started designing around it.

I think we’re about to go through the same cycle one level up the stack: persistent memory.

Every serious agent deployment now has a memory layer. Mem0, Zep, Letta, or a homegrown vector store with summarization on top. The pitch is always the same: your agent remembers, so it gets better over time. In practice, I’ve watched the opposite happen. Agents that run for weeks don’t get smarter — they get confidently wrong in ways a fresh instance never would.

I’ve started calling this memory rot: the progressive degradation of an agent’s persistent memory as it runs. It’s not one failure mode. So far I’ve seen at least five distinct ones:

Stale memory. The agent stored a fact that was true in March. It’s July. Nothing in the retrieval pipeline knows the difference. Unlike a human, the agent doesn’t feel uncertainty about old information — a memory retrieved is a memory trusted.

Memory conflict. New information contradicts old information, and both get retrieved. Which one wins depends on embedding similarity and chunk ordering, not recency or truth. The agent’s behavior becomes nondeterministic in a way that’s brutal to debug.

Compression drift. Most memory systems summarize to stay under budget. Summaries of summaries lose specificity, and worse, they lose the hedges. “The user mentioned they might try X” becomes “the user uses X” three compactions later. Each individual compression looks fine in isolation; the drift only shows up over long horizons.

Retrieval pollution. Deprecated memories don’t die — they keep matching queries. A decision that was explicitly reversed still surfaces because the reversal lives in a different chunk with a different embedding. Deletion is the least-implemented operation in every memory framework I’ve looked at.

Identity drift. The subtlest one. Stored self-referential memories (“I prefer to answer concisely”) accumulate and interact, and the agent’s persona slowly walks away from its system prompt.

What strikes me is that none of this is a model problem. You can swap in a better model and memory rot persists, because it lives in the storage layer. It’s an engineering problem — closer to cache invalidation and schema migration than to prompting. Which, if the old joke about the two hard problems in computer science is any guide, means it won’t be solved soon.

The uncomfortable implication: the industry is selling “agents that learn from experience” while shipping systems where experience is a liability past a certain horizon. Fresh context beats rotten memory. Right now the state of the art for fixing a long-running agent is the same as for a misbehaving router — turn it off and on again.

I’ve started cataloguing failure modes and mitigation patterns at memoryrot.com. If you’ve run agents with persistent memory for more than a few weeks, I’d genuinely like to hear which of these you’ve hit — and whether you’ve seen failure modes that don’t fit the taxonomy.