Memory Expiry and Decay: Scheduling What an Agent Forgets

A single global TTL is the most common design mistake. Facts, preferences, task state and tool outputs have different decay profiles and different failure modes when they go stale. The memory design guide by Hidekazu Konishi argues for building forgetting into the design from the start, with freshness metadata per memory type rather than one expiry rule.

Here is a starting table you can copy into a design doc and adjust with your own numbers. The durations are illustrative defaults, not measured optima; the important column is the failure mode, which tells you what to test.

Three rules make the table operational. First, attach the TTL to the record at write time, not to a global config, so a single entry can be granted a shorter life without a schema change. Second, separate "hard TTL" (a privacy or retention obligation that must be enforced) from "soft TTL" (a recall-quality default that can be extended on evidence). Mem0's eviction overview makes exactly this split: age-based TTL is the right tool for legally constrained data, while relevance decay handles recall quality.

Third, never let a pure TTL delete a small set of "never age out" facts. The classic failure is a user's allergy that has not been mentioned in six months. An age or recency policy quietly prunes it, and the next relevant question gets a dangerous answer. That same analysis flags this as the central weakness of LRU-style eviction: it treats access frequency as a proxy for importance, and rare-but-critical facts have low access frequency by definition.

A worked example of the budget effect: suppose an agent holds 40,000 memory entries averaging 60 tokens each. Relaxed TTLs let 5,000 of them exceed 180 days, and a naive retrieval layer puts 20 of those into every prompt at 60 tokens, which is 1,200 tokens of memory context per call. If a third of those are stale tool outputs that now expire in a day, and you also cut the retrieval fan-out from 20 to 12 candidates, the per-call memory payload drops to roughly 480 tokens. At 200,000 calls a month that is on the order of 144 million tokens saved, before any quality gain. Run the arithmetic with your own traffic to decide whether the engineering time pays for itself.

Time is a weak signal. An entry written yesterday can be wrong today, and an entry written a year ago can still be exactly right. Production systems need event-driven eviction alongside TTL. The AgentCore deep dive from AWS describes the core problem well: a memory system has to detect that two statements refer to the same thing and merge them without creating duplicates or contradictions, which is the same mechanism that lets you detect a contradiction and retire the older side.

Five triggers cover most cases:

1. Contradiction. A new write conflicts with an existing entry. Do not keep both and hope ranking sorts it out. Mark the older entry superseded, keep it in the audit log, and remove it from the retrieval index. The AgentCore write-up gives the canonical example: a user says they are allergic to shellfish in January and "can't eat shrimp" in March, and those must consolidate rather than coexist.
2. Low retrieval hit rate. If an entry has been a retrieval candidate many times and has never been cited in a final answer, it is crowding the candidate pool. Score each memory with an access counter and a citation counter, and evict entries that fall below a ratio you choose (for example, fewer than one citation per 50 retrievals after 30 days).
3. Source revocation. When the document, ticket, CRM record or permission that produced a memory is deleted or its access policy changes, the derived memory must go too. Keep a source identifier on every write so revocation is a query, not an archaeology project. The Atlan taxonomy of agent memory types is useful here because it separates governed organizational context (definitions, lineage, access policy) from free-form episodic traces, which makes the revocation boundary explicit.
4. Session boundary. Working memory should not survive the session by default. Anything worth keeping must be promoted explicitly to long-term storage. The Redis guide to agent memory describes the short-term layer as the equivalent of RAM: fast, limited and volatile, cleared when the thread ends. The KodeKloud explainer on agent memory makes the same point, that memory is a loop of writing, retrieving and forgetting rather than a one-time save.
5. Memory pressure. The OS-inspired approach in MemGPT uses warning and flush thresholds on the prompt buffer: at a warning level the agent is prompted to save what matters, and at the flush level older items are evicted and summarized into external storage. You can apply the same thresholds per user or per tenant, not just per prompt. The alphaXiv summary of MemGPT describes the queue manager and recursive summarization concretely, and notes that this paging does not enlarge the model's real context window.

A decision rule to keep teams consistent: evict on any hard trigger (contradiction, revocation, hard TTL) immediately and without review; evict on soft triggers (hit rate, soft TTL, pressure) only through a scheduled job that writes an audit record. The first category is correctness and compliance. The second is tuning, and tuning should be reversible.

Implement the policy as data, not as scattered if statements. A single policy record per memory type plus a pure function makes the behavior testable.

from dataclasses import dataclass
from datetime import datetime, timedelta

