Memory Types
Agents have three storage horizons — the context window, short-term session state, and long-term persistent memory — and long-term memory splits into semantic facts, episodic events and procedural know-how.
Three horizons
The word "memory" hides three very different mechanisms with different lifetimes, costs and failure modes. Keeping them separate is the first step to designing any of them well.
- Context window — what the model sees in this call. Lifetime: one call. Capacity: the token limit. It is not storage; it is the input (Context Engineering).
- Short-term (session) memory — the orchestrator state for one task or conversation: turns, plan, scratchpad, tool results. Lifetime: the session. Lives in your process or a session store, and is rendered *into* the context selectively (Dynamic Context Assembly).
- Long-term memory — facts and experiences persisted across sessions, scoped to a user, team or system. Lifetime: until expired or deleted. Lives in a database and is retrieved into context on demand (Memory Architectures).
Semantic, episodic, procedural
Long-term memory borrows a taxonomy from cognitive science that maps cleanly onto storage decisions. Take a customer-support agent for a SaaS product as the running example.
- Semantic — stable facts. "Customer 4471 is on the Enterprise plan, based in Berlin, prefers German, admin is anna@…". Typically key-value or a small profile record; retrieved by id, not by similarity.
- Episodic — things that happened, with time. "On 2026-08-12 the customer reported SSO failures; we escalated ticket T-8812; resolved 2026-08-14 by rotating the SAML cert." Stored as timestamped events or ticket summaries; retrieved by recency and by similarity to the current issue.
- Procedural — how to do things. "For SSO issues on Enterprise, first check the IdP metadata expiry, then the clock skew; do not ask the customer to re-provision users." Usually curated instructions, playbooks, or learned tool-usage patterns; injected into the system prompt for the relevant route.
What each type is for
The support agent needs all three, but in different places. Semantic facts remove repeated questions ("which plan are you on?") and enable correct tool calls (right tenant id). Episodic memory gives continuity: recognising that today's ticket is the same SSO problem from two weeks ago changes the diagnosis. Procedural memory is where hard-won operational knowledge lives, and it is the type most teams under-invest in because it looks like "just a prompt".
Notice what is *not* long-term memory: the current conversation, the model's reasoning, and raw tool output. Those are session state, and promoting them wholesale into long-term storage is the fastest route to Memory Pitfalls.
1type SemanticFact = { userId: string; key: 'plan' | 'locale' | 'admin_email' | 'region'; value: string; updatedAt: string }2 3type Episode = { userId: string; at: string; summary: string; ticketId?: string; tags: string[] }4 5type Procedure = { route: 'sso' | 'billing' | 'export'; steps: string[]; doNot: string[]; version: number }6 7// Retrieval differs per type:8// semantic → lookup by (userId, key) — exact, cheap, always injected9// episodic → top-k by similarity + recency — only when relevant to the current issue10// procedural → by route classification — goes into the system prompt for that routeChoosing what to persist
The interview question "what would you store long-term?" has a disciplined answer: store what will change a future decision, is stable enough to still be true when read, and is cheap to verify. Plan tier: yes. The user's tone in one conversation: no. A resolved incident: yes, as a two-line summary with the ticket id, not the transcript.
Every persisted item needs an owner (which user or tenant), a source (who said it, when), and a lifetime (Memory Pitfalls covers expiry and deletion). If you cannot fill those three fields, do not store it.
Key points
- Context window, session state and long-term memory are three different mechanisms with different lifetimes.
- The context window is input, not storage; session state is rendered into it selectively.
- Semantic = stable facts by key; episodic = timestamped events by similarity and recency; procedural = how-to knowledge by route.
- Store what changes future decisions, stays true, and can be verified — with owner, source and lifetime.
- Raw transcripts and tool output are session state, not long-term memory.
Memory explorer
Targeted: the step gets what it needs (context, the session, maybe one episodic fact). Retrieve memory per step; do not inject everything.
When to use — and when not to
- Users return across sessions and repeating questions costs trust (support, assistants, coaching).
- Past incidents or decisions materially change how the next task should be handled.
- Operational know-how accumulates and should be applied consistently by every run.
- One-off, stateless tasks (translate this, classify that) — memory is pure overhead.
- When the source of truth already exists in a system of record — read it via a tool instead of copying it into memory.
- When you cannot scope memory per user/tenant safely; leakage is worse than forgetting.
Failure modes
- Treating the context window as memory and wondering why the agent forgets after the limit.
- Storing whole transcripts as "episodes"; retrieval returns noise and costs a fortune.
- Semantic facts without timestamps: the plan tier changed six months ago and the agent still uses the old one.
- Procedural knowledge living in one engineer's head instead of a versioned playbook the agent can load.