Overview
How might we let people choose how far a fact persists before it becomes durable assistant context?
When memory can outlive the current chat
- Near send or attachment (where the decision happens) not only in buried settings.
- Settings still need a review list of what is stored.
When scope is fixed by policy or product design
- Stateless products with no memory layer at all.
- Single-session throwaway chats where every option is “this chat only.”
- Enterprise modes where policy already forces chat-only and a toggle would lie.
States
Design the scope decision at save time, not as a buried settings toggle after the fact is already stored.
Proposed
The assistant or user identifies a fact worth remembering. Nothing is stored yet.
Scoping
Save to options appear: this chat, project, or all chats. The person picks a destination.
Confirming
A short line confirms where the fact will live and what that scope means in plain language.
Saved
Explicit save commits the fact at the chosen scope. The UI reflects the destination.
Reviewing
Settings or in-thread review shows what is already remembered at each scope.
Revoked
The person removes or narrows scope. Downgrade from all chats to project should be one clear action.
Key UX elements
The parts that must be present for scope choice to prevent accidental long-term memory.
Show the exact text that will be stored.
Quote the preference or detail verbatim so people know what they are promoting into memory.
Offer distinct Save to destinations.
This chat, project, and all chats must read differently. Avoid labels like Saved vs Remembered.
State where it will live before commit.
Update confirmation copy as the scope changes so promotion never feels silent.
Make storage explicit.
A primary Save action beats auto-remember on send, especially for pasted or sensitive content.
Let people inspect stored memory.
After save, link to a review list grouped by scope so users can edit or delete what the assistant knows.
Default to the narrowest safe scope.
Chat-only or project-only defaults reduce risk when someone pastes credentials or one-off context.
Anti-patterns to avoid
Defaulting sensitive pastes into long-term memory without a scope choice.
Toggles that do not show what is already remembered after send.
Silent promotion from project memory to org-wide memory.
Scope labels users cannot distinguish (Saved vs Remembered vs Learned).
How products use it
| Product | Implementation |
|---|---|
| Claude Projects | Project-scoped knowledge separate from global chat memory. |
| ChatGPT Memory | Controls for what is remembered and ability to manage saved memories. |
| Notion AI workspaces | Workspace and page context boundaries for AI assistance. |
| Enterprise copilots | Tenant and channel scopes with admin-enforced retention. |
Real-world examples
How shipped products implement memory scope toggle, from our teardown guides.
Implementation
Copy this prompt to generate a production-ready implementation in Cursor, Claude Code, Lovable, or any AI coding agent.
Generate a production-ready implementation of the "Memory Scope Toggle" AI interface design pattern.
Pattern Definition:Frequently asked questions
What is a memory scope toggle in AI chat?
A memory scope toggle lets users decide whether content applies only to the current chat, a project/workspace, or lasting account memory before the assistant stores it.
Why not remember everything by default?
Long-term memory increases privacy risk and stale-context bugs. Explicit scope keeps sensitive one-offs from becoming permanent assistant beliefs.
Where should the toggle live?
Near send or attachment (where the decision happens) not only in buried settings. Settings still need a review list of what is stored.
How does it relate to data ownership?
Scope controls what enters memory; data ownership controls export, delete, and training use of that stored data. Users need both.