Personal AI Memory: Store, Inspect, Correct, Export and Delete

Image: Daniel Forsman on Unsplash.

Useful AI memory is a data lifecycle you control: every remembered fact has a source and a scope, you can see it, correct it and export it, and deletion tells you exactly what it does and does not reach. Memory you cannot inspect is a liability that happens to be convenient.

Here is the failure this guide is built around.

Months ago you mentioned you prefer morning meetings.

You changed jobs. Now you prefer afternoons.

The assistant keeps booking mornings, politely, forever.

The fix is not a smarter model. It is memory you can see and change. This guide is part of the AI harness engineering guide. For the research landscape, see AI agent memory explained.

Decide what should be remembered

"Memory" covers four different things. Give each its own store.

Kind	Example	Store it as	Lifetime
Task state	"Step 3 of 5 done, draft awaiting approval"	Checkpoint	Until the task ends
Preference	"Prefers afternoon meetings"	Memory record	Until corrected
Fact	"Sam owns Project Alpha"	Memory record with a source	Until superseded
Document	The project plan itself	Original file, retrieved when needed	As long as the file exists

Documents should not be copied into memory. Retrieve them from the source so a change to the file is reflected. The RAG vs memory vs context guide covers that split in depth.

Then decide what should never become memory at all:

passwords, keys and recovery codes,
one-off instructions such as "just this once,"
other people's sensitive details mentioned in passing,
anything you would not want read back to you in a year.

Default to not remembering. Saving something should be a deliberate act, by you or by a rule you can read.

Design a memory record you can inspect

A record needs enough structure to answer "where did this come from, and is it still true?"

{
  "id": "mem_0142",
  "kind": "preference",
  "value": "Prefers meetings after 13:00 local time",
  "scope": "scheduling",
  "source": { "type": "user_statement", "ref": "conversation 2026-10-02", "quote": "afternoons work better now" },
  "created": "2026-10-02",
  "status": "active",
  "supersedes": "mem_0087"
}

Each field earns its place:

• source lets you check the fact against what was actually said or written.
• scope keeps a scheduling preference out of an unrelated writing task.
• status distinguishes active, superseded and deleted records.
• supersedes keeps history without letting old facts win.

Store these as readable files or a simple database you can query. If you cannot list your assistant's memories in under a minute, the design is too opaque.

Control how memories are written and retrieved

Writing. Separate what you said from what the assistant inferred. "You told me you prefer afternoons" and "you seem to prefer afternoons" deserve different weights. Many people let the assistant propose memories and approve them, at least at first.

Retrieving. Load only records whose scope matches the task. Explicit corrections outrank inferences. Newer records outrank the ones they supersede. If two active records conflict, surface the conflict instead of picking one silently.

Separating profiles. If the assistant serves more than one person or role, keep their memories in separate stores and test that one never retrieves the other's records.

Correct a wrong memory and prove the change

Correction is the operation that matters most, and the one most systems get wrong. A correction is only real if the next answer changes.

1. Find the record and its source.
2. Write a new record that supersedes it, with your correction as the source.
3. Mark the old record superseded. Keep it for history; never retrieve it as active.
4. Rerun the task that failed. Book a test meeting and confirm the afternoon slot.
5. Check caches and indexes. If memories are embedded for search, re-index the changed record. A stale embedding of the old record can resurface it.

Add that rerun to your test suite. Memory bugs come back when indexing or caching changes.

Export and import without losing meaning

Export memory in a format a person and another program can read: JSON or CSV with the schema documented. Include IDs, sources, scopes, status and dates. A list of bare sentences loses the information that makes memory trustworthy.

Test the round trip: export, import into a clean store, compare record counts and content, then rerun a few questions that depend on memory. An export you have never imported is a hope. The provider exit test uses this as one of its steps.

Delete memory, and explain the limits

Deletion should remove the record from active use immediately. Then be honest about what it does not reach:

Location	Removed by deleting the record?
Active memory store	Yes
Search index or embeddings	Only if re-indexed; make this automatic
Caches	Only if invalidated
Your backups	Not until those backups age out or are rewritten
Logs that captured the text	Not unless logs are redacted or expire
A cloud model provider	No. Data already sent is governed by that provider's retention policy

On that last row, check the actual policy. OpenAI's API documentation, for example, says abuse-monitoring logs may be retained for up to 30 days, with stated exceptions (OpenAI). Local deletion cannot reach that.

Show these limits in the interface. "Deleted from memory. Copies in backups older than today remain until they expire" is more trustworthy than a reassuring tick.

Maintain memory over time

Facts age. Build a habit around it:

• review memories with no recent use,
• flag records whose source document has changed,
• surface conflicts for you to resolve,
• expire task state when tasks finish.

Not everything needs to persist. If a question can be answered from the source document every time, retrieval is enough and memory is just a second copy to keep in sync.

A small lifecycle test suite

Before trusting memory, run these:

1. A stated preference is saved with its source.
2. A correction changes the next answer.
3. A superseded record is never retrieved as active.
4. A deleted record does not appear in search results.
5. Two profiles never see each other's memories.
6. Export then import preserves count, content and sources.

Each takes minutes to write. Together they catch most of the ways memory quietly goes wrong. The evaluation guide shows how to fold them into a full suite.

Frequently asked questions

Is chat history the same as memory?

No. History is a transcript. Memory is a curated set of records chosen to persist, each with a source and scope.

Can I see what my assistant remembers?

You should be able to. If a product cannot list its memories with sources, treat its memory as opaque.

How do I fix a memory the assistant keeps repeating?

Supersede the record with a correction, re-index it, invalidate caches and rerun the task to confirm the answer changed.

Does deleting local memory erase provider logs and backups?

No. It removes the record from active use. Backups, logs and data already sent to a provider follow their own retention rules.