When Should an AI Agent Forget?

Forgetting is a decision about use

In this design, forgetting means withdrawing a memory from active decision support when its validity is uncertain, expired or superseded. It does not mean silently deleting the record of what a system previously knew. A retained audit record and a current working memory serve different purposes.

Consider an illustrative purchasing agent that remembers a supplier quote. The quote may have been correct when recorded but may no longer apply to the quantity, date or delivery destination now requested. Retrieving the exact stored number is not enough. The agent needs evidence that the number can be used for this particular decision.

Store the conditions with the claim

A proposed System Brain memory record should contain the claim, its source identifier, observation time, applicable role, validity conditions and review status. Where available, it should also retain a source version and links to records it replaces. These fields make it possible to ask where an instruction came from and whether its authority still applies.

The W3C PROV family provides a vocabulary for representing how information relates to entities, activities and responsible agents. That is useful background for documenting provenance. A provenance record does not establish that a source is correct, and this article does not claim that System Brain implements or conforms to the full PROV specifications.

Sources: [1]

Time is only one expiry signal

A fixed time limit is simple to apply, but not every fact changes at the same rate. A short-lived price and a historical test result should not automatically receive the same validity window. A historical observation can remain accurate as history even when it no longer supports a current operational decision.

Other triggers may be more informative: a source publishes a replacement, permission changes, a role is reassigned, a dependency becomes unavailable or the current task falls outside the original scope. The design should also support an unknown state when a source cannot be reached. Failure to check freshness must not be treated as proof that the old evidence is still valid.

Borrow the distinction between freshness and revalidation

HTTP caching distinguishes freshness from validation of a stored response. RFC 9111 describes rules for reusing stored responses and checking with an origin when required. This offers a useful engineering analogy: possession of a stored item is different from permission to reuse it now.

An AI memory system needs additional semantics. A valid HTTP response can still contain incorrect advice, and a successful network check does not establish that a statement applies to the requested action. Source revalidation should therefore check content identity, applicability and authority as well as retrieval success. The protocol below is our proposed design, not a requirement of the HTTP standard.

Sources: [2]

Give the memory an explicit state

A state transition should record both the reason and the evidence used. An expired memory may still be shown as historical context, but it should not quietly re-enter an execution path because it is semantically similar to the question. Permission to retrieve and permission to act must remain separate.

Current: Eligible for consideration within its recorded scope; ordinary authority checks still apply.
Needs revalidation: Retrieve authoritative evidence or ask for help before relying on the claim.
Superseded: Link to the replacement; exclude the old claim from current action support.
Invalid for this role: Do not use it to authorise the requested action.
Historical: Preserve the dated record for explanation and audit under applicable retention rules.

Connect memory to act, ask and stop

A current memory is not an instruction to execute automatically. It contributes evidence to a separate decision process. If the evidence is sufficient and the action is authorised, the system may proceed. If a necessary fact can be clarified, it should ask for help. If the action is prohibited, it should stop rather than using a remembered precedent to override the boundary.

This follows the separation of role, memory and authority explored in the JARVIS and System Brain report. The proposed memory lifecycle extends that engineering discussion. The published prototype checks do not establish that this complete lifecycle is implemented or that it improves model decision accuracy.

Sources: [3]

Evaluate stale decisions and unnecessary hesitation together

A proposed experiment would compare three retrieval policies: no explicit expiry, fixed expiry and source-aware revalidation. Freeze a synthetic scenario set before evaluation, record which sources changed and define the acceptable action at the decision time. Hold task wording, model version, tool permissions and scoring rules consistent across conditions.

Measure reliance on stale evidence, justified task completion, unnecessary escalation, revalidation cost and delay. A policy that refuses every task might avoid stale-evidence actions while providing little useful work. Report denominators and failed source checks, preserve disagreements with the scoring rubric and keep development cases separate from held-out evaluation cases.

This comparison has not been run for this article. It sets out a testable hypothesis: source-aware revalidation may improve the balance between useful completion and inappropriate reliance on old information. A result would need measured evidence before that hypothesis could become a performance claim.

Preserve explanations without keeping everything forever

