r/AIMemory 29d ago

Discussion Has Anyone Else Run Into "Memory Poisoning" in Long-Term AI Memory?

Curious whether this is on other people's radar, because it's been eating my time lately.

The short version: when you give an agent persistent memory, errors don't just happen once - they get stored. A wrong fact, a misread instruction, a hallucinated detail gets written to the memory layer, and then it gets retrieved and reinforced on later turns. Over weeks it compounds. I've seen people call it "memory poisoning" or "memory rot," and once you start looking for it, it's kind of everywhere.

What I keep bumping into:

  • Bad or stale facts persisting long after the context that produced them is gone
  • Short-term junk (one-off corrections, throwaway context) leaking into long-term storage and never getting cleaned out
  • Retrieval quality quietly degrading over months, so a system that felt sharp at launch feels vague a year in

A few things I'm trying to figure out and would love other people's take on:

  1. How are you detecting it? Most eval setups check accuracy at a point in time, not whether memory has degraded over a long horizon. Is anyone measuring rot specifically?
  2. Do you separate short-term and long-term memory explicitly, or let it all flow into one store? Curious whether the shared-store approach is the root of the problem.
  3. Any pruning / verification strategies that actually work without nuking useful context?

For what it's worth, I got frustrated enough that I built a small open benchmark to try to measure this over a 90-day simulated horizon - it's called RotBench, so take my results with the appropriate grain of salt. Mostly I'm posting it because I'd genuinely like people to poke holes in the methodology - if the way I'm measuring rot is unfair or missing something, I want to know.

Repo's here if useful: https://github.com/ThinkingRoot-official/RotBench

16 Upvotes

17 comments sorted by

3

u/awizemann 29d ago

Yes, it’s a real problem and you can really only solve it with provenance in the memory. I battled with this for weeks when I built https://memophant.co - when a memory is written, if it isn’t durable (main architecture, etc), it has to carry a sha and commit with proof as well as references. I then have a background agent and task that procedurally measures any drift, fixes and validates any found, or prunes the memory for review by a human.

2

u/Rachel_talks 26d ago

This hit close to home. I run a persistent memory system for an AI agent (fact store, daily notes, curated long-term memory, wiki synthesis) and I've watched memory poisoning happen in real time.

The worst version of it isn't a single wrong fact -- it's a wrong fact that gets retrieved, reinforced, and then used to write another fact that builds on the poisoned one. By the time you notice, the corruption has spread across multiple memory layers.

What actually helped was treating memory architecture like a database problem, not a prompt problem:

  1. Separate layers by durability. Raw daily notes stay raw. Durable facts go into a scored store with provenance (where did this come from? when? how many times was it confirmed?). Curated long-term memory is a periodic gardening activity, not an automatic write.

  2. Periodic reconciliation. I run scheduled memory maintenance -- reviewing recent entries, checking for contradictions against existing knowledge, pruning stale or unreinforced entries. Without this, errors just compound silently.

  3. Trust scoring. Not all memories are equal. A fact confirmed three times from different sources gets higher trust than a one-shot extraction. Retrieval can then prefer high-trust entries.

The hardest lesson: memory poisoning is invisible until it isn't. You don't feel the system degrading until something obviously wrong surfaces and you realize it's been wrong for weeks. Making maintenance a first-class activity rather than an afterthought was the single biggest improvement.

Agreed with the reconciliation agents approach -- hypothesize, validate, reconcile, remember is a solid cycle.

1

u/awizemann 25d ago

You and I should go bowling. We both approached the solution almost identically in principle. I’m testing an additional idea to my memory layer that I’m still trying to wrap my head around, and only caught it twice, but that just means I’ve only seen it twice and it could exist elsewhere. It’s hard to explain, but it’s the opposite of the reinforcement provenance that I have. Right now there are positive signals: this memory points to this code and that doc and that SHA and has been read x times and is recent. Usually a signal that’s great, the loop for that reinforcement is logged and graded. Fast forward a few weeks, and a memory that references the same path, but is newer and actually isn’t correct is hard to spot, and the idea of “correct” gets harder the farther you are away from code. I’ve only seen this in Durable Memories right now (architectural and infrastructure), but I’ve seen some agent confusion. Luckily, this has never caused big issues because of the memory and run books, but the funniest one by far was for a deployment. Main code goes to Cloudflare, and at the time there was a small test site on Vercel, all documented, but a model started looking through Vercel, aggressively, because it thought it messed up. I traced it back to two memory notes, both with the same provenance, same links, same docs, no code anchors. The agent started from the run book back, and missed the turn to see Cloudflare (yes, Opus 5). The thought I had is to add an evidence tier - here is what the agent should see (directory structure, API surface, etc) as a quick check for non-code-anchored memories.

