The full answer
Separate three kinds of memory. The current conversation lives in the context window and is kept small by clearing old tool output and summarising older turns. Durable facts about the user (preferences, projects, decisions) live in a per-user store that the assistant reads and writes through tools. Large reference material stays in its systems and is fetched only when needed. Each layer has its own rules for what is kept, for how long, and who can see it.
1. Why not keep everything in the prompt
Context is finite and has diminishing returns: the more tokens in it, the worse the model recalls any one of them, and every token costs money on every turn. A month of conversations in the prompt is slow, expensive and less accurate. Memory design is choosing the few things worth carrying forward.
2. The three layers
| Layer | Holds | Mechanism |
|---|---|---|
| Working context | This conversation, recent tool results | Clear old tool results past a threshold; compact older turns into a summary |
| Long-term memory | "Prefers short answers", "Project Atlas launches 3 March", decisions made | Per-user memory store read at the start, written during work, via memory tools |
| Reference | Documents, tickets, mail, calendars | Searched just in time with tools, never copied wholesale into memory |
3. Long-term memory in practice
- Tools, not magic: give the assistant tools to view, write, update and delete memory entries (the Claude API's memory tool is one ready-made pattern; your application executes the file operations against storage you control).
- Small, structured entries: one fact per entry, with a date and a source conversation. Notes such as
projects/atlas.mdgrow and are rewritten rather than appended forever. - Read at the start: load the user's index (titles and one-line summaries), and open entries only when relevant.
- Write deliberately: save stable facts and decisions, not every message. Instructions in the system prompt say what is worth remembering.
4. Isolation and safety
- Every memory operation is scoped by the authenticated user ID in code. The model never chooses whose memory to open.
- Validate paths and keys (no traversal outside the user's area).
- Memory is untrusted input too: a note written from a malicious document can carry instructions into later sessions. Store provenance and review what gets written from external content.
5. User control and retention
- Users can see, edit and delete what the assistant remembers, and "forget this" works immediately.
- Old entries expire or are summarised; nothing personal is kept longer than policy allows.
6. Measure it
Test sets with multi-session scripts: does the assistant recall the right fact a week later, ignore stale ones, and avoid inventing memories? Track memory size per user, tokens per turn and cost.
What interviewers want: the limits of context (cost and recall), separating working, long-term and reference memory, compaction and clearing, tool-based memory with small structured entries, strict per-user scoping in code, memory as an injection path, user control, and evaluation across sessions.
Last updated 16 October 2026
Sources