We trained AI agents to remember information, but not to know when the information is out-of-date, superseded, or too sensitive to remember.Now imagine an AI agent confidently telling a customer that your refund policy is "14 days, no questions asked.Now imagine an AI agent confidently telling a customer that your refund policy is “14 days, no questions asked.” The answer is directly from a true support conversation the agent had months ago. The issue is that the policy was altered three months ago - reduced to 7 days after a spike in fraud. The agent hasn't lied. It has just picked up a fact that was once true.That's the one thing that nobody tells you about when they sell you on "agents with memory. For years, the industry has been fixated on making agents remember things, whether it's vector databases, embeddings, long-context windows, or memory layers added to each framework. Then those systems shipped, and the actual problem became apparent: the agents remember too well, too long, and they never ask themselves if the thing they remembered is still real.We created systems that had no memory loss, and no judgment on when the memory loss ends. Humans don't work that way, and it turns out it's a feature and not a bug we need to fix.Memory Was Never the Hard PartIt's easy to store information now. Embed, index and retrieve on similarity. The difficult part is what to do with a memory after the time has gone and the world has passed on under it.Consider your everyday functioning. You don't carry the burden of all the conversations you've had with the same person. You can recall yesterday's standup and last March's standup only if you have some memory. It's not a storage issue, your brain is just fine. It's an ongoing process of letting things go as most things cease to matter.This is not something that most agent memory systems do. They append. A fact is put in, and it is there forever, and can be retrieved with the same confidence on day 400 as on day one. There is no question in the architecture, since there is no need for it: nothing was constructed to ask the question "is this still true?".The Stale Decision ProblemThe refund policy story is a little quirky and almost hilarious. Here's a less humorous one.An agent involved in vendor negotiations recalled a month ago email exchange where a vendor agreed to "net-60 terms.An agent involved in vendor negotiations recalled a month ago email exchange where a vendor agreed to "net-60 terms. What it didn't realize was that the deal fell through, that the supplier relationship was re-established two months later, and that the new contract called for net-30. In a dispute with the vendor, the agent invoked the old terms from its memory store. It wasn't hallucinating. It was picking up a true memory of a true conversation that had simply been replaced.This is the stale decision problem and it's everywhere you look and see: approval that was revoked, price that changed, person that left the company, project that was cancelled and re-cancelled, etc. All of these leaves a memory that is factually correct about the past but factually incorrect about the present. An agent that has no understanding of decay treats them both as the same.The bad news is that much of the "agent memory" that we call it is just an append-only log in a trench coat. Logs are candid about being historical records. Memory implies something closer to belief—an active, current model of how things are. It's two different jobs, and it's when they're mixed up that things get wrong.What Relevance Decay Actually Looks LikeHuman memory has a half-life and is context-dependent. You can't remember a person's name after 10 seconds, but you never forget your childhood address. The difference is that it is a rough estimate that continually evolves, based on the likelihood of needing it again and the amount of change since you learned it.Agents require a similar mechanism, and it's not that hard to explain, though it's a bit tricky to construct.Anything transactional, time based decay. A fact that says the user is travelling this week should be considered for one week and then fade away and not affect the user's behavior.Event-based invalidation for anything related to a decision. If a memory has been recorded as "approved", it must be hard approved, not slow approved, when it gets un-approved.Confidence weighting on retrieval, not storage. A memory from six months ago on the same topic shouldn't be a better match for similarity than a memory from six hours ago on the same topic, if the embedding is just as similar.Explicit source of truth checks for any other source of truth which has a canonical record elsewhere: pricing, policy, org structure. The agent's knowledge of a fact must never supersede the actual system that owns that fact.None of this is foreign. It's simply work that was left out because the metric everyone optimized for was “remembering more” and “remembering correctly, for the right amount of time” is not the same metric.A Framework for Deciding What to Trust: FRESHIt helps to have a checklist rather than a vibe. Before a stored memory gets to influence a decision, I run it through what I call the FRESH Memory Model:F — Freshness: How recently was this confirmed as still true?R — Reliability: Did it come from an authoritative system, or from a passing remark in conversation?E — Expiration: How long should this realistically stay active before it needs re-checking?S — Supersession: Has a newer memory already replaced this one?H — Harm sensitivity: What actually happens if the agent gets this wrong?The purpose of going through all five is not for the sake of bureaucracy, it's because the amount of caution is different for different memories. An out-of-date note on a favorite coffee order doesn't pose a significant threat if the freshness rating is low. If there is a policy for a refund, or a term of a contract, or a medical detail, that one is stale, and a high harm-sensitivity score should prevent it from being used in memory, even if there is a small chance that it is wrong.Privacy Is the Other Half of ThisThere's another failure mode that gets less attention but is more important: agents that remember things that they shouldn't have remembered in the first place.A user states a medical condition informally when requesting a schedule change. A customer complains about a divorce, and then provides details about a billing issue.A customer complains about a divorce and then details a billing issue. An employee states that he or she is looking for a new position and requests that the agent write an email that is "resignation-like. None of that was permission to store those details forever, cross-referenced, and possibly brought to the fore in some future unrelated way of interaction.Human interactions are governed by social norms of discretion: most people wouldn't store every piece of information a co-worker says and then be able to pull it up a year later in a different context. Agent memory systems have no idea of those expectations unless they are explicitly encoded. An agent will do what a discreet colleague wouldn't: keep the detail in his mind, index it and bring it to the fore later, as if it didn't ask first.This is not an ethics issue, it's a liability issue. Each and every piece of retained personal information is a piece of personal information that can leak, be subpoenaed, be pulled into a prompt injection, or appear in an output where it simply shouldn't. The solution is not "store less": sometimes, context really needs to persist. The patch is to view retention as a choice that needs to be explained, rather than an automatic process because it's easier to delete than keep.That means:Memories tagged with why they were kept, not just what they contain.A default expiration on anything personal that isn't explicitly load-bearing for the task.A real deletion path—not a soft flag that leaves the data recoverable in a backup or a training set somewhere.Boundaries around what gets remembered across sessions versus what should die with the conversation that produced it.Building the Muscle to ForgetNone of this argues against giving agents memory. Memory is what makes an agent useful across more than one turn instead of being a very articulate autocomplete. The argument is that memory without forgetting isn't memory—it's a liability with good retrieval.A few practical shifts worth making if you're building or buying agent systems right now:Give every stored memory a TTL by default, even a long one, not forever. Forever should be a clear decision and not a non-decision. However, TTL should diminish the power of a memory, not eliminate it entirely: Historical information can still be useful in recording what was once true, but it cannot be allowed to become a representation of what is true now.Separate facts from decisions. A fact about the world decays slowly. A decision made at a point in time should be treated as provisional until reconfirmed, because decisions get reversed far more often than facts change.Log confidence and recency together at retrieval time, so a fresher, weaker match can beat an older, stronger one when they conflict.Audit what's being retained periodically, the same way you'd audit access logs. If nobody can tell you what your agent remembers about your users six months from now, that's not a feature, that's exposure.For years, the industry has been using memory as its end goal for making agents feel capable. It's not the end of the race. The hard one is what to keep, and what to let go, and it is the one that will make these systems trustworthy or not.We taught machines to remember. We forgot to teach them when to stop.