How should an AI product design memory and chat history controls?

Illustrative situation: a founder ships an assistant that drafts client updates for bookkeeping firms. A bookkeeper shares a screen on a client call and opens a new chat. The assistant greets the bookkeeper with “Picking up on the late-payment penalty at Hollin & Dray.” The client on the call is a different client. Nothing was hacked and the model did not fail. The product remembered, never said what it remembered, and gave nobody a way to see or scope it. The scene is invented, but the pattern is common.

Humbleteam, a digital product design agency, publishes this guide. Vendor behavior is described as of October 30, 2026. The guide treats memory as several separate things, each with its own owner, scope, default and delete path. A memory inventory, an admin comparison, a failure table and an invented worked example follow.

What counts as memory, and why does it need its own design?

The big assistants already split it. Claude saves memory as individual topics and, on paid plans, separately lets users search past chats. Microsoft’s Copilot settings list three user controls: custom instructions, saved memories and chat history. Google’s Gemini help page separates info a user asks Gemini to save from past chats it may look at. A product with one “memory” switch gives people one lever for five different things.

Users also learn late what was stored. A CHI ’26 interview study of 20 ChatGPT users found that a majority had “negative expectancy violations” after seeing what the chatbot had stored. The authors report a strong need for visibility, transparency and user control. A separate WWW 2026 analysis of 2,050 memory entries from 80 ChatGPT users found that 96% were created unilaterally by the system and 28% held personal data as the GDPR defines it. That is one product and one sample, not a measure of yours. It does show how much gets saved without a request.

What should the product remember across sessions?

Start with an inventory. Every row is a decision someone made, or failed to make. The table is our suggestion, not an industry format.

Defaults differ across vendors. Claude memory is on by default for Free, Pro and Max, and by default it does not store personal or sensitive topics. On Team and Enterprise it is off for each member until the member turns it on. Microsoft’s enhanced personalization is on by default, and admins cannot restrict what type of information goes into memory. Microsoft marks the feature as in preview. Our reading: set the default by who is exposed when a memory is wrong. One person on a private screen can get “on.” A workspace where screens are shared should get “off until opted in.”

How should users see, edit and delete memories?

Claude shows memory as topics. A user selects one, reads it, edits or deletes it, or tells the chat to remember, change or forget something. “Pause memory” stops new entries and keeps old ones. “Reset memory” deletes everything, including project memories. Microsoft’s support page offers a Delete button per memory and a Delete all memories button.

Two traps appear in the documentation. First, switching memory off does not delete what exists. Microsoft says so plainly. Second, deleting a chat does not delete memories made from it. Both Microsoft and Claude say that. A person who deletes a chat to “make it go away” is wrong about what happened, and the product knows it. Put the consequence in the dialog: “Memories saved from this chat stay. Review them.” with a button that opens them.

Timing belongs in the interface too. Microsoft states that if a user deletes all chats where a detail was shared, traces of it leave the chat-history details within seven days, and that switching chat history off deletes those details after 30 days. A number can be tested. “Deleted soon” cannot.

On erasure law, GDPR Article 17(1)(a) gives a person the right to erasure when the data is “no longer necessary” for the purposes it was collected for. Other grounds and exceptions exist, and we are not giving legal advice. Our design reading: a delete action should reach every place a memory lives, including derived summaries and search indexes, or the interface should say which places it does not reach.

Microsoft’s HAX Toolkit backs the pattern. Support efficient correction asks teams to make it easy to edit, refine or recover when the system is wrong. Provide global controls asks for system-wide settings over what the system monitors and how it behaves.

How should projects and workspaces scope context?

Claude’s projects are self-contained workspaces with their own chat histories and knowledge bases. On the memory page, each project has its own memory. Claude uses it alongside memory from chats outside projects, but not memory from other projects. On Team and Enterprise plans a project can be shared, and members with “Can view” access can see its contents, knowledge and instructions. That page does not say whether memory or chats in a shared project are visible to other members. Your product cannot leave that question open, so answer it in the interface.

Our suggestion: show the scope above the message box all the time. One line is enough: “Using: Hollin & Dray project (3 files, 1 note) and your 4 saved facts.” Moving a chat between scopes should show what changes before it happens.

Uploaded files need the same honesty. Claude’s help page says that when project knowledge nears the context limit, Claude enables RAG mode to expand capacity by up to 10x. Our reading: files can be searched, not fully read. If your product behaves that way, say “searched” and not “read” when a long file is attached.

What should a temporary or incognito chat do?

Claude’s incognito chats are kept out of history and memory, do not use existing memory, are not used for training, and cannot be converted to regular chats. They are still retained: for 30 days by default, and on Team and Enterprise plans for 30 days for safety or longer under the organization’s policy. They are included in organizational exports and, on Enterprise, in the Compliance API. Google’s Temporary Chats do not appear in recent chats or activity and are not used to personalize or train. Google holds them for up to 72 hours to respond and process feedback. Microsoft says admins can access temporary chats in Purview like regular chats.

So “private” is a loose word. Write the remaining readers into the label: who can still see this chat, and for how long. Make the mode obvious on screen. Decide whether files uploaded in this mode are kept, and say it before upload.

What can the model see right now?

A context indicator answers “what is this answer based on?” before the user has to ask. Claude Code gives a developer example. Memory files, tool names and skill descriptions load before the user types, the /context command shows a live breakdown by category, and automatic compaction summarizes the conversation near the limit. Gemini labels answers that used saved info with “Your saved info” under sources, and Google warns that the label may occasionally be wrong. A label that can be wrong needs a way to dispute it.

For a startup, our suggestion is a panel with four groups: this chat, attached files, the project, and saved memories. Each item can be removed for the next reply without deleting it. Show when the product summarized earlier turns to make room. Sources that back a claim are a different job, covered in letting users inspect sources behind an AI answer. This panel is about what shaped the answer, not what supports it.

What should retention and training disclosures say?

Vendors disagree on mechanics, so the copy must come from your own system. Google’s Privacy Hub says activity is auto-deleted after 18 months by default, with 3, 36 months or never as options. With activity on, a subset of chats is reviewed by human reviewers, and reviewed chats are kept for up to three years. With Keep Activity off, chats are not used to train models but are still saved for 72 hours. Microsoft says Purview retention policies do not apply to Copilot memory and that memory actions do not generate Purview audit entries. Memories live in a hidden folder in the user’s Exchange mailbox.

Our suggested disclosure has six parts: what is kept, where, for how long, who can read it, whether it trains a model, and how to remove it. A startup also inherits the retention and training terms of its model provider. We did not research API terms here, so read them and quote them in your own copy only after you have checked them.

What do B2B teams and admins need?

The two vendors chose opposite answers on admin visibility, and both are defensible. Leaving employees to guess is not defensible. Permission design in general is covered in who can do what in enterprise AI.

What are the failure cases?

HAX’s Update and adapt cautiously asks teams to consider the scale and rate of behavior changes. Treat a model change as a memory change too. A new model may read old entries differently.

Illustrative worked example: a bookkeeping assistant

Every name here is invented. Larkspur Books, a startup, sells an assistant to bookkeeping firms. A product designer and a founder fill in the inventory. They make five decisions.

1. Saved facts are per bookkeeper and per client project, never account-wide. The Hollin & Dray penalty can only appear inside the Hollin & Dray project.
2. Inferred facts wait in a “suggested memories” tray. Nothing is used until the bookkeeper accepts it.
3. A one-line scope bar sits above the message box, and a screen-share mode hides memory references.
4. “Delete chat” opens a dialog listing the memories saved from it, each with Keep or Remove.
5. A firm admin can switch memory off for the firm, can export and delete entries for a leaver, and is told in writing that admins can read memories.

They log how often suggested memories are accepted, removed within a week, or reported as wrong. They claim no results yet.

Where do these rules stop working?

Vendor behavior comes from help pages and documentation read on October 30, 2026, and it changes. We could not open OpenAI’s ChatGPT help pages, so ChatGPT behavior appears here only through research on its users. Microsoft’s memory feature is in preview. The ChatGPT memory studies use one product and small samples. We found no controlled study showing which memory controls raise trust or retention, so test the advice here. The GDPR point is a design reading, not legal advice.

What can you produce now?

Six things to produce before anyone redraws a screen:

1. The completed memory inventory, with an owner who can confirm each row is true in the code.
2. A scope model: which chats, files and memories can mix, written as a one-page map.
3. Delete and off behavior for each row, with the exact dialog text and timing.
4. A context panel and a temporary-chat state, drawn with their disclosure lines.
5. An admin matrix: switch off, read, export, delete, retain, audit.
6. A failure test plan covering the five cases above.

If you are choosing a team to design these states, our comparison of design agencies that have designed LLM-powered products for startups shows how each one describes its work, so you can judge them before you talk.