Episodic Memory

Episodic memory is what the agent remembers about things that happened: a specific issue investigation, a specific debugging session, a specific pull-request follow-up. The key property — the thing that makes it episodic — is that it has a when.

The running example

Throughout this pillar we'll use one request to a coding agent, about a small league-management app:

"Pick up issue #9 — the old-club-on-profile bug assigned to Buddy. Use the same approval-gated workflow as last time."

That one sentence leans on the past everywhere. Issue #9 points at a specific thread. "Same workflow as last time" references an earlier session. And critically: the last run was blocked, because implementation in this project requires an approval comment on the issue — which didn't exist yet.

A focused slice, not a transcript

When the agent searches its past, you don't want every old conversation dumped back into the window. You want the slice that matters:

episodic search: "issue #9" "old club" "approval"

→ session 2026-07-18T14:02 (issue-9 investigation)
    · proposed fix: profile query joins stale membership row
    · approval check: NO "implement" comment found — stayed read-only
    · status at end of session: blocked, awaiting approval

This is more than retrieving a flat fact. The agent is pulling back a past event with enough context to understand what actually happened — what was tried, what was found, and where it stopped.

In the wild

In practice, episodic memory is usually a log: messages, tool calls, terminal output, each stamped with a time and session ID. The storage can be humble — markdown files, SQLite with full-text search. Vector search helps when keywords get brittle; temporal knowledge graphs help when the ordering of events matters. The storage format matters far less than the job: can the agent find the past event, recover the right slice, and tell old state from current state?

For what's true now, the agent needs facts that float free of any particular moment.