Memory & context for the product leader
Memory as a product decision, the three shapes it takes, how memories are written and kept, the designs for reading them back, and the trust failures it has to be designed against.
A model does not give you memory. Your product builds it as a set of promises about what it keeps, reads back and forgets.
A model remembers nothing between calls. Anything it appears to "remember" — the earlier turns of a chat, a preference from last week, a company's house style — was put back in front of it, deliberately, by your product. Whether and how to do that is one of the highest-leverage product decisions in any AI feature, and it is easy to get backwards: teams either build no memory at all, forcing users to repeat themselves forever, or build memory carelessly, and end up with a feature that resurfaces something a user assumed was forgotten, in front of the wrong audience.
A note on scope. The engineering mechanics of context and memory are already covered in depth in two places: Context engineering and Context & memory. They cover the context window as a scarce resource, compaction, offloading, and the memory hierarchy. This module does not repeat them. It answers what those lessons do not lead with: memory as a product decision. What do you promise a user? How is a memory written and kept? What does it cost in trust? Where does it fail as a business risk?
It has five lessons. Four cover the decision and its risks. One, on the write path, covers ground that no other lesson in this curriculum does. For the wider argument about context as an operating discipline, including specs, governance and evals, see Context engineering for the product leader.
Where the depth lives
Each lesson summarises an idea and points to the lesson that covers it in full.
| If you want the full depth on | Read |
|---|---|
| The context window, compaction, offloading | Context engineering |
| The memory hierarchy for agents | Context & memory |
| Chunking, embeddings, retrieval quality | RAG & vector databases |
| Isolating tenants and users | Multi-tenant isolation |
| Prompt injection and defences | Safety, security & governance |
| Owning shared context across features | Context governance at scale |
The knowledge graph
Memory is a set of promises your product makes about what it will and will not carry forward. Every lesson hangs off this picture:
Five lessons · promise → scope → write → read → risk
Memory isn't free infrastructure — every step of it is a decision someone should make on purpose.
Memory is a feature you choose to build
Three scopes · session · user · organizational
Session
A sticky note · one conversation only
User
A personal file · one person, many visits
Organizational
A shared handbook · team-wide with an owner
What is saved, when, and how it changes
Three designs · load · retrieve · agent notes
Four failure modes to test for by default
Stale
Product acts confidently on outdated info
Leaked
Crosses tenant, user, or org boundary
Stuck
User can't see, correct, or delete it
Poisoned
Planted instruction acts in later sessions
Read it in four passes. The promise: memory is something your product decides to offer, with a cost and a risk. The scope: one conversation, one person, or a whole organization, each with a different contract. The write and read paths: how memory gets in, and how it comes back. The risk: every shape fails in a predictable way, and the failure is usually a trust problem before it is a technical one.
The lessons
- Memory as a product decision — why offering memory is a choice with a cost and a promise, and the four-part question that scopes it.
- Session, user & organizational memory — the three shapes, and why each needs its own answer to "who sees this, and for how long?"
- Writing and maintaining memory — what is worth saving, when to save it, how new facts replace old ones, and when memories expire.
- Retrieval as memory — the three designs (load, retrieve, keep notes) and how to choose. Bridges to RAG.
- When memory goes wrong — staleness, leakage, the right to be forgotten, and poisoning, with a test for each.
Each lesson has a 🎯 For the product leader briefing, a labelled worked example, an "Under the hood" section for engineers, and a Sources list.
📌 Close out the module: Recap & real-world examples, which ends with a self-test.