Long-term memory: episodic, semantic, procedural

Why it matters

Short-term memory ends with the session. The next morning the agent does not know that the user prefers terse answers, that the deploy failed last week for a reason it found, or that the billing API only accepts ISO dates with a timezone. Long-term memory is what carries across sessions, and it is not one thing. Borrowing the split from human memory gives three kinds with different write paths, read paths and risks, and interviewers use it to see whether a candidate has thought past "store the chat history in a vector database".

The idea

Three kinds

Episodic memory is what happened: past sessions, what was tried, what the outcome was, when. "On 4 November the migration against the staging database failed on a foreign key; reordering the steps fixed it." It is a log of events with timestamps and outcomes.

Semantic memory is facts, stripped of the episode they came from: about the user (role, timezone, preferred language), the domain (the product has three pricing tiers), the environment (the test suite takes eleven minutes). It answers "what is true", not "what happened".

Procedural memory is how to do things: learned preferences ("run the linter before proposing a diff"), tool sequences that worked (resolve the person first, then the calendar), and instructions the agent wrote for itself after a failure. In practice it is a growing file of rules read before acting, which is why the model seems to learn when nothing in its weights has changed.

How each is written

Two write paths. An explicit tool call lets the model save a memory mid-task. It is precise and visible in the trace; it also depends on the model noticing that something is worth keeping, which it often does not. A background extraction job runs after the session: a separate model call reads the transcript and emits candidate memories. It catches what the agent missed, costs one call per session rather than per turn, and lets a review step sit between extraction and persistence. The agent itself should write procedural memories, because the lesson is clearest at the moment of failure; episodic memories are extracted, since a session's shape is only known at its end; semantic facts come from both.

{"kind": "semantic", "subject": "user", "text": "Prefers diffs over full-file rewrites",
 "confidence": 0.8, "source": "session 2026-11-12", "scope": "user:4821"}

How each is read back

Nothing in long-term memory reaches the model unless it is placed in the window, so reading is retrieval. Procedural memory is small and always relevant, so it loads whole into the system prompt as a standing block of rules. Semantic facts are looked up by subject at session start and by relevance per turn. Episodic memory is searched when the current task resembles a past one: the query is the task description, the result the two or three most similar past episodes and their outcomes. Each kind has its own query shape; the Memory stores and recall lesson covers the stores and the ranking.

Size and freshness

Memories accumulate. A user with two hundred sessions behind them has thousands of candidate facts, many now false: the timezone changed, the preference was a one-off. Every memory therefore carries a timestamp, a source and a confidence, and the read path favours recent, repeatedly confirmed facts over old single observations. The Forgetting lesson handles revision and expiry; the decision now is to record enough that forgetting is possible later.

Privacy

A memory about a user is personal data. It is scoped to that user and never recalled for another, which sounds obvious until a shared vector index with a missing filter leaks one customer's facts into another's session. Users should be able to see what is remembered and delete it, and some things are never stored: credentials, health details mentioned in passing, anything the user would not expect to persist. That filter belongs in the extraction job, before anything is written.