Agent Memory Needs an Expiration Rule

“The agent just needs memory” is usually where the trouble starts.

The phrase can mean a customer’s preferred name, the last tool call in a long job, a summary of a repository, last month’s approval policy, or a fact retrieved from a live system five seconds ago. Those records have different owners, different failure costs, and different useful lives. Putting them in one memory store without saying when they stop being trustworthy turns continuity into a source of quiet errors.

An agent does need memory. It also needs to know when the memory is only a lead.

That is the job of an expiration rule. Every memory that can become false needs a source, an observation time, an invalidation condition, and a way to check again. Otherwise the agent cannot distinguish “I learned this before” from “this is still true.”

Memory Is a Claim

Consider a support agent that remembers a customer is eligible for a replacement. That might be a useful summary of a case it handled yesterday. Today the replacement could have shipped, the customer could have returned the original item, or a manager could have denied the exception. The remembered sentence has become a claim about a changing system.

The same thing happens with API guides, repository notes, pricing terms, inventory, policy, account status, and permissions. The model does not see a fact aging. It sees tokens that arrived from a memory tool. If those tokens carry no date or source, they look much like fresh evidence.

This is why a large context window does not solve memory. A longer history can preserve more stale material. OpenAI’s guidance on session memory focuses on trimming and compression because carrying forward everything makes a long-running agent slower and less reliable.¹ Anthropic makes the adjacent point: context is finite, and agents benefit from lightweight references that load current information when they need it.²

Memory earns its place when it saves a lookup without replacing the authority for the fact.

Give Each Record a Freshness Contract

An expiration rule does not need an elaborate knowledge graph. Four fields cover most cases.

The source gives the agent a way back to evidence. The timestamp tells the application how long the claim has been sitting around. The invalidation rule names the event that matters. The recheck path prevents an expired record from becoming a dead end.

The rule should follow the information, not a generic cache setting. A user’s writing preference may stay useful until that user edits it. A discount code may expire at midnight. A pending bank transfer must be checked against the ledger before an action. A product policy may stay current for months, then change in one deploy. A one-hour time to live is sensible for none of those by itself.

Keep State, Preference, and Knowledge Separate

Teams call all persistent information memory because it is convenient. The application should keep the categories separate.

Workflow state is the record of work the application owns: a job identifier, completed steps, a retry count, an idempotency key, the last persisted checkpoint. Store it durably and update it through normal application logic. A model summary can help explain the work, but it should not be the system of record for whether a payment ran or a database migration finished.

User preference describes a person’s stated choice: a preferred report format, a saved destination, an accessibility setting. Give it a scope, an edit path, and a visible owner. A preference can still be outdated, but its recheck may be as simple as letting the user change it.

Retrieved knowledge is a claim from another source. This is where freshness does the real work. The record should preserve enough of the source to fetch it again. A policy summary points to a policy version. A customer fact points to the relevant record. A repository note names the commit, file, or issue that established it.

Learned summaries deserve extra suspicion. A summary can be very useful for resuming work after a context reset. It can also turn a temporary conclusion into durable folklore. Keep the underlying sources beside the summary. Mark unresolved statements as unresolved. Replace a summary when the evidence changes instead of appending another paragraph that disagrees with it.

Retrieve Current Facts at the Point of Action

A compact memory record often should contain a pointer rather than a complete answer. File paths, document IDs, record keys, source URLs, and stored queries let the agent find the current material without hauling a warehouse of old text into every turn. Anthropic describes this as just-in-time context: retain lightweight identifiers, then load the relevant data through tools at runtime.²

That approach changes the memory tool’s job. It does not answer, “What is the return policy?” from an undated summary. It answers, “The return-policy source is document 72, last read yesterday. Read the current version before making an exception.”

The recheck should be proportionate to the consequence of acting on an old rule. Giving Data to AI makes the broader architecture case. Let the model reach the systems that own the facts instead of stuffing their contents into a prompt and hoping the contents remain current.

Freshness also has to reach the action boundary. An agent can remember that an account is allowed to do something, then call a tool that checks the account’s current permission anyway. The memory helps the agent choose a path. The permission service decides whether the path is allowed. Rules are not controls, and a memory entry is not an authorization decision.

Make Staleness a Normal State

An expired memory should not be an error message that leaves the agent guessing. It should be a normal part of the record lifecycle.

The distinction between stale and false matters. A record may still be right after its freshness window closes. The application simply no longer knows that it is right. That is enough to require a recheck when the agent is about to give advice, make a decision, or take an action based on it.

Sometimes the source cannot be reached. Then the agent needs a policy for uncertainty. It can say it cannot verify the claim, ask for confirmation, defer the work, or route to a person. What it must not do is quietly promote a stale memory into current evidence because the lookup was inconvenient.

This is the same pattern as a guide receipt in The Model Has to Read the Manual. The application can require the model to retrieve a current guide before it queries complex data. A memory freshness rule generalizes that idea. Current context becomes a prerequisite where old context can cause damage.

Correction Should Rewrite Memory

The useful signal is often an agent correction. A customer says the saved preference is wrong. A tool rejects an action because policy changed. A reviewer finds that a summary missed an exception. Each event should do more than fix one reply. It should update or retire the record that produced the mistake.

That feedback belongs outside the transcript. Claude 201 argues that repeated work improves when corrections enter a durable brief or ledger. Memory follows the same rule. A correction trapped in chat lets the agent repeat the same claim after the next context reset. A correction attached to the record changes the next retrieval.

There is a practical payoff here. Expiration shrinks the surface that deserves inspection. The team can audit records that are due for revalidation, records whose source version changed, and records that caused a correction. It does not have to reread an ever-growing pile of agent notes and infer which parts of it are still alive.

The best memory systems know two things about every stored claim: where it came from and what would make it unsafe to repeat. That is enough to give an agent continuity without asking it to mistake yesterday’s context for today’s world.

Footnotes

1. OpenAI, “Context Engineering: Short-Term Memory Management with Sessions”, September 9, 2025. ↩

2. Anthropic, “Effective Context Engineering for AI Agents”, September 29, 2025. ↩ ↩²