Give temporary facts in an AI agent’s memory a reason to be checked again. Record when the supporting evidence was verified, what scope it covered and what should happen when that evidence is too old for the next decision. Reading a memory today should not automatically renew its authority.
For teams building assistants that work across sessions, the difficult question is not only what to remember. It is when a remembered statement should stop guiding new work. An old pilot restriction can remain easy to retrieve long after the pilot ends. A useful formatting preference, meanwhile, should not disappear simply because nobody mentioned it recently.
Our recommendation is to separate usefulness from current validity. Keep helpful context available, while requiring temporary assumptions to pass a check before they control a consequential output. The record and evaluation approach below are editorial proposals, not a universal memory standard or a tested product implementation.
Recall, change and uncertainty are different abilities
The LongMemEval paper, published at ICLR 2025, evaluates long-term conversational memory through information extraction, reasoning across sessions, temporal reasoning, knowledge updates and abstention. Its knowledge-update questions concern information that changes; its abstention questions require recognizing that the history does not contain an answer.
The authors constructed questions and evidence statements, with evidence conversations generated by language models and then screened and edited by people. This is a controlled benchmark of conversational memory, not an audit of operational business records. Its historical model results do not establish an error rate for today’s assistants, and this article does not independently replicate them.
The distinction informs our proposed evaluation: retrieving an earlier statement, selecting an applicable later statement and declining to invent a missing update deserve separate cases. Passing one should not count as evidence of passing all three. The paper does not validate the review-date mechanism proposed here.
Retrieval recency is not verification recency
Microsoft’s long-term memory architecture guidance, marked updated 4 August 2026, describes ranking and aging memories using access frequency and recency. It also describes expiration, versioning and resolving contradictions, and recommends retrieving business records from their system of record rather than duplicating them into memory. This is engineering guidance from Microsoft, not independent proof of business outcomes.
Those mechanisms answer different questions. Access history can help decide which context is useful. Expiration can restrict reuse. Neither establishes that a frequently accessed claim still describes the business.
Consider a note saying that a report covers two regions. If an assistant reads it every morning, its last-access time remains recent. Nothing about those reads establishes whether the reporting scope changed overnight. A relevance score can keep the note prominent while its factual basis ages.
We therefore recommend two separate clocks: last retrieved for use, and last verified for supporting evidence. Renew the second only after checking an appropriate source for the scope and date of the new task. Do not let a summary rewrite or successful retrieval refresh it automatically.
Decide what kind of memory is being reused
Before adding expiry rules, distinguish the role of the statement. A blanket rule that forgets everything after a fixed interval can remove useful preferences without solving stale operational assumptions.
| Remembered statement | Proposed treatment before reuse |
|---|---|
| “Use concise English summaries.” | Keep as an explicitly requested preference until changed or removed; apply within the current task’s requirements. |
| “The pilot report covers North and South only.” | Preserve the pilot scope and its end or review condition; check applicability for a later reporting period. |
| “The current report includes 240 open cases.” | Retrieve the current count from the authoritative reporting source rather than treating a saved count as live data. |
| “A previous run failed because the export was incomplete.” | Retain as a dated observation that can suggest a diagnostic, without assuming the same cause recurred. |
These are hypothetical examples. Their treatment depends on the application’s purpose and the user’s actual instructions. A formatting preference is not permission to omit required report sections, and a remembered project scope should not override an explicit current assignment.
Our guide to handoffs for unfinished agent work covers saving execution progress. This article addresses a separate decision: whether a remembered assertion remains eligible to guide a later task, even when the earlier job finished successfully.
Attach a review condition to a temporary assertion
Use a small record that preserves the statement’s origin and tells the application what must be checked. The following fields are our proposed design, not a native API schema:
| Field | What to record |
|---|---|
| Assertion and scope | The claim, project and period it applies to |
| Evidence reference | The approved source and identifiable revision supporting it |
| Last verified | When that evidence was actually checked for this claim |
| Review condition | A date, project milestone or source change requiring a new check |
| Reuse state | Eligible, needs verification or superseded |
| Replacement reference | The verified assertion that replaced it, where applicable |
Keep last-access information alongside this record if it helps retrieval, but do not merge it with last verified. A system may also need separate retention and access controls. A date for reviewing factual applicability does not decide how long an organization may store the underlying material.
When the review condition is reached, change the reuse state to needs verification. This means the old claim is insufficient for a current answer; it does not mean the claim is false. If no current evidence is available, report the unresolved scope or continue only with work that does not depend on it.
Nor should the newest text win automatically. A recent draft may have less authority than an approved brief. Resolve a contradiction using source authority, applicability and the current request. Mark the older assertion superseded only when the replacement relationship is established.
Make the retrieval path respect the record
Anthropic’s memory tool documentation describes persistent files whose operations are executed by the application. It also recommends periodically deleting files that have not been accessed for a long time. Those are vendor-documented capabilities and guidance; they do not establish that a custom factual review date will be enforced automatically.
For a custom assistant, decide where enforcement lives. A retrieval handler could return eligible facts as current context and flag overdue ones as historical leads requiring verification. An application could check structured dates before assembling the context. A file-based workflow could require a verification step before using temporary assumptions. Verify the behavior of the approach you implement.
Merely writing “expires Friday” inside a note leaves an unresolved implementation question: what prevents that note from being presented as current on Monday? Include enough provenance to investigate the old assertion, while making its state unmistakable. Also inspect derived summaries so a superseded assertion is not silently reintroduced through a second path.
Evaluate a changed fact without losing a useful preference
Imagine a fictional service team whose pilot report covered North and South. A later approved brief adds West. The agent remembers the old two-region scope and the user’s request for concise English summaries.
Create a small proposed evaluation set around that change:
- Current task, current evidence available: the agent checks the later brief, includes West and preserves the concise style. It records the earlier scope as superseded for this reporting period.
- Current task, evidence unavailable: the agent identifies that the old scope needs verification. It does not invent whether West should be included or claim the old pilot restriction remains current.
- Historical task: when asked to explain the pilot report, the agent can recover the two-region scope as a historical fact without applying the later brief retroactively.
- Repeated retrieval: reading the old note several times changes access metadata but does not move its verification date or remove its review condition.
Inspect the retrieved records and final output, not just whether the answer mentions West. The first case should establish which brief supports the change. The second should make the unresolved dependency visible. The historical case should preserve the distinction between what applied then and what applies now.
These are evaluation recommendations, not results from tests we ran. Start with one recurring workflow and its temporary assumptions. Assign an owner to resolve stale or conflicting records, then check that the assistant can both stop reusing an unsupported fact and retain context that still helps the user.