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.

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 Memory FAQ explains that saved memories are stored separately from chat history: turning memory off does not delete what was already remembered, and deleting a chat does not remove saved memory from that conversation. Fully removing a saved memory may require deleting both the memory and the source chat.

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 broadly, 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.

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: deleted
  retrieval_index: deleted
  semantic_cache: deleted
  evaluation_corpus: not_present
  audit_archive: retained_restricted
 
recall_block_tombstone: active
completed_at: "2026-09-01T10:05:41+05:30"
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.

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, test with a new session and inspect the product’s documented retention behavior.

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.

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