An assistant that remembers, and forgets on request
An assistant that keeps what matters across sessions, recalls it on the next message, and forgets on request.
The problem
An assistant that forgets everything between sessions makes the user repeat themselves — their name, their preferences, what they asked yesterday. Each conversation starts from zero, and it feels like talking to a stranger every time.
You want memory that persists: the assistant extracts what is worth keeping from a conversation, recalls the relevant parts on the next message, and answers in a way that shows it remembered. And it must forget on request, because some things should never be stored.
Architecture
Memory wraps the reply. A message arrives, the assistant recalls what is relevant from this user's memories, that shapes the reply, and afterwards anything worth keeping is written back to the store for the next message. The loop is what turns a stateless model into an assistant with a history.
What not to remember is a design decision, not an afterthought. Decide up front which fields are off-limits — payment details, anything a user asks to be forgotten — and enforce it at the write-back box, so private data never enters the store.
What it draws on
Everything here comes from this stage of the roadmap; the project is where those courses meet.
- LangGraph: checkpoints and stores for conversation memory
- Mem0: extracting, scoping, updating and deleting long-term memories
- Or the same with LangMem: memory managers, the LangGraph store and background extraction
- Topic: customer data and PII: what should never be remembered
What done looks like
| Requirement | Done when |
|---|---|
| Continuity | A second message in the same conversation uses the first without the user repeating it |
| Recall | A new conversation for the same customer uses a fact from an earlier one |
| Isolation | Customer A's memories never appear in customer B's answers |
| Updates | A changed fact, such as a new address, replaces the old one |
| Forgetting | After a delete request, no memory for that customer is returned, and a test proves it |
Where to start
Build the write-and-recall loop on one fact first: remember the user's name, recall it next message. Get that solid, then widen what is worth keeping. Add the forget path early, not last — deciding what is off-limits after you have stored it is how private data leaks.
Every expert started right here.