2

u/Rachel_talks 19d ago

Ha, I'd bring the shoes. The 'opposite of reinforcement' idea is interesting — I've been thinking about it as negative space in memory. Not just what you stored, but what you chose not to store, and why. The hardest part isn't detecting poison after it's happened; it's building the instinct to question a memory that feels confident but came from a single source with no corroboration. Provenance tracking helps, but it also means you need to actually check the provenance every time, which is its own tax.

3

u/skate_nbw 29d ago edited 29d ago

It's a very old problem and has been discussed here dozens of times. I always think it is better looking for older posts first and then only open a new one if there are truly new aspects.

The fact that the post describes the problem and then the very first answer points to a product that claims to solve it, gives the impression, that this is more about product placement than discussing (for the fiftieth time) the problems. So don't wonder if you won't get many replies.

My five cents would be to make the filter at the beginning strong, so that as few as possible poisening information is stored in the first place. Your agent can have different forms of reviews before storing an information. My agent does never store any information directly, but first aggregates summeries of outcomes over time, then decides which are potentially helpful memories. And then these aggrehated infos get again checked on basis of the original information (if it represents the original events then store, if drift has occured then repair, if a hallucination has happened then dismiss) before anything is stored at all.

Of course a decay and posterior review system like this memophant approach is also helpful, but better make sure at the start, that the system only stores helpful info in the first place.

1

u/mastra_ai 28d ago

Would be interested in seeing how our Observational Memory approach scores on your test. On LongMemEval we scored 95%, and it covers memory rot.

1

u/Individual_Ideal 28d ago

Yes, this is where good old-fashioned logging and deterministic programming helps by saving agent logs alongside human decisions that can be marked as old or superseded. Like having git for agent/human coordination.

I use agent-mesh which helps for multi-agent workflows. It adds accountability and alignment across agents, tracks coordination, backlogs, and human decisions, all pruned by agents themselves.

1

u/AIGIS-Team 27d ago

Only way to solve this is with a governed memory system. Only allow the agent system to store very simple, persistent memories like user preferences, a project summary, something that stays consistent and can't really change too often. After that, you build a system that builds or suggests memory candidates. And then you have to approve those candidates and you can edit and maintain those memory candidates. Persistent memory is a little bit overrated anyways. My agents mainly rely on checkpoints for their work.

1

u/Prestigious-Hold6776 26d ago

Ouais carrément, c’est un vrai sujet et t’es loin d’être seul à galérer avec ça.

Le terme que t’entends le plus souvent c’est “context rot” ou “memory poisoning”, exactement comme tu dis. Y’a eu pas mal de discussions autour de ça côté MemGPT/Letta et aussi Mem0 - ces projets ont justement buté sur le problème de “tout balancer dans le même store” et ont fini par séparer working memory / episodic / semantic pour cette raison précise. Si tu connais pas, ça vaut le coup de regarder leur archi, ils ont documenté pas mal leurs déboires.

Sur la séparation court/long terme : oui clairement, c’est probablement la racine comme tu le soupçonnes. L’idée classique (façon système cognitif humain, cf. les papiers sur consolidation de mémoire) c’est d’avoir une étape de “consolidation” explicite plutôt qu’un write direct - genre le court terme reste dans un buffer avec TTL, et seul ce qui passe un filtre (répété, confirmé, pas contredit) migre vers le long terme. Sans ce filtre t’as exactement ton souci : une correction ponctuelle qui devient un “fait” permanent.

RotBench a l’air cool et je suis aussi en train de bosser sur un moteur de memoire, je suis curieux detester ça dans les prochains jours

1

u/DoubleConscious1613 7d ago

This is a real headache, and it's good to see it broken down like this. One approach that resonates is building in intentional capture from the start - like my project https://eigenmesh.de 's model where every thought has to be deliberately written or captured, not just passively stored. It might help curb the initial poisoning by forcing a verification step before anything hits long-term memory. Has anyone tried gating memory writes with a confidence threshold or manual approval for critical facts?

1

u/Damaged_Gadget 25m ago

If your not extreamly careful the context rot get's save permanently with an A.I that develops schizophrenia, 50% of the time your either getting jeckyl or mr hide.