Forward-deployed / AI Knowledge Graph
Memory & contexta Generative AI module
Recap

Memory & context — recap & real-world examples

Real-world examples & war stories

ChatGPT memory shipped with controls (2024). In February 2024 OpenAI began testing a memory feature for ChatGPT with a small share of users. Users could tell it to remember or forget something, view what it remembered, and turn memory off. 🎯 Takeaway: ship visibility and control with the capability, not after it. See memory as a product decision. The date and controls come from press coverage in search results. OpenAI's own page could not be opened.

A caching bug showed one user's data to another (2023). On March 20, 2023, a bug in an open-source library used by ChatGPT let some users see other users' chat titles. OpenAI said a small share of ChatGPT Plus subscribers could also see some billing details. It took the service offline to fix it. 🎯 Takeaway: a leak needs no attacker. Any shared store can cross a boundary under load. Enforce the boundary in the system, and test it directly. This was a race-condition bug in a caching library, not a memory feature. Details come from press coverage in search results.

A planted memory that kept working (2024). Security researcher Johann Rehberger showed that a crafted web page or document could get the ChatGPT macOS app to save a hostile instruction in its long-term memory. The instruction sent later conversations to an outside server. OpenAI fixed the app in September 2024, and the work was published on September 20, 2024. The fix was partial. It closed the data-sending route. The author notes that an untrusted page can still get ChatGPT to store memories. 🎯 Takeaway: if a model can write to memory, an injection can outlive the session. A vendor patch does not close the write path. Hold writes from untrusted content for confirmation. See poisoning and the write path. The author's own write-up was opened for this edit.

Who owns the store (Claude API). The Claude memory tool runs on the developer's side. Claude asks for a file operation, and the application performs it. Anthropic's docs say memory "lives entirely in your application," and put path checks, size caps and expiry on the developer. 🎯 Takeaway: you own the store, and so you own its boundary and its deletion duty. See session, user & organizational memory.

Deleting the chat does not delete the memory (Claude help page). Anthropic's help page says that deleting a conversation does not delete the memories created from it. The user must delete those memories one by one. Memory is on by default for Free, Pro, Max and Ultra users. On Team and Enterprise plans, each member starts with it off, and owners cannot view members' memories. 🎯 Takeaway: users link a chat to what it taught the product. Decide whether deleting the source also deletes the memory, and say which. See when memory goes wrong and session, user & organizational memory. Checked 2026-11.

The stale preference (an illustration). A shopping assistant learns "vegetarian" in January. In June the customer starts eating fish and says so, but the store only appends. Retrieval returns the January note first, and the assistant keeps offering vegetarian options. Nothing crashed. 🎯 Takeaway: staleness is a write-path problem. Give facts a replace rule and a review date. See writing and maintaining memory.

Module recap

Lesson The one idea The question it makes you ask
Memory as a product decision Memory is a set of promises you choose to make, not a free default. What do we remember, for whom, for how long, and who can edit it?
Session, user & organizational memory Three shapes carry three different stakes. Name the shape first. Which shape is this, and is the boundary enforced by the system?
Writing and maintaining memory Memory quality is set when a memory is written. What happens to the old fact when a new one contradicts it?
Retrieval as memory Load, retrieve, or keep notes. Pick by size and kind of data. Is this small enough to load, large enough to search, or task progress?
When memory goes wrong Stale, leaked, uncorrectable and poisoned memory each need a test. Would monitoring find a memory failure, or would a user?

The through-line: memory is never something a model gives you. Your product builds it as a set of promises. The mistakes that sink memory features are rarely engineering mistakes. They are decisions nobody made: a shape left unnamed, a boundary assumed instead of tested, a write path with no rule, a deletion path never built. The engineering depth lives in Context engineering and Context & memory. This module stays at the decision altitude.

Walk-away question: "For our AI feature's memory: could we tell a user exactly what we remember, could they see and correct it, do we have a rule for how memories are written and expire, and have we tested the boundary against the store, not just the chat?"

If yes, this is a memory feature your product can stand behind. If no, you know which lesson to reread.

Test yourself

  1. Why is memory a product decision and not a default?

    AnswerThe model keeps nothing between calls. Your team builds every bit of memory, and it makes promises about what is kept and for how long. It has a cost and a risk that someone must own. (Lesson 1)

  2. What are the four parts of the question that scopes a memory feature?

    AnswerWhat is remembered, for whom, for how long, and who can see or edit it. If any part is "we will decide later", the feature is not ready to build. (Lesson 1)

  3. Name the three memory shapes and the main risk of each.

    AnswerSession memory (low risk, may be dropped when a long chat is summarised). User memory (a personal data store with duties to show, correct and delete). Organizational memory (the boundary of who is inside). (Lesson 2)

  4. Why must the identity used to filter memories come from the session and not from the model?

    AnswerA model can be tricked into asking for another user's data. The store must filter by the authenticated caller before anything reaches the model. (Lesson 2)

  5. A user says "I moved to Pune." The store says "lives in Delhi." What should the write policy do?

    AnswerReplace the old value, because the newer fact wins, and keep the old one in history for audit. If the change is ambiguous or sensitive, ask the user. (Lesson 3)

  6. A user has forty stable preferences and three years of chat history. How do you serve each?

    AnswerLoad the forty preferences directly on every request. Search the history and add only the few relevant pieces. Filter to the user's own records before ranking. (Lesson 4)

  7. How is memory poisoning different from an ordinary prompt injection?

    AnswerAn ordinary injection ends when the session ends. If it writes itself into memory, it persists and acts in later sessions. Defend by holding writes from untrusted content for confirmation. (Lesson 5)

  8. Why is asking the chatbot "do you know other users' data?" a weak leakage test?

    AnswerThe model may refuse while the store still returns the data. Test the store directly, as an attacker would. (Lesson 5)

Sources

Core insight: A model does not give you memory. Your product builds it as a set of promises about what it keeps, reads back and forgets.
Part of the learning modules collection.