Contrast episodic and semantic long-term memory with examples from a personal-assistant agent

Long-term memory in an LLM agent is not one thing. It splits cleanly into two kinds. **Episodic memory** holds specific past events tied to a time and context. Examples for a personal assistant: 'On 2026-04-12, the user asked about migrating from Pinecone to Turbopuffer and decided against it because of latency concerns.' 'On 2026-05-30, the user mentioned a sprint deadline of June 14.' These memories answer 'what happened?' They have timestamps, they reference specific decisions or events, and they are dense with context. **Semantic memory** holds distilled, stable facts about the user or domain. Examples: 'The user prefers Python over TypeScript.' 'The user works at a 20-person ML startup.' 'The user's primary timezone is IST.' These memories are time-invariant (or at least slow-changing), they describe attributes rather than events, and they are short and reusable. The two have different retrieval patterns. **Semantic memories** are loaded as persona context at the start of every session, they shape how the agent talks to this user. **Episodic memories** are retrieved on demand when the model needs to reference a specific past event ('what did we decide about vector stores last month?'). Mem0 and Zep both expose this split as first-class API constructs. Letta and LangGraph leave it to the application schema, but most teams arrive at the same distinction by necessity.

**Episodic stores events with time; semantic stores facts.** The distinction is borrowed from cognitive science but earns its keep in LLM systems because the two kinds have different shapes and different lifecycles. **Episodic memory entries** look like: `{event: 'User decided against Turbopuffer migration', date: '2026-04-12', reasoning: 'latency concerns from p99 benchmark', related_topics: ['vector-stores', 'pinecone', 'turbopuffer']}`. They are dense, time-stamped, and retrieved by similarity to a current question. Their value comes from preserving the *story* of what happened. When the user later asks 'remind me why we picked Pinecone', the episodic memory contains the actual reasoning, not just the conclusion. **Semantic memory entries** look like: `{fact: 'Prefers Python over TypeScript', confidence: 0.9, last_confirmed: '2026-05-15'}` or `{fact: 'Works at 20-person ML startup', confidence: 0.95}`. They are short, stable, and loaded into the system prompt as persona context. Their value is shaping the model's default behavior every session: pick Python when offering code, assume small-team constraints when discussing infrastructure. **Retrieval differs.** Semantic memory is eager, loaded at session start as a small persona block. Episodic memory is lazy, retrieved on demand via vector search over event embeddings when the current turn references the past. **Write policy differs.** Episodic writes are easier; you record what happened with timestamps and move on. Semantic writes are harder because the system must infer a stable trait from observations, often using an LLM to compress 'the user mentioned Python in 6 of the last 10 conversations' into 'prefers Python', and then maintaining a confidence score that can be revised. The two work together. A conversation often produces both: 'On 2026-06-01, the user shipped the auth refactor in Go' is episodic; the semantic update is bumping confidence on 'works on backend systems' or adding 'has Go