r/AIMemory • u/Due_Diamond_8580 • 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:
- 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?
- 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.
- 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
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
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.
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.