Correct a memory without losing the record

The scenario

The system learned that Priya owns the billing service. Priya moved teams in August. Every answer since has been confidently wrong, and the customer-facing agent has been routing escalations to someone who left. Deleting the memory fixes today’s answer and destroys the record. Six months from now nobody can explain why the agent said what it said in July — and for a regulated workload, “we deleted it” is the wrong answer to an auditor.

Step 1 — Supersede it, with the reason

client.update_memory(
    space_id="platform",
    memory_id=memory_id,
    state="invalidated",
    reason="Priya moved to the data team on 2026-08-01; Marcus now owns billing.",
)

state="invalidated" takes it out of retrieval without removing it. The reason is stored alongside, so the correction is self-documenting rather than a mysterious gap.

Step 2 — Record what is true now

client.record(
    space_id="platform",
    content="Marcus owns the billing service and is on call for it.",
    timestamp="2026-08-01T00:00:00Z",
)

Give it the date the change happened, not today. That is what makes “who owned billing in July?” answerable later.

Step 3 — Read the history

history = client.get_memory_history(space_id="platform", memory_id=memory_id)
for entry in history["history"]:
    print(entry["changed_at"], "|", entry["reason"], "|", entry["previous_content"][:80])

This is the audit trail. Not “the value changed” but what it was, when it changed, and why somebody changed it.

Step 4 — Fix a detail without invalidating

For a wrong date or a typo, correct the field rather than superseding the whole memory:

client.update_memory(
    space_id="platform",
    memory_id=memory_id,
    occurred_start="2026-08-01T00:00:00Z",
    reason="Recorded with the wrong start date.",
)

Evals

Record a fact, retrieve it, confirm it comes back.
Invalidate it with a reason. Retrieve again — it must not come back.
Read the history and confirm the old content and the reason are both intact.
Ask a question that the superseded fact would have answered. Check the answer now reflects the replacement rather than sitting between the two.

Guardrails

Invalidating is not deleting, and for a data-subject request you need deleting. An invalidated memory is still stored and still readable through its history. If someone has asked you to erase their data, follow the deletion runbook instead.

Always pass a reason. A correction with no reason is indistinguishable six months later from a mistake, and it is the field an auditor reads first.
Correcting is owner-only. A read-only member of a shared space cannot invalidate, by design.
Do not fix a wrong fact by recording a right one and leaving both. Retrieval will happily return the pair, and the model will average them.

Built from

Both are complete, runnable scripts: memory_basics.py, time_travel.py. The full field list is on Memories.

Getting Started

API Essentials

Memory (data plane)

LLM Proxy (drop-in)

Account (control plane)

SDKs & MCP

Integrations

Guides

Use Cases

Changelog

Correct a memory without losing the record

The scenario

Step 1 — Supersede it, with the reason

Step 2 — Record what is true now

Step 3 — Read the history

Step 4 — Fix a detail without invalidating

Evals

Guardrails

Built from

​The scenario

​Step 1 — Supersede it, with the reason

​Step 2 — Record what is true now

​Step 3 — Read the history

​Step 4 — Fix a detail without invalidating

​Evals

​Guardrails

​Built from

The scenario

Step 1 — Supersede it, with the reason

Step 2 — Record what is true now

Step 3 — Read the history

Step 4 — Fix a detail without invalidating

Evals

Guardrails

Built from