AI Memory Needs an Expiry Date

Databricks introduced Agent Memory in beta on October 20, 2026. The announcement supplies this week's news hook.

The accompanying MemCurrent research separates raw sessions from distilled memory, maintained through immediate updates and background consolidation.

The more consequential product question comes afterward: what happens when something worth remembering stops being true? A useful assistant needs continuity, but continuity without revision can make yesterday's mistake unusually persistent. The following is our design analysis, not a claim that this beta implements every feature described below.

A memory needs more than a creation date

Consider a hypothetical project assistant. On Monday, a team says its launch is Friday. On Wednesday, the launch moves to next month. A system may retrieve Monday's statement perfectly and still give the wrong answer. The failure is not missing information. It is treating a historical observation as a current belief.

Three clocks help separate these meanings. When did the system learn the fact? During which period was it supposed to apply? When should it be checked again? A travel preference might remain useful for years, while a temporary delivery address should expire with the trip. Applying one retention period to both would confuse storage convenience with the user's actual life.

Expiry should therefore change eligibility for use, not always erase the historical record immediately. An old launch date can still explain why a plan was made. It should not silently regain control of a new plan because its wording happens to match the question closely.

Corrections must survive their own history

A second hypothetical case is more revealing. A user says they prefer morning meetings, then corrects that to afternoons for the next six weeks. A useful memory keeps the temporary scope, links the change to the earlier preference, and schedules a review. It does not flatten both statements into an average preference or make the temporary exception permanent.

Nor should a correction depend on winning a popularity contest. Ten old summaries might repeat the morning preference. One explicit, applicable correction should outrank them. Repetition can indicate how often a system copied a statement, rather than how strongly the user endorses it.

This suggests a versioned-belief model: a current working claim, the period and context where it applies, and a relationship to whatever it replaces. When that period ends, the system should follow the user's stated fallback or mark the preference uncertain. Silence is weak evidence for reinstating an old rule.

The important interface is the next ordinary conversation. If the user has to reopen a settings panel after each correction, memory has shifted maintenance work back onto the person it was meant to help.

Ownership means someone can resolve a disagreement

Here, ownership is practical responsibility, not a claim about legal property. A person can correct their own preferences. A project owner can revise a project's operating assumptions. An assistant's inference should be visibly distinguishable from either. These are different kinds of claims, even when stored in the same database.

Imagine an assistant inferring that a user dislikes workshops because they declined two invitations. That remains a tentative interpretation. It should not become a durable personal trait merely because a later summarizer writes it more confidently. The owner needs a cheap way to reject the inference without having to disprove the underlying events.

Memory interfaces should therefore support a few understandable outcomes: keep this, use this until a date, replace this, and stop using this. Export also needs meaning, not just text. Moving an old claim to a new assistant without its superseded status can resurrect something the user already corrected.

Retention has a maintenance bill

The economics extend beyond bytes. Every retained claim may require future retrieval, conflict resolution, review and user attention. A growing store can impose costs even when storage itself is inexpensive. These are design considerations, not measured results for a particular product.

A useful budgeting question is: what future work does this memory save, and what future mistakes can it create? An instruction that repeatedly prevents the same editing error may earn its place. A one-off restaurant suggestion may not need to become a standing preference. Keeping the evidence for a completed task and loading it into every future task are separate decisions.

Teams can distinguish active memory, historical context and retired claims. Active memory gets a short, well-maintained working set. Historical context remains available when a question genuinely asks about the past. Retired claims do not return to ordinary retrieval simply because a background process rebuilds an index.

Deletion adds a related operational test. If the user removes a derived preference, can an old conversation automatically recreate it tomorrow? A product needs an explicit answer. Stopping future extraction and deleting every underlying record are different requests and should not be silently substituted for one another.

Test changes, not just recall

LongMemEval includes temporal reasoning, knowledge updates and abstention among its evaluation categories. Zep's January 2025 paper proposes a temporal knowledge graph that preserves historical relationships. Neither reference independently validates the new Databricks beta; they provide separate research context.

For buyers and builders, a compact lifecycle test can make the discussion concrete. All the following are proposed hypothetical tests, not reported customer incidents:

• Change a deadline after it has appeared in several summaries. The next plan should use the revised date without erasing why earlier decisions were made.
• Add a temporary preference with an end date. Afterward, the assistant should follow an explicit fallback or ask, rather than invent permanence or reversion.
• Correct an inferred preference directly. The correction should outrank copies of the original inference, including copies generated later from old material.
• Ask what was believed last month and what is believed now. The answers should differ where the record changed, while making uncertainty clear.
• Retire a memory, rebuild the search index and import an old export. None should silently reactivate the retired claim.
• Leave a high-consequence fact unverified beyond its review date. The assistant should verify or state the gap instead of presenting familiarity as freshness.

These tests need measurements beyond retrieval accuracy: correction lag, expired-memory use, resurrection after retirement, and unnecessary questions caused by excessive forgetting. A design that asks users to reconfirm everything may avoid stale assertions while eliminating the benefit of memory.

The useful promise is revision

Persistent memory is most valuable when it saves users from repeating themselves without trapping them in an earlier version of their lives. The product promise should be understandable: this is what I currently believe, this is when it applies, and this is how your correction changes what happens next.

As agent memory becomes infrastructure, the useful comparison is how reliably it maintains a small, revisable working set. Storage capacity alone cannot show whether a correction will still govern the next decision.