When should an AI agent save, correct, or delete long-term memory?

A writing assistant can carry a preference into tomorrow’s session. That convenience creates a new obligation: the preference may be wrong, temporary, inferred from someone else’s words, or later withdrawn. A useful memory system therefore needs rules for admission, retrieval, correction, expiry, and deletion, not just a database that can save chat summaries.

The context map shows what enters one model call. Conversation compaction preserves the state of a running task when its history grows. Long-term memory is a different decision: a record is deliberately available across sessions, often under a user or organization scope. LangGraph, for example, distinguishes thread-scoped history from long-term records stored in a separate namespace. Neither a compacted transcript nor an old chat should silently become a permanent user profile.

Decide whether a candidate deserves a future read

Ask what later task would improve, who the memory describes, and when it will stop being reliable. Route each candidate before writing it:

Candidate	Default route	Reason
A clearly stated, future-facing preference the person asks to remember	Confirm its scope, then consider a bounded record	It can save repeated instruction without pretending to be a fact about every task
A detail needed only for this order or conversation	Keep in session or task state	A one-time condition is not a lasting preference
A model inference, a retrieved page’s claim, or a third party’s description	Do not persist as a user fact	The speaker and certainty do not support that promotion
A sensitive detail or a credential	Exclude from optional memory by default	A possible convenience does not justify a lasting copy

This is a product decision as well as a privacy review. Optional personalization can require an explicit opt-in in your product; a team must still determine the applicable legal basis and retention duties for its jurisdiction. Do not treat every statement in a conversation as consent to save it for future sessions. Google Cloud’s memory generation documentation expressly warns that its sensitive-information filtering is not infallible; an application needs its own admission controls.

Give each memory a lifecycle contract

Store a narrow assertion, not a full transcript. A record should identify its subject and tenant, purpose, exact scope, source and observation time, how the person confirmed it, sensitivity class, owner, expiry or review event, and current status. Keep a pointer to the authorized source when one exists, but do not copy the source merely to make the memory look well evidenced.

Useful statuses are proposed, active, contested, superseded, deletion pending, and deleted. Only an active, unexpired record inside the current subject, tenant, and purpose may enter a later request. Check those conditions before retrieval or prompt assembly. A memory such as “prefers short answers” is personalization data; it cannot grant permission to send a message, open a private document, or bypass an approval gate.

Time to live is a backstop, not proof that a claim stays true until that date. Tie review to an event when possible: a project closes, a role changes, a new statement conflicts, or the person asks what is remembered. A record without an owner or a removal path should not be promoted to long-term storage.

Correct conflicts without flattening their scope

When a new statement differs, first ask whether it applies to this task, one project, or future sessions generally. A temporary exception can coexist with a global preference. An explicit, future-facing correction should replace the old active value for that same key and scope; link the old and new record IDs, mark the old one superseded, and rebuild any search material that might still retrieve it. Two ambiguous claims should make the record contested and unavailable until clarified.

Do not let recency alone decide. A newer tool result may be less authoritative than the person’s earlier confirmed preference, and a model-generated summary may have lost a negation. Present the competing source, scope, and date to a reviewer or the person. If the record affects a consequential decision, the underlying system of record remains the authority.

Treat deletion as a multi-surface operation

On a valid forget request, stop returning the memory immediately, then trace every place it could be reproduced: the active store, semantic index, cached prompt or result, replicated store, export, revision history, logs, and backup. Record what was deleted now, what is retained under a separate rule, who owns that retention, and when the remaining copy becomes unavailable. Tell the requester the actual state rather than saying “gone everywhere” after one API call.

This distinction is concrete. Google Cloud Memory Bank documents that deleting the current Memory resource can leave earlier facts in child MemoryRevision resources until their own expiry. Its current-resource lookup may return 404 while revisions still exist. Other products have different retention behavior, so inspect the service actually used. UK ICO guidance also describes conditional rights to correction and erasure, recipient notification, and backup handling; it is jurisdiction-specific guidance, not a universal promise that every copy can be removed instantly.

Verification needs a fresh session and the same identity scope: list or query the active store, search for distinctive synthetic markers, inspect revision and export behavior under the applicable policy, and confirm that the agent no longer uses the withdrawn value. Include a backup-restore scenario where relevant, so a restored copy cannot quietly reactivate a deleted memory. Keep an audit receipt with request ID, systems checked, owner, time, and exceptions, without retaining the forgotten sensitive value in that receipt.

Example 1: A writing preference changes without becoming a false global rule

A writer explicitly asks an assistant to remember: “For future internal briefs, use concise Chinese bullet points.” The product asks for confirmation of that scope and stores a short active preference with an expiry review date. Next week the same person requests a formal English letter for one client. That instruction belongs to the letter, not to the long-term preference; nothing is overwritten.

Later the writer says: “For all future internal briefs, use Chinese paragraphs, not bullets.” This is a durable correction at the same scope. The old bullet-point record becomes superseded, the new record links to it, and the retrieval index is refreshed. A test in a new session asks for an internal brief and expects paragraphs. A second test asks for the client letter and still respects that task’s English requirement. If both old and new values appear, the update is incomplete.

Example 2: An inferred health detail must stop following a traveler

During one trip-planning chat, a traveler asks for a low-sugar dessert at a single restaurant. An extraction step incorrectly stores “traveler has diabetes” as a persistent fact. That claim was never made by the traveler, and it concerns sensitive health information. The application disables the record for retrieval as soon as the problem is reported, reviews whether the inference reached other sessions, and does not ask the model to decide whether the diagnosis was “probably right.”

The traveler requests deletion. The owner traces the memory ID through the active store, search index, response cache, revisions, exports, and applicable logs and backups. A new-session test must not personalize the itinerary using the inferred condition; a separate query of the memory store must not return it. If a revision or backup remains temporarily under a documented retention rule, the team records its access restriction and end date and reports that limitation accurately. It never copies the health claim into the deletion receipt.

Test the contract before enabling writes

Use synthetic records and run four probes: a one-off request stays session-only; an explicit durable correction defeats the old value in a fresh session; a different tenant cannot retrieve it; and a deleted record cannot reappear through search, cache, or restore. Record both the agent’s answer and the underlying read result. A fluent answer can hide a stale memory that happens not to be mentioned.

Boundary

The worksheet below is a design aid and saves edits in this browser. Use invented labels and values; do not enter real health details, identifiers, credentials, or deletion requests. Production memory requires access controls, an approved retention schedule, user-facing correction and deletion routes, and jurisdiction-specific privacy review. A record that cannot be traced and removed is not ready to be written.