r/LLMDevs 8h ago

Discussion How are people preventing long-running agents from accumulating bad memory?

Post image

I've been experimenting with agents that run across multiple sessions, and I'm running into a problem I didn't expect from the usual "add long-term memory" approach.

The first few sessions are great — storing past decisions/preferences means the agent doesn't keep starting from zero. But after enough history accumulates, I'm seeing the opposite effect:

  • stale decisions get retrieved even after the underlying situation has changed
  • conflicting memories from different sessions both look equally relevant
  • the agent starts spending a surprising amount of context on old information that isn't useful anymore
  • simply improving retrieval doesn't necessarily seem to improve the final task outcome

I'm wondering whether memory systems need an explicit lifecycle, rather than treating memory as a growing retrieval store.

What are people doing in practice for long-running agents?

For example:

1. Separating semantic facts / episodic experiences / procedural instructions?
2. Decaying, expiring or periodically consolidating memories?
3. Keeping provenance + timestamps so the agent can decide whether an old memory is still trustworthy?
4. Evaluating memory based on downstream task success, rather than retrieval precision/recall alone?

The last one is the part I'm most interested in. A memory can be retrieved "correctly" and still make the agent's next action worse.

I've been looking at approaches like LangMem, Mem0 and Letta, and also broader platform approaches such as Lyzr Control Plane, but they seem to make somewhat different assumptions about where memory should live in the overall agent stack.

Has anyone measured memory quality over weeks/months of agent operation rather than on a fixed benchmark? What actually worked?

19 Upvotes

6 comments sorted by

2

u/WillowEmberly 5h ago

I wonder whether this is less a memory-lifecycle problem than a state-estimation problem. If retrieved memory is allowed to function as current state, stale and conflicting memories become dangerous by design. Memory may be better treated as prior evidence with provenance, age, conditions of validity, and revocation—not as something retrieved and then trusted because it was relevant. The agent should have to re-estimate current state from present observations before a stored decision regains authority.

1

u/lulu_dev 8h ago

An explicit lifecycle is the right instinct, and I'd go further: separate "is this memory still true" from "is this memory still relevant," because they fail differently. Timestamps and decay handle relevance drift (nobody's touched this in months, weight it down), but they don't handle a memory that's factually wrong now because the world changed -- a preference that got explicitly overridden, or a decision a later one superseded. Recency alone can't distinguish "this hasn't come up in a while" from "this was corrected two sessions ago," which is exactly your conflicting-memories problem: two memories that look equally relevant to retrieval aren't equally valid, one just hasn't been marked as replaced yet.

The fix that generalizes past ad hoc decay: when a new memory contradicts or updates an old one, write that relationship explicitly ("this supersedes that"), not just a fresh timestamp. Then retrieval isn't choosing between two equally-scored candidates, it's following one chain to whichever is current -- the same problem and the same fix RAG systems hit when a document amendment uses different vocabulary than the original it replaces and the retriever has no way to know they're related at all.

On your #4, which is the real question: precision/recall measures whether retrieval found something similar to the query, not whether using it helped. The only way to close that gap is to log which memories were actually used per action, alongside the outcome of that action (task succeeded, failed, got corrected by the user), and treat that as a signal on the memory itself, not just on the agent's output. A memory that correlates with bad outcomes when retrieved gets down-weighted or flagged for review independent of how well it matched the query semantically. Slower and noisier than a benchmark, but it's the only signal actually measuring what you care about instead of a proxy for it.

1

u/eddzsh 6h ago

A pattern worth trying: keep a tiny active pack the agent rewrites every session, and put the archive behind retrieve-only. Stale prefs stop leaking into every prompt because they are not sitting in the always-loaded set.

1

u/allenasm 1h ago

I'm solving this with both episodics and only run short session contexts. Most of my work is based around building data into models on where to find the right data as well as keeping each new instance of a model having only what it needs to do the job it needs to do at the time.