Give an AI agent memory, and the first thing everyone celebrates is that it remembers you. The second thing nobody plans for is that some of what it remembers stops being true after some time, and memory becomes stale. This leads to a quiet bug that quietly sits on your memory, but nothing crashes until you need to retrieve that one particular memory.

This post is about what staleness actually is, why "just remember everything" makes it worse, and two concrete mechanisms you can reach for when you're building this yourself: expiring memories on purpose, and deleting them cleanly when they need to go.

What does staleness mean?

A stale memory isn't wrong the day it's written. It's wrong later, and the system doesn't notice the moment it crossed over. Say, “The user prefers dark mode" might be true forever, or until they switch jobs and get a new laptop and nobody tells the agent. No flag on it says "this one's going bad.”

Staleness isn't a data quality issue or a bug that you can catch in test. It's a time problem. A fact's usefulness has a shelf life, and most memory systems don't track shelf life at all; they just track "was this ever said.”

There's a version of this that's obvious and a sneaky version.

• The obvious version says that if something changes, then the old fact gets contradicted directly. Say, for example: "Alice has admin access" becomes "Alice's access is revoked." The right memory layer retires the old fact the moment the new one shows up, instead of leaving both sitting around, and that's a solved enough problem already.

• The sneaky version says that nothing ever contradicted the fact. It just quietly stopped mattering, or nobody ever confirmed it's still true, and it's still sitting there, still gets retrieved, and shapes what the agent says or does.

Now, there are a few ways a memory can go stale, and you can name them as you like, but I wanted to point out just two ways that I feel matter the most. Let’s dive into them next.

Two ways a memory goes stale

Not all staleness looks the same, and honestly they need different fixes:

• Decay: Any information has a natural expiry, and everyone kind of always knows it. "Traveling this week", "In a meeting until 3", "On call this weekend", are a few examples. These aren't wrong later; they're just done. If your memory system has no concept of "this expires," you're relying on the agent to figure out from context that a week has passed, which it mostly won't, because nothing in the text says so.

• Unconfirmed drift: A preference gets stated once, gets stored, and then just sits. Nobody re-confirms it or checks if it is still true six months later? Well, that depends on how confident you want an agent to be about something it hasn't heard in six months. This kind is genuinely hard to detect automatically; most systems don't even try, and I won't pretend there's a clean code snippet for it. It's more of a design posture: don't treat a six-month-old unconfirmed preference with the same confidence as something the user said an hour ago.

The first kind, decay, you actually can build for directly. That's the one I want to show code for.

Handling decay: Give memories an expiry

If you know a piece of information has a shelf life when you write it, say so. Mem0's hosted API takes an expiration_date on add() operation. Once that date passes, the memory stops showing up in normal search, but it isn't deleted. It's just not going to get surfaced by default anymore.

If this got you Interested? Get yourself a Mem0 API Key and let's dive deeper.

import datetime
from mem0 import MemoryClient

mem = MemoryClient(api_key="your-api-key")  # get one free at app.mem0.ai
USER_ID = "user_123"

yesterday = (datetime.date.today() - datetime.timedelta(days=1)).isoformat()

mem.add(
    "The user is traveling this week and unreachable by phone.",
    user_id=USER_ID,
    expiration_date=yesterday,
    infer=False,
)

mem.add(
    "The user prefers dark mode in the editor.",
    user_id=USER_ID,
    infer=False,
)

# hidden by default, it expired
results = mem.search(
    query="what do we know about this user?",
    filters={"user_id": USER_ID},
)

# still there if you actually ask for it
results_with_expired = mem.search(
    query="what do we know about this user?",
    show_expired=True,
    filters={"user_id": USER_ID},
)

import datetime
from mem0 import MemoryClient

mem = MemoryClient(api_key="your-api-key")  # get one free at app.mem0.ai
USER_ID = "user_123"

yesterday = (datetime.date.today() - datetime.timedelta(days=1)).isoformat()

mem.add(
    "The user is traveling this week and unreachable by phone.",
    user_id=USER_ID,
    expiration_date=yesterday,
    infer=False,
)

mem.add(
    "The user prefers dark mode in the editor.",
    user_id=USER_ID,
    infer=False,
)

# hidden by default, it expired
results = mem.search(
    query="what do we know about this user?",
    filters={"user_id": USER_ID},
)

# still there if you actually ask for it
results_with_expired = mem.search(
    query="what do we know about this user?",
    show_expired=True,
    filters={"user_id": USER_ID},
)

import datetime
from mem0 import MemoryClient

mem = MemoryClient(api_key="your-api-key")  # get one free at app.mem0.ai
USER_ID = "user_123"

yesterday = (datetime.date.today() - datetime.timedelta(days=1)).isoformat()

mem.add(
    "The user is traveling this week and unreachable by phone.",
    user_id=USER_ID,
    expiration_date=yesterday,
    infer=False,
)

