Your Agent's Memory Needs a Garbage Collector

Persistent memory is the feature everyone adds to their agent and almost nobody maintains. The pitch is irresistible: the agent remembers your schema, your preferences, the decision from last Tuesday, and every session starts smarter than the last. The failure mode is quieter: memory grows monotonically by default, and an append-only store of facts about a changing world is a slow poisoning. The API that got migrated, the team that got reorged, the architectural decision that got reversed — all of it sits in the store next to fresh facts, retrieved with equal authority, injected into context with equal confidence.

A stateless agent makes isolated mistakes. A memory-equipped agent can turn one mistake into a recurring one, because it stores the error and then retrieves it later as evidence. One confidently-written wrong memory — "the payments service owns refund logic" — contaminates every future run that recalls it, and each run that acts on it may write new memories derived from it. That's not a storage problem. That's a garbage collection problem, and most agent memory systems ship without a collector.

Memory rots in two ways, and only one is an attack

The security literature has spent the last two years on memory poisoning — adversarial injection of malicious entries into an agent's long-term store. The MINJA attack demonstrated over 95% injection success against agents with naive memory stores, using nothing more than ordinary queries. That work matters, and it pushed teams to treat the memory write path as untrusted input.

But most rot isn't adversarial. It's entropic. A fact that was true when written stops being true, and nothing in the system notices:

• The world changed. The endpoint moved from v1 to v2. The table got renamed. The person who "owns deployments" changed teams. An agent that learned last quarter's schema keeps querying tables that no longer exist.
• The decision reversed. "We're standardizing on library X" was true in March and false in May. Both statements were faithfully extracted from real conversations. The store now holds a contradiction, and retrieval will surface whichever embeds closer to the query.
• The memory was wrong at birth. The agent misread a log, drew a wrong conclusion, and wrote it down. Unlike a hallucination that dies with the session, this one is now durable and citable.

Recent research put a number on how badly agents handle this. The STALE study tested whether LLM agents can recognize when their stored memories are no longer valid, and found that most agents fail to notice supersession — they keep acting on outdated assumptions even when contradictory evidence is available. Retrieval systems rank by semantic similarity, and a stale fact is exactly as similar to the query as the fresh fact that replaced it. Similarity search has no concept of "no longer true."

The uncomfortable implication: a confidently-recalled outdated memory is worse than no memory at all. Forgetting isn't a defect you tolerate. It's a subsystem you build.

Why "just store everything" keeps winning anyway

If lifecycle management is so obviously necessary, why do most systems skip it? Because deletion is scary and benchmarks don't punish hoarding.

The popular memory benchmarks — LoCoMo, LongMemEval — test recall across multi-session conversations. They reward remembering; they barely test unremembering. LoCoMo's conversations run roughly 16k–26k tokens, short enough to fit in a modern context window, and the questions ask what was said, not whether it's still true. A system that never deletes anything scores fine.

The incentives show up in real systems too. Mem0 redesigned its pipeline in 2026 to move away from update/delete consolidation toward single-pass, add-only extraction where old and new facts survive side by side — a defensible choice for preserving temporal history, and a revealing one about where the pressure points. Append-only is easier to build, easier to debug, and safer against the catastrophic failure of deleting something you needed. The cost — gradual contamination — never shows up in a demo.

TTL, the other default answer, is a blunt instrument. Time-based expiry treats all memories identically: the critical constraint and the trivial observation expire on the same schedule. A 30-day TTL deletes the still-true fact about your deployment process and preserves the three-week-old fact about a schema that changed yesterday. TTL bounds the age of your garbage; it doesn't identify what's actually garbage. It's a useful backstop — a poisoned memory can't outlive its TTL, which is why security guides recommend it — but it's the memory equivalent of restarting a server nightly to fix a leak.

What a real collector looks like

Garbage collection in a runtime works because reachability is computable: an object nobody references is garbage, period. Memory truth isn't computable the same way, but the GC framing still gives you the right components — a liveness signal, a compaction pass, and a way to trace and free what's dead.

Loading…