Memory in AI systems is not one feature. It is several mechanisms with different lifetimes, owners, and risk profiles. Context architecture decides which type applies where.
Memory types
| Type | What it stores | Typical lifetime | Risk if misused |
|---|---|---|---|
| Session | Current task thread | Until session ends | Low if scoped to one case |
| Episodic | Past interactions for continuity | Days to months | Stale facts, wrong customer bleed |
| Organizational | Approved docs, policies, playbooks | Versioned, long-lived | Low when retrieval is governed |
| Working (in-prompt) | Assembled context for one run | Single invocation | Token cost, leakage if over-filled |
Design rules
- Default to stateless runs for regulated outputs; add memory only with a written reason.
- Episodic memory needs tenant and case IDs—never a shared pool across customers.
- Organizational memory should flow through retrieval with tags (
approved,deprecated), not ad hoc uploads per user. - Forget on purpose—define retention for session and episodic stores (e.g. delete when ticket closes).
Example: support workflow
- Session: last N messages in the ticket.
- Organizational: KB articles tagged
customer-safe, versioned quarterly. - Episodic: optional summary of prior cases for the same account—human-visible, not silent auto-inject.
- Denied: full chat history from unrelated products.