mem.add(
    "The user prefers dark mode in the editor.",
    user_id=USER_ID,
    infer=False,
)

# hidden by default, it expired
results = mem.search(
    query="what do we know about this user?",
    filters={"user_id": USER_ID},
)

# still there if you actually ask for it
results_with_expired = mem.search(
    query="what do we know about this user?",
    show_expired=True,
    filters={"user_id": USER_ID},
)

A couple things worth calling out here.

infer=False matters most here for this to make sense. With inference on, Mem0 runs extraction on what you send it, which can rewrite, split, or merge it with existing memories before it's stored. For a demo where the exact text and the exact expiration date need to line up, you want it stored exactly as written, nothing decided for you in between.

show_expired doesn't undo expiry, it just lets you see past it. An expired memory isn't gone, it's parked. If you ever need to audit what an agent used to believe, or figure out when something changed, that history is still there. Decay is a visibility switch, not a shredder.

Set the expiry to when you write the memory, and you don't need cron jobs sweeping through your memory store guessing what's gone stale.

Handling deletion: The other failure mode

Deletion isn't staleness by itself; it's what can go wrong around it. Say a memory got superseded properly; the old fact was correctly marked outdated when a new one contradicted it. Later, someone deletes the newer fact, maybe as cleanup, maybe by mistake. If that delete only removes the note itself and doesn't touch what it superseded, the outdated fact is now the only thing left standing, which can resurface simply because the delete was incomplete.

Mem0's delete() takes a delete_linked flag for exactly this:

# only removes the fact itself, whatever it superseded can resurface
mem.delete(memory_id=memory_id, delete_linked=False)

# removes the fact and the whole chain it superseded
mem.delete(memory_id=memory_id, delete_linked=True)

# only removes the fact itself, whatever it superseded can resurface
mem.delete(memory_id=memory_id, delete_linked=False)

# removes the fact and the whole chain it superseded
mem.delete(memory_id=memory_id, delete_linked=True)

# only removes the fact itself, whatever it superseded can resurface
mem.delete(memory_id=memory_id, delete_linked=False)

# removes the fact and the whole chain it superseded
mem.delete(memory_id=memory_id, delete_linked=True)

The delete_linked=True parameter is how you make sure a delete actually reaches the whole chain, not just the top of it. A delete that only removes the surface fact and leaves its history dangling is a delete that can let something old and wrong come back from under it.

This is basically the same idea as the "agentic unlearning" problem people are starting to write about for LLM systems in general: deleting something needs to reach every place that fact left a trace, or you haven't really deleted it, you've just hidden the newest layer of it.

Wrapping up

Memory staleness isn't a crash, it's a quiet confidence problem, an agent acting on something that used to be true like it still is. The fixes for the obvious version of it are pretty mechanical once you know they exist: give shelf-lived facts an expiry, and make sure deletes actually clean up what they're supposed to, not just the newest layer. The harder version, memories that just quietly stop mattering without ever being contradicted, doesn't have a clean API call yet. Worth remembering that as you design for it, not every kind of stale has a flag you can flip.

Further Reading

• Memory eviction and forgetting in AI agents

• AI Memory Management for LLMs and Agents

• Stale AI agent memory and how Mem0 Dream fixes it

• Memory in Agents: What, Why and How

——-

Mem0 is an intelligent, open-source memory layer designed for LLMs and AI agents to provide long-term, personalized, and context-aware interactions across sessions.

Get your free API Key here: app.mem0.ai

Sign up using app.mem0.ai or self-host Mem0 from our open-source GitHub repository.

——-

Frequently asked questions

Q. Is memory staleness the same as a memory being wrong?

Not quite. A wrong memory was incorrect from the start; maybe extraction messed it up. A stale memory was correct when it was written; it just stopped being useful or accurate over time, and nothing marked that transition.

Q. Does deleting a memory in Mem0 also delete what it replaced?

Only if you ask it to. delete() defaults todelete_linked=False, which removes just that one memory. Set delete_linked=True if you want the delete to also remove whatever that memory had superseded, so an older fact can't resurface underneath it. Note this flag is confirmed in the client source but isn't on the public docs pages yet.

Q. If I set anexpiration_date, is the memory gone after that date?

No. It's hidden from normal search results, but it's still in the store. Passing show_expired=True on search() or get_all() brings it back. Expiry changes visibility, not existence.

Q. Why use infer=False in the decay example?

Because with inference on, Mem0 processes what you send before storing it, which can change the wording or combine it with existing memories. For an example where the exact text needs to carry the exact expiration date, storing it verbatim keeps the demo honest.

Q. What about preferences that never get explicitly contradicted or expired, do they just stay "true" forever?

In most memory systems, yes, unless something actively updates or removes them. This is the harder, less solved side of staleness. There's no automatic timer on an unconfirmed preference; it's usually on your application to decide how much weight an old, never-revisited memory should still carry.