Agent Memory Needs a Right to Correct and Forget

Part 5 of the AI Agents in the Real World series.

An assistant remembers that you are vegetarian. Helpful.

It remembers that you were searching for oncology clinics for a relative. Sensitive.

It infers that you have cancer. False.

It continues using that inference after you delete the original conversation. Persistent.

It shares the conclusion with a travel, insurance, or workplace workflow because all of them use the same profile. Harmful.

“Memory” makes these cases sound like one feature. They are five different data operations: capture, inference, storage, retrieval, and disclosure.

An agent that remembers needs more than a larger context window. It needs a governed lifecycle and a person who can see, correct, scope, and remove what the system carries forward.

Contract review, October 16, 2026: the original publication date remains. This revision updates the product-control example from the current official documentation, corrects the legal-source link, and makes current owned lifecycle checks and honest deletion evidence explicit. It is an engineering design, not a legal determination, deployed erasure service or conformance certificate.

A useful memory can still be an inappropriate memory

Memory quality is not only factual accuracy.

Ask six questions:

1. True: Is the memory supported by evidence?
2. About the right subject: Was a fact about a relative assigned to the user?
3. Appropriate: Should this category be remembered at all?
4. Current: Is it still valid?
5. Scoped: Which agents, tasks, and people may use it?
6. Controllable: Can the affected person inspect, correct, and delete it?

A stale home address can be true historically and wrong for shipping. A medical detail can be accurate and irrelevant to travel. A project decision can be valid for one repository and dangerous as an organization-wide rule.

The core error is treating successful retrieval as justified use.

Consumer memory already reveals the systems problem

OpenAI’s current Memory documentation, checked October 16, distinguishes remembered information from its sources. Depending on the available experience, removing information can involve saved memories or a summary, chats, Library files and connected apps. Deleting a chat alone does not necessarily remove a separate saved memory; disconnecting an app stops future access without deleting prior chats. Controls vary by plan, region, platform and workspace, and updates can take time to propagate.

Those controls continue to evolve and apply to one product. The broader lesson is durable: users think in conversations, while systems store memory across multiple layers.

An enterprise agent can have even more layers:

• raw conversation or event log,
• extracted profile facts,
• vector embeddings,
• summaries,
• episodic run records,
• learned procedures,
• caches and replicas,
• analytics and evaluation datasets,
• downstream copies in tickets, documents, or messages.

A delete button that clears one layer is not a memory lifecycle.

In jurisdictions where the GDPR applies, Article 16 and Article 17 provide rights to rectification and, under defined grounds and exceptions, erasure of personal data. This article is not legal advice, and not every memory is personal data governed by the same law. The engineering implication is still important: correction and erasure cannot be bolted onto a store that has no provenance or copy map.

Memory also creates a security boundary

A retrieved memory arrives looking like the agent’s own prior experience. That can make it more trusted than external content.

The MINJA research demonstrates a query-only attack that injects malicious records into an agent memory bank through ordinary interaction. MemoryGraft demonstrates poisoned “successful experiences” that later resurface for semantically similar tasks and induce persistent behavioral drift.

These are research demonstrations, not measurements of every deployed memory product. They expose two design mistakes:

• untrusted interaction is promoted into durable memory without review,
• retrieved experience is treated as procedural authority rather than evidence.

The usual “learn from every interaction” product promise makes both mistakes sound like features.

Separate five memory classes

Different memory classes need different controls.

Do not put all five into one vector index and call the result memory.

The most consequential separation is between episodic evidence and procedural authority. A run that happened is not automatically an example to imitate. A human correction is not automatically an organization-wide policy. A successful outcome does not prove the path was compliant.

The memory ledger

Every promotable memory should carry a record that makes future use explainable and removable.

memory_id: mem_7812
class: profile
subject: user_1842
statement: "Prefers vegetarian meal options"
 
provenance:
  source_type: explicit_user_instruction
  source_id: conversation_991_turn_14
  observed_at: "2026-08-20T12:10:00+05:30"
 
governance:
  purpose: travel_and_dining_recommendations
  sensitivity: personal_preference
  allowed_scopes: ["travel", "dining"]
  prohibited_scopes: ["employment", "insurance"]
  confidence: 1.0
  expires_at: "2027-08-20T12:10:00+05:30"
  promotion_status: user_confirmed
 
supersession:
  replaces: null
  replaced_by: null
 
deletion:
  status: active
  replicas: ["profile_store", "retrieval_index"]
  tombstone_id: null

The schema is illustrative. The non-negotiable idea is that a memory is not just text plus an embedding. It is a governed claim with a subject, source, purpose, scope, lifecycle, and copy map.

Capture eligible data, promote narrowly

A production memory lifecycle should have explicit transitions:

event captured
  -> candidate extracted
  -> sensitivity and subject classified
  -> evidence checked
  -> promotion approved
  -> scope and expiry assigned
  -> recalled with provenance
  -> corrected, superseded, expired, or deleted

Capture is not promotion

Keep an immutable run receipt when audit requires it, with appropriate retention and access controls. Do not make every receipt eligible for semantic recall.

Collect only authorized necessary content. Candidate workspaces need owner/tenant/namespace, subject, purpose, actual reader/processor and retention controls before review. An immutable audit design cannot justify indefinite retention of raw personal data; exceptions need a current declared basis and accountable review. Recalled content remains evidence, never new authority.

Promotion is a decision

Promotion should depend on memory class:

• A personal preference can require explicit user confirmation.
• A business fact can require an authoritative source and freshness rule.
• A procedure can require an owner, evaluation, version, and rollout.
• A security-sensitive fact may be prohibited from agent memory entirely.

