Episodic Memory

What it is

Records of particular occasions: what happened, when, in what order, involving whom, and how it turned out. An episode keeps its circumstances — the reconciliation run on 3 March that failed at step four because the exchange-rate service timed out — rather than the general proposition that the service is unreliable. Episodes are addressed by time, by actor, and by outcome, and they accumulate for as long as the agent operates.

Why it is not semantic memory

A standing belief has shed its occasion: "this customer bills quarterly" is asserted without reference to when or how it was learned. An episode is the opposite — remove the occasion and nothing is left. The difference shows up in how each is handled. A belief is queried by subject and is superseded when it stops being true; an episode is queried by time or outcome and is never corrected, because what happened happened. Judging an episode to have been a mistake adds an annotation to it; it does not change the record.

Why it matters

An agent that repeats a failure does so because nothing recorded the last one. Episodes are what make "the last two attempts at this migration timed out on the same table" available at the moment of the third attempt, and what lets a human reconstruct why the agent behaved as it did on a particular day rather than in general. They are also the raw material everything else is derived from: beliefs and routines that are not grounded in episodes are grounded in nothing.

Key decisions

• The granularity of an episode — one tool call, one task, one session. Too fine and retrieval drowns in fragments; too coarse and the outcome cannot be attributed to the step that caused it.
• Whether an outcome is recorded at all, and how it is determined. Episodes without outcomes cannot answer "has this worked before", which is most of what they are for.
• Which clock the record uses: when the event occurred, and separately when it was written. Conflating them makes any backfill look like a burst of activity on one afternoon.
• Retention, given that episodes grow linearly with usage and never stop. Either they expire, or they are consolidated into derived statements, or storage and retrieval both degrade.
• What is captured inside an episode. Full tool payloads make it reproducible and make the episodic store the largest uncontrolled copy of credentials and personal data in the system.
• Whether failed and abandoned episodes are recorded as readily as successful ones, since the asymmetry is the default and it is the wrong one.

Failure modes

• Only successes are written, so the memory of a recurring failure never exists and the same broken path is retried every month.
• Granularity is the whole session, so "it failed" is retrievable and "it failed at the authentication step" is not.
• Retrieval is driven by recency alone, and the single relevant episode from six months ago is never surfaced while twenty irrelevant recent ones are.
• Episodes are timestamped at ingestion rather than at occurrence, and a replay of historical data compresses a year into one hour of apparent events.
• A single episode is treated as a general rule — one timeout becomes "that service is down" — because nothing in the retrieval path distinguishes an occasion from a belief.
• Episode text embeds identifiers, tokens, and customer data copied verbatim from tool results, and the store inherits a classification nobody assigned to it.
• Episodes are mutated when a later review finds them wrong, so the record of what the system observed is quietly replaced by the record of what it now thinks.

Related capabilities

• Semantic Memory — the standing beliefs that episodes are evidence for
• Memory Consolidation — what turns many episodes into fewer derived statements
• Memory Expiration and TTL — the only thing that bounds linear growth
• Memory Provenance — the link from a derived claim back to the occasion behind it
• Conversation Memory — the dialogue record, as distinct from the recorded occasion

Applies: Production readiness · Design questions