An action log should identify the evidence version considered and why it was accepted or rejected. Retention should still be bounded by purpose, access controls and applicable obligations. Working-memory expiry does not require erasing a published research archive, and an audit objective does not justify retaining unrelated personal information.

The engineering aim is selective, explainable use of knowledge. Before an agent acts on a memory, it should be possible to explain what that memory says, where it came from, when it was checked and why it applies now.

What the published restart pilot adds

The original article appeared on 5 October 2026, before the restart pilot was published on 9 October. That pilot compared current evidence alone, conversation history, structured memory and source-checked memory on 48 synthetic evaluation cases, with three repeats in each condition. It did not compare the three expiry policies proposed in this article.

All 576 scheduled evaluation responses failed the strict output contract. A separately declared diagnostic removed one outer Markdown fence and then applied the original schema and scoring rules. In that diagnostic, structured memory produced 144 correct decisions out of 144, while source-checked memory produced 138 out of 144. This does not support claiming that source checking improved decision accuracy on the tested corpus. The diagnostic must not replace the unsuccessful strict primary endpoint.

The practical implication is a research priority: evaluate the machine interface, evidence applicability and decision policy separately. A useful-looking memory design can still fail the receiving system, and deterministic filtering can change what information the model sees. This is an interpretation of the published evidence, not a newly measured deployment outcome.

Sources: [4]

A sharper next test for memory expiry

Freeze the output contract and its acceptance rules before a new held-out comparison. Give each expiry condition the same current facts and permissions. Keep development cases separate; include expired authority, unavailable evidence, a replacement source and a prior action whose outcome is unknown. Any additional control for context length should be declared before examining evaluation results.

Report strict interface validity, policy correctness, stale-evidence actions, useful authorised continuation, unnecessary escalation and resource cost as separate outcomes. Count missing and malformed responses in scheduled denominators. Review explanations as well as labels: the decision pilot found an unsupported policy exception in a response with a correct ASK label.

The success criterion is a better measured balance of useful action and appropriate restraint, not a predetermined positive result. New results require an executed, versioned experiment; this revision supplies no additional model responses.

Sources: [4] [5]

Version history

Original publication dates are retained. Article revisions do not replace the underlying study reports or their archived evidence.

Version 1.0 / 5 Oct 2026
Original engineering article and proposed experiment.
Version 1.1 / 17 Oct 2026
Added interpretation of the published October pilots and a more explicit follow-up evaluation plan. This is an editorial synthesis, not a new model run. Original publication date and underlying study results are unchanged.

Sources and evidence scope

W3C, PROV-Overview (Working Group Note, 2013)
Background on provenance entities, activities and agents; not validation of the proposed memory policy.
IETF, RFC 9111: HTTP Caching (2022), sections 4.2 and 4.3
Freshness and validation as an explicitly limited engineering analogy, not an AI memory standard.
Mohanad Osama Zahran, JARVIS & System Brain, edition 1.3 (2026)
The lab’s role, memory and authority architecture; the proposed expiry evaluation is separate.
Mohanad Osama Zahran, After the Restart, report 1.0 / evidence 1.0.1 (9 October 2026)
Published synthetic computational pilot. Primary strict output validation failed for all 576 evaluation responses; fence-only secondary analysis is separate. No physical survival or general memory-benefit result.
Mohanad Osama Zahran, Decide, Ask for Help, or Stop?, edition 1.0 (7 October 2026)
Published synthetic recommendation pilot; correct labels did not establish faithful explanations or execution of real actions.

Authorship and preparation

Research direction and author: Mohanad Osama Zahran. This article was prepared with AI assistance from the cited primary sources and ZEISMO research materials. Examples and proposed tests are identified by their scope. No customer records or new live-model results are included. Edition 1.1 was prepared with AI assistance from the existing public pilot records. No new customer data, model calls or experimental outcomes were added.

Published 5 Oct 2026. Internal editorial checks covered source attribution, scope, consistency with existing research and obvious sensitive information. These checks do not establish the outcomes of the proposed experiments.

Suggested citation

Mohanad Osama Zahran (2026). When Should an AI Agent Forget? Expiring Memory Before It Becomes a Bad Decision. ZEISMO Research & Lab, version 1.1.

Continue reading

More publications by Mohanad Osama Zahran