@dataclass(frozen=True)
class Policy:
    memory_type: str
    soft_ttl: timedelta
    hard_ttl: timedelta | None   # compliance bound, None means no hard limit
    max_retrievals_without_citation: int
    promote_after_citations: int  # citations needed to extend soft_ttl

def decide(entry, policy, now):
    """Return (action, reason) where action is keep, extend, expire or review."""
    if policy.hard_ttl and now - entry.created_at > policy.hard_ttl:
        return "expire", "hard_ttl"
    if entry.citations >= policy.promote_after_citations:
        return "extend", "proven_useful"
    if entry.retrievals >= policy.max_retrievals_without_citation and entry.citations == 0:
        return "review", "low_hit_rate"
    if now - entry.last_confirmed_at > policy.soft_ttl:
        return "expire", "soft_ttl"
    return "keep", "within_ttl"

Two implementation details matter more than they look. Store created_at, last_confirmed_at, last_retrieved_at, citations, retrievals, source_id and policy_name on every record; the machine learning mastery guide to agent memory design shows a comparable MemoryEntry shape with importance, confidence, source and timestamps, and gates persistence on thresholds rather than writing everything. And use a soft delete: set status = 'expired' and remove the entry from the retrieval index, but keep the row. Hard deletion belongs to the compliance path only, covered by hard_ttl.

Notice that last_retrieved_at is not the same as last_confirmed_at. A retrieval proves the entry was a candidate, not that it was right. Renewing on retrieval alone is how stale facts survive forever. Renew on citation in a delivered answer, or on an explicit user confirmation.

An eviction you cannot explain is an incident waiting to happen. The first time a customer says "your assistant used to know my account manager's name," you need to answer three questions in minutes: was the memory ever written, when was it removed, and by which rule. Without an audit trail the answer is a log grep through application code.

Log every mutation as an append-only event with these fields:

Three practices make the trail useful rather than merely present. First, capture a snapshot on delete, so a reviewer can see what was forgotten without restoring it. Second, make the reason codes a closed list, so dashboards can group expiries by cause and reveal, for example, that 60 percent of deletions come from one over-eager TTL. Third, retain the audit log longer than the memories themselves, and record the retention period in your privacy notice; the Forgetful but Faithful paper frames this as forgetting-by-design, where retention decisions are explicable and aligned with privacy norms, and evaluates six forgetting policies including FIFO, LRU, priority decay and a hybrid that scored best across its simulations.

For regulated data, the audit log is also the evidence file. A retention policy that promises an eighteen-month window is only credible if you can show, per record, when it was deleted and under which rule.

The review step is where most designs stop short. A forgotten entry is a hypothesis: we believed this would not be needed. Once a week, test the hypothesis on a sample.

Sample the expiries. Pull a random sample of 100 expired memories per policy and ask two raters, one of them the product owner for the agent, whether each removal was correct, neutral, or a mistake. Track the mistake rate. A rate that climbs means the TTL is too aggressive for that memory type.

Watch for re-ask signals. If users repeat information after the agent forgot it, that is direct evidence of a bad eviction. Instrument the conversation for repeated entity values and attribute them to the expired memory that used to hold them.

Run resurrection drills. Take ten expired entries, restore them in a staging index, and replay the queries that once used them. If answers improve, the policy is wrong. If they do not, the deletion was free.

Review the low-hit-rate queue, not just the deletions. The review action in the policy code above produces a queue of entries that retrieved often and never helped. That queue is where over-writing happens; it usually shows the agent recording too much small talk and too few confirmed facts.

Close the loop on contradictions. Every superseded fact should have a cause. If contradictions cluster around one source, such as a CRM sync that writes every field nightly, fix the source rather than the eviction job.

One decision rule ties the review together: promote on evidence, expire on default. An entry earns a longer life only when it is cited in a delivered answer, confirmed by the user, or explicitly marked as durable by policy. Everything else shrinks toward the TTL. This inverts the common instinct to keep everything and prune later, and it is far easier to defend when someone asks why the agent forgot.

The eviction policy has to live somewhere that sees every write and every retrieval. If you are running several models in one agent (a small model for extraction, a larger one for reasoning, an embedding model for the index), keep the memory layer independent of the model choice so a swap does not reset your counters and TTLs. Quanta Inference (https://quantaintelligence.ai/inference) exposes text, image, video, audio and embedding models through a single OpenAI-compatible API key, which keeps the memory service free to call whichever model the policy needs.

For teams that would rather not build the whole loop from scratch, a specialist can take the design and ship it with you; that is what the Quanta build service is for. Either way, the three controls are the same: a TTL per memory type, triggers that go beyond the clock, and an audit trail that makes every removal explainable.