glossary//episodic-memory
episodic memory
Episodic memory is an agent's record of what happened and when, kept as short digests of past sessions and looked up by recency or keyword rather than by entity.
Two lookups separate the layers. Episodic memory answers time-based or keyword queries: what happened last Tuesday, what came up when the invoice was discussed. A memory graph, the semantic layer, answers entity queries: what is true about this person, this project, this deadline. Both layers often start from the same session, yet a durable fact must outlive its conversation, so the system extracts it and stores it separately.
Episodic memory is also not the raw log. The append-only ledger that records every turn serves a different purpose as the complete source of truth. Episodic memory sits one step above that ledger: compressed, recall-oriented, and built for scanning rather than auditing.
How the digests get built
Memory is easy, retrieval is hard shows the mechanism. Session Digests forms the episodic layer for recent sessions. At session close a background task sends all the turns to claude -p in summarization-only mode, parses the returned JSON, and stores a short narrative along with candidate facts, procedural notes, and key decisions.
Only a small block reaches the next prompt: an === EPISODIC MEMORY === header, a timestamp, and one line such as "Discussed Nutrifax invoice reconciliation. Decided to postpone Stripe migration until July." One line of narrative per session, not a transcript. So the compression keeps recall cheap even as the history grows.
Which things stay episodic
Structured memory graph workers draws the boundary from the opposite direction, through the promotion rules for the entity graph. A Person node requires two supporting facts before it is minted; a Project requires three. Deadline and Preference are never minted at all. Their thresholds are effectively infinite, because a deadline or a stated preference is an episodic thing, not a durable entity you want to consolidate.
Give the model the tools, not the context places episodic memory beside semantic and procedural memory as three query modes over one store, while noting that the write-time partitions are not clean. A single turn can drop a record into all three at once: an episodic note that the turn happened, a semantic update because the user named a new deadline, and a procedural note about how they want it handled.