← Master Index
Vol. 15 Module 15.2 Lecture

Episodic Memory

Agent Memory Types (added)

How This Lesson Fits the Module & Volume

Module 15.1 introduced memory as a core agent primitive alongside the agent loop, tool calling, and human in the loop. Module 15.2 splits that primitive into types. Episodic memory is first: it stores what happened in a particular run, session, or trajectory—not general facts.

Next lectures contrast this with semantic memory (facts and concepts), working memory (the live scratchpad), and long-term memory (what you persist across sessions). Frameworks in LangGraph and CrewAI later wire these stores into agent graphs and crews.

Learning Objectives

By the end of this lesson, students should be able to:

  • Define episodic memory for agents as time-stamped, contextual traces of past events.
  • Distinguish an episode (a specific run) from a semantic fact and from working-memory scratch.
  • Design a minimal episode record: goal, actions, observations, outcome, timestamp.
  • Retrieve similar past episodes to improve planning and avoid repeating failures.
  • Identify failure modes: noisy logs, privacy leaks, and treating every chat turn as an episode.
  • Place episodic stores relative to RAG/vector stores used as long-term semantic memory.
Definition

Episodic memory (in cognitive science and in agent systems) is memory of specific experiences—events bound to time, place, actors, and outcome. For an AI agent, an episode is typically one task run or conversation session: the goal, the tool calls, the observations, the human interventions, and whether the run succeeded.

Why Agents Need Episodes, Not Just Facts

A support agent that only knows “refunds require a receipt” (semantic) still fails if it cannot recall “last Tuesday this user already submitted receipt R-441 and was denied for policy X.” Episodes capture situated history. They let the planner reuse successful trajectories and skip dead-ends—similar in spirit to how reinforcement-learning agents store trajectories, but here the “policy” is an LLM plus tools.

Memory typeWhat is storedTypical agent artifact
EpisodicDated events and outcomesRun logs, trajectories, session recaps
SemanticFacts, concepts, policiesKB, wiki, vector RAG corpus
WorkingCurrent task scratchContext window, graph state
Long-termAnything persisted across sessionsDB + vector store + episode archive

Anatomy of an Agent Episode

Identity

  • episode_id, user_id, thread_id
  • started_at / ended_at
  • goal or user intent

Trace

  • Thoughts / plan steps
  • Tool names + arguments
  • Observations / errors

Outcome

  • success / fail / aborted
  • human overrides (HITL)
  • short recap for retrieval

A Minimal Episode Store

Production systems often use a database plus embeddings of recaps. The sketch below is enough to teach write, retrieve-by-similarity, and recency—the three operations most agentic workflows need.

from dataclasses import dataclass, field from datetime import datetime, timezone @dataclass class Episode: episode_id: str user_id: str goal: str steps: list[dict] = field(default_factory=list) # {thought, tool, observation} outcome: str = "in_progress" # success | fail | aborted recap: str = "" started_at: datetime = field(default_factory=lambda: datetime.now(timezone.utc)) class EpisodeStore: def __init__(self): self._items: list[Episode] = [] def write(self, ep: Episode) -> None: self._items.append(ep) def recent(self, user_id: str, k: int = 5) -> list[Episode]: own = [e for e in self._items if e.user_id == user_id] return sorted(own, key=lambda e: e.started_at, reverse=True)[:k] def similar(self, query: str, k: int = 3) -> list[Episode]: q = query.lower().split() scored = [] for e in self._items: text = f"{e.goal} {e.recap}".lower() score = sum(1 for w in q if w in text) if score: scored.append((score, e)) scored.sort(key=lambda x: x[0], reverse=True) return [e for _, e in scored[:k]] store = EpisodeStore() store.write(Episode( episode_id="ep-17", user_id="u-42", goal="Reset SSO for contractor", steps=[{"tool": "lookup_ticket", "observation": "Ticket #881 open"}], outcome="fail", recap="SSO reset failed: contractor lacked Okta admin group.", )) print([e.recap for e in store.similar("contractor SSO reset")])

Retrieval Policies That Matter

Dumping every past episode into working memory blows the context window. Prefer: (1) recency for the same user/thread, (2) similarity of goal or error signature, (3) outcome filter (prefer successes when planning, failures when debugging). Summarize traces into recaps before embedding—raw tool JSON is a poor semantic query target.

Strengths

  • Personalizes behavior without retraining
  • Enables “do not repeat this failure” learning
  • Supports audit and HITL review
  • Natural fit for multi-step agent traces

Tradeoffs

  • Storage and PII growth
  • Noisy traces poison retrieval
  • Stale episodes contradict new policy
  • Easy to confuse with semantic KB
Common Misconception

“Episodic memory is just the chat history.” Chat history is working memory while the thread is live. An episode is a compact, retrievable record of a completed (or aborted) experience, often stored outside the prompt and fetched only when relevant. Unbounded chat logs are not a memory architecture.

Knowledge Check

  1. Short Answer: What binds an episodic memory that a semantic fact lacks? Answer: Time/context—a specific event, actors, and outcome.
  2. True/False: A vector store of company policies is primarily episodic memory. Answer: False—that is semantic (and usually long-term).
  3. Multiple Choice: The best recap to embed is: (a) raw tool JSON dumps, (b) a short outcome-focused summary, (c) the full token stream. Answer: (b).
  4. Short Answer: Name two retrieval keys for episodes. Answer: Recency (same user/thread) and similarity of goal/error.
  5. True/False: HITL overrides belong in the episode trace. Answer: True—they explain why the agent changed course.
  6. Multiple Choice: Working memory during a live run is closest to: (a) the context window/scratchpad, (b) a wiki, (c) a cold archive. Answer: (a).
  7. Short Answer: Why not inject all past episodes into every prompt? Answer: Context limits, noise, cost, and privacy.
  8. True/False: Failed episodes are useless and should be deleted immediately. Answer: False—they help avoid repeating failures.
  9. Multiple Choice: An episode_id + user_id + recap is mainly for: (a) CNN pooling, (b) write/retrieve of experiences, (c) MCP transports. Answer: (b).
  10. Short Answer: Which next lecture covers facts and concepts rather than events? Answer: Semantic Memory.

Key Takeaways

  • Episodic memory stores situated experiences: goal, trace, outcome, time.
  • It is not chat history, not a policy wiki, and not the live scratchpad.
  • Write compact recaps; retrieve by recency and similarity.
  • Guard PII and stale traces; episodes can poison future plans.
  • Continue with Semantic Memory for facts vs events.
Trainer’s Guide

Lab: Log three toy agent runs (one success, two distinct failures). Implement recency + keyword similar() and show which episodes a new “SSO contractor” goal retrieves.

Whiteboard: Draw one user journey with working memory (inside the loop), episodic write (after the loop), and semantic lookup (policy KB). Mark where HITL annotations attach.

Recap: Episodic memory is the agent’s dated experience log. Continue with Semantic Memory.