Recall should show its work

When a memory materially changes an answer or action, the interface should expose:

• what was remembered,
• where it came from,
• when it was recorded,
• why it was considered relevant,
• how to correct or stop using it.

“Because I know you” is not an explanation.

Give people four distinct controls

See

Users and administrators should be able to inspect active memories by subject, source, category, scope, and last use. A chat transcript is not a sufficient memory console.

Correct

A correction should create a new version, mark the previous memory superseded, and prevent old replicas from continuing to rank. Preserve the history only where policy permits and restrict it from ordinary recall.

Forget

Forgetting should propagate to every retrieval surface. Use a deletion job with acknowledgements from primary store, indexes, caches, and derived profiles. Where a retained audit record is legally or operationally required, separate retention from recall and explain the exception.

Limit

Let the person say “remember this only for travel,” “do not infer health information,” or “use this until the project ends.” Scope and expiry are often better than the false choice between remember forever and forget completely.

Deletion needs a propagation protocol

An enterprise deletion request should create an inspectable workflow:

deletion_request_id: delmem_204
subject: user_1842
memory_ids: [mem_7812]
requested_at: "2026-09-01T10:05:00+05:30"
reason: user_request
 
targets:
  profile_store: confirmed
  retrieval_index: confirmed
  semantic_cache: pending
  evaluation_corpus: not_present
  audit_archive: retained_restricted
  derived_exports: external_unknown
 
recall_block_tombstone: active
status: pending
completed_at: null
exceptions:
  - target: audit_archive
    basis: regulated_retention
    recall_allowed: false

The tombstone matters in eventually consistent systems. Without it, a stale replica can repopulate a deleted memory during synchronization.

This is a local product projection, not the canonical lifecycle record or proof of receipt verification. The example is intentionally incomplete: cache propagation is pending, exports are externally unknown, and an audit exception remains. Bind each actual copy’s receipt to the record digest, operation, artifact and current observation, using a complete verified inventory. A caller’s confirmed label or not_present claim cannot authenticate itself. Keep failed, pending and external-unknown states visible; a tombstone blocks recall but cannot prove every copy was erased. An exception requires the declared escalation/review path rather than an unqualified “forgotten everywhere” message.

The execution contract supplies owned MemoryLifecycleRecord / MemoryLifecycleContext checks with trusted provenance, readers, retention, reviews and propagation observations. It does not supply a storage backend, legal adjudication or erasure service. Stable operation identity, current authority/fencing and original shared accounting remain in force across jobs, retries, children and resume. Expiry prohibits ineligible recall; appropriately authorized cleanup can still proceed.

Never learn policy directly from outcomes

Suppose an agent issues a refund, the customer is satisfied, and nobody complains. Was the procedure good?

Not necessarily. The refund may have violated a limit, relied on stale evidence, or succeeded only because a human repaired the record later.

Before turning a run into procedural memory:

1. Verify the outcome.
2. Verify policy compliance.
3. Inspect side effects and human repairs.
4. Determine which step caused success.
5. Test the candidate rule on representative and adversarial cases.
6. Assign an owner and version.
7. Roll it out gradually with rollback.

ContextOS treats corrections as proposals for a governed improvement loop, not invisible self-modification.

Personal memory checklist

• Ask the product what it remembers and inspect the memory view regularly.
• Use temporary or memory-off modes for sensitive, one-time tasks.
• Do not assume deleting a conversation deletes extracted memories.
• Correct the subject as well as the fact: “that diagnosis was about my relative, not me.”
• Avoid storing passwords, financial secrets, recovery codes, or confidential employer data as memory.
• Separate personal and work accounts and connected sources.
• After a deletion, inspect documented retention/propagation status; a new-session recall check alone cannot prove backend erasure.

Enterprise memory checklist

• Inventory every store, index, summary, cache, and derived profile.
• Assign memory classes and prohibit sensitive categories by default.
• Keep tenant, subject, and purpose boundaries in the retrieval key.
• Require provenance and promotion status for recall.
• Separate event retention from future behavioral influence.
• Provide correction, supersession, expiry, and deletion propagation.
• Red-team query-only poisoning and cross-user memory leakage.
• Do not allow recalled content to grant authority or override current policy.
• Version procedural memory like code and evaluate it before release.

The deeper architecture is documented in Memory and Memory Fabric. AI Agent Memory Is Broken covers the broader multi-layer design.

Evaluate useful correction/recall and authorized cleanup alongside denied cross-owner access, stale reviews and incomplete propagation. Required controls need current independently verified evidence for the workflow, implementation, release and environment under Conformance. A privacy console, memory-off setting, successful reference check or deletion-request receipt does not establish all those runtime controls.

What to measure

Retrieval precision does not cover these questions. A system can retrieve exactly the wrong memory with excellent similarity.

Memory is a promise, not a convenience

When a product says it remembers, it makes two promises:

1. the right information will be available when useful;
2. the person retains meaningful control over what persists and where it matters.

Most memory designs optimize only the first promise.

Agents that act on remembered information make the second one more important. A false memory can change a recommendation. A sensitive memory can change a disclosure. A poisoned memory can change a procedure. A memory that cannot be fully corrected can outlive the person’s ability to contest it.

The right to correct and forget is therefore not a settings-page nicety. It is part of the agent’s decision architecture.

What to read next

• The AI Agent Exception Economy: Why the Long Tail Decides ROI
• AI Agent Memory Is Broken
• Persistent Memory Poisoning
• Memory