Episodic memory — specific events, tied to a particular moment:
- "On March 3rd, the user asked about the refund policy and seemed frustrated"
- "In the last call, the sales rep promised a follow-up by Friday"
Semantic memory — general, timeless-ish facts about the world or the user:
- "The user's company has ~50 employees"
- "The user prefers email over phone calls"
Procedural memory — learned behavior about how to act, not what is true:
- "Always confirm order details before processing a refund for this user"
- "This user gets annoyed by overly long responses — keep answers short"
These three types should usually be stored and decayed differently:
- Episodic memories often matter less as time passes (an event from 6 months ago is less relevant than one from yesterday) — good candidates for time-based decay.
- Semantic memories tend to be more stable but need active contradiction-checking (a "user's company size" fact should be checked/updated periodically, not just accumulated forever).
- Procedural memories are often the most valuable long-term, since they encode learned behavior that improves the agent's usefulness over time, and they change relatively rarely.
If you store all three types identically (same decay rule, same storage, same retrieval weighting), you'll end up either losing valuable long-term behavioral learnings too fast, or clogging retrieval with stale one-off events.
Working memory = what's currently in the LLM's context window for this specific turn. Long-term memory = everything stored externally (vector DB, graph DB) that gets selectively retrieved and injected into working memory only when relevant.
Think of it like RAM (working memory — fast, but wiped when the session ends) vs. a hard drive (long-term memory — slower to access, but persists and only the relevant files get loaded into RAM when needed). This RAM/disk analogy is literally the design inspiration behind MemGPT/Letta (Module 9).
1. Capture → raw conversation turn happens
2. Extract → LLM pulls out discrete facts from the raw turn
3. Store → facts get embedded/graphed and saved
4. Retrieve → on a new query, relevant facts are fetched
5. Inject → retrieved facts are added to the prompt (working memory)
6. Decay/Forget → over time, irrelevant or stale facts get down-weighted or deleted
Every module from here builds out one piece of this lifecycle in depth.
Take this sample conversation:
User: Hi, I'm looking into your Enterprise plan for my company.
Agent: Great! How many employees do you have?
User: We're about 50 people right now, growing fast though.
Agent: Got it. What's your main use case?
User: Mainly for internal support automation. Also, quick note —
please always email me, I never check Slack.
User: Actually wait, we just closed a round, we're closer to 80
employees now.
Manually write out every fact you can extract, and classify each as episodic / semantic / procedural.