Ship persistent memory users can trust: audit your AI feature against four controls

Persistent memory is a trust surface

You are shipping an AI feature that remembers users. On August 25, Anthropic made Claude Chat and Claude Cowork share one memory store.

The trust question is whether the user can see what was kept, why it was kept, and how to change it before the next answer is shaped by that state.

Agents can retain private details—buying patterns, communication style, or earlier guidance—without revealing them to the user. That hidden continuity is the core AI memory privacy problem. A user may accept a preference for concise answers, then discover later that the assistant also remembered a private detail they never meant to save. The real damage is the loss of a predictable boundary.

Shared memory makes the limits harder to reason about. The Model Context Protocol enables memory and context to move from one app to another. MCP-enabled memory raises user questions about limiting or editing remembered data, which services can access it, and who is responsible for securing shared memory. If your product is one surface in a larger agent stack, the user still needs one clear account: what is remembered, where it appears, and what they can do.

Four controls make memory auditable

Use this checklist before launch. Each item should be testable in a minute by a teammate who has not seen the design, using the live product, not a mockup. If an answer is “maybe,” the control is not shipped.

• One shared store across surfaces. Ask where memory lives. If chat, mobile, desktop, and an agent workflow each keep separate copies, the user has no stable account of what the product knows. A single store sets the baseline for persistent memory controls.
• User-visible, editable, deletable storage. Open the memory view. Can the user read each item, edit it, and delete it without contacting support? User-editable memory is the repair step when the model infers something wrong.
• Sensitive categories off by default. Check whether sensitive data is excluded unless the user opts in. Default-off is the guardrail that keeps personalization controls from becoming a data-collection habit.
• Per-save disclosure. Trigger a save of a sensitive item. Does the user see a notice at the moment it is stored? Memory disclosure at save time gives the user a chance to correct the record before the memory becomes part of future behavior.

The list is short because the failure modes are ordinary. If the user cannot inspect the state that will shape the next answer, the product can be smart, useful, and still feel unsafe.

Claude's shared store shows the controls working

Claude exposes its stored memory as individual topic files in the Memory settings, where users can view, change, or remove them. The shared store matters because it treats memory as product state, not a model feature.

By default, Claude excludes health, race, ethnicity, religious beliefs, politics, and gender identity from memory storage. When a user enables sensitive topics, Claude shows a notice each time it saves one of those topics to memory. That pairing is the redesign pattern: a default that protects the user, plus a moment of disclosure when the user chooses a broader setting. Memory is enabled by default for Free, Pro, and Max plans on web, desktop, and mobile. The default can be useful, but it only works if the controls are visible and the save moment is legible.

For now, Claude Code is not part of the shared Chat-Cowork memory system. That boundary is useful to state plainly in the product, not only in docs. If a surface does not participate in the shared store, the product should say so, rather than letting users infer that everything remembers everything.

The PI memory design stores memories in JSONL files and treats git diffs on memory files as an audit trail for reviewed changes. The design also requires every preference or principle to include a change_condition so that beliefs can be invalidated.