Episodic Memory — Patterns

Outcome recorded as a closing act

Problem. Episodes are written when something starts or when something interesting happens, and the result arrives later — after a retry, after a human approval, after an asynchronous callback. The store fills with openings that have no endings, and the question episodes exist to answer cannot be asked.

Approach. Treat the episode as an object with a required terminal state and make closing it an explicit act with its own code path: succeeded, failed with a classified reason, abandoned, or superseded by another attempt. Anything still open past a bound is closed by a sweeper as unknown, so the absence of an outcome is itself recorded rather than represented as silence. Query paths that answer "has this worked before" consider only closed episodes.

Trade-off. Closing is a second write on a path that already succeeded, so it is the write most likely to be skipped under load or lost in a crash, and a sweeper that closes too eagerly manufactures false failures. The classified reason also needs a maintained vocabulary, which drifts as the environment changes.

Event time and record time kept separate

Problem. When a single timestamp field means "when this was stored", any import, replay, or delayed write collapses the past into the moment of ingestion. Recency ranking then promotes material that is not recent, and the order of events becomes the order they were processed in.

Approach. Carry both clocks on every episode, with the occurrence time supplied by whatever observed the event and the record time supplied by the store. Rank and filter on occurrence time; use record time for auditing, debugging ingestion lag, and detecting clock problems. Flag episodes whose occurrence time is implausible relative to their record time rather than silently accepting them.

Trade-off. Two clocks mean two chances to be wrong, and an upstream with a skewed clock now injects wrong occurrence times that look authoritative. Out-of-order arrival also becomes something every consumer must handle, including the ones that only ever wanted the latest.

Annotate, never amend

Problem. Episodes turn out to have been misrecorded, misclassified, or based on a tool that was returning wrong data. The tempting fix is to correct the record, which destroys the evidence of what the system actually observed at the time.

Approach. Make episodes immutable after close and express every later judgement as a separate annotation that references the episode: disputed, superseded, reclassified, known to have been produced during a faulty window. Retrieval applies annotations as filters or as qualifiers attached to the returned episode. The original remains available to anyone reconstructing the agent's state of knowledge at a past moment.

Trade-off. Every reader must now understand annotations or risk acting on a record that is known to be wrong, and a reader that ignores them is worse off than if the record had simply been corrected. Annotations also accumulate independently and need their own retention rule.

Reference the payload, store the narrative

Problem. The useful part of an episode is a short description of what was attempted and what resulted. The bulk is the raw tool output, which may be megabytes, may contain credentials and personal data, and is almost never read.

Approach. Split the episode into a small narrative record — what, when, who, outcome, classified reason — and a payload stored separately under a handle, with its own retention and its own access rules. The narrative is what is indexed, retrieved, and shown to the model; the payload is fetched deliberately when someone is reproducing a specific incident. Retention can then be short for payloads and long for narratives, which is almost always the right shape.

Trade-off. The narrative is a summary written at capture time without knowing what a future investigation will need, and once the payload expires the missing detail is unrecoverable. Two retention clocks also mean the system can be in a state where an episode exists and its evidence does not, which must be visible rather than look like a storage error.