What Should an AI Companion Remember? A Practical Guide to Choosing What Stays
If you are deciding what an AI companion should remember between conversations, start with a short list of details you deliberately provide and expect to matter again: stable response preferences, ongoing project context, and a few practical facts relevant to that project. Keep one-off scene details inside the project or conversation where they belong. Do not treat a system’s ability to infer a pattern as permission to store it. A useful memory helps with a concrete future task, stays within its intended scope, and can be reviewed or removed.
Start with the task a memory should improve
Before saving a detail, finish this sentence: “Remembering this will help with ___.” If the answer is vague, the detail probably does not belong in persistent memory. “Use concise bullet points when helping me plan weekend activities” has a clear purpose. “I seemed impatient in yesterday’s chat” does not establish a lasting preference or useful fact.
This is a practical application of data minimization: NIST defines minimization as limiting the creation, use, and retention of personal information to what is directly relevant and necessary for a purpose, and keeping it only as long as needed for that purpose. For a memory feature, the corresponding design question is whether the system needs this detail to perform a user-chosen task later. NIST’s definition of minimization
Good candidates: explicit preferences and useful project facts
The strongest candidates are ordinary details the user has stated plainly and that are likely to shape repeated responses. Examples include a preferred answer format, a chosen project name, the materials already selected for a craft project, or the user’s stated preference for low-maintenance plants while planning a balcony garden. Save the least detailed version that still helps: “prefers short, step-by-step instructions” is more useful and less intrusive than storing a narrative about every occasion when the user requested brevity.
Some personal facts are relevant only inside a defined project. If a user says a room is 3 by 4 metres while planning its layout, that dimension may help within the room-design project; it need not become general background for unrelated conversations. A project-scoped memory answers a simple question: which future conversations are allowed to draw on this detail?
Product documentation shows why it helps to treat persistent memories and project context as distinct choices. OpenAI describes saved memories as separate from chat history and documents a Project-only memory option that restricts which project conversations can reference one another. These are product-specific controls, not a guarantee that every AI system offers the same scope. OpenAI’s memory documentation
Keep temporary scene details temporary
A detail can be useful now without being useful later. The café you are sitting in, today’s weather, a temporary shopping list, or an unfinished decision may help answer the current request but become stale quickly. Keep these in the current conversation or project unless you explicitly ask to carry them forward. If they are saved, attach a scope and a review point: for example, “for this trip plan” or “until I choose a laptop.”
This avoids turning a moment into a supposed trait. One request for a quiet café does not prove a permanent preference for quiet places; choosing a bright color once does not establish a lasting aesthetic. The safe design inference is to preserve the user’s words as a scoped fact when needed, not silently generalize them into a personality description.
Google’s Gemini privacy documentation distinguishes saved instructions from past-chat personalization and says saved information can be managed or deleted by the user. It also notes that past-chat personalization may use information from chats. That distinction supports a practical product-design rule: deliberate, editable preferences should be identifiable separately from context drawn from conversation history. Gemini Apps Privacy Hub
Do not infer sensitive traits or save third-party details by default
A memory system should not convert conversational clues into sensitive conclusions. A user’s wording, schedule, purchases, or one-off choices do not justify guessing about personal traits, circumstances, or motivations. Even when an inference sounds plausible, it may be wrong, and a future answer can become awkward or misleading if it is treated as confirmed. Store a user-provided fact only when it has a clear task-related use; do not transform it into a broader claim about who the user is.
Apply similar restraint to information about other people. A project may need a name or role the user has explicitly supplied, but routine conversation should not become a durable dossier about friends, relatives, or colleagues. If a third-party detail is necessary for a specific task, keep it within that task’s scope and avoid unnecessary personal specifics. This is a product-design recommendation derived from minimization, not a claim that every service handles such data in the same way.
Give every memory a scope, source, and review path
A memory is easier to trust when the interface makes clear what it says, where it came from, and where it can be used. A practical memory record might include: the exact user-provided statement; its purpose; whether it applies broadly or only to one project; and an optional review date or condition for removal. For example: “For the balcony garden project, prefers plants that need little watering; review when the plant list is chosen.” This is an illustrative format, not a documented feature of any named product.
Users should be able to inspect, correct, and remove remembered information. They should also be able to distinguish deleting a memory from deleting a chat or changing broader personalization settings. OpenAI’s help documentation explains that saved memories can be separate from chat history, so deleting the originating chat alone may not delete the separate memory. Gemini’s privacy hub likewise describes separate activity controls and saved-info controls. These product examples show why a clear deletion path should explain which layer a control affects. OpenAI memory controls, Gemini Apps data controls
Memory selection is separate from disclosure and settings scope
Choosing what belongs in memory answers one question: which details should persist for future personalization? It does not, by itself, explain what information a service collects, how it handles chats, who may review data, or what account and settings controls apply. Those are separate disclosure and settings-scope questions. A product should describe them separately and accurately rather than suggesting that a small memory list means that no other data is processed.
The distinction matters in practice. Google’s privacy notice describes several categories of information and settings, including saved instructions, activity controls, connected apps, and the use of data to provide and improve services. The exact behavior varies by product and configuration. A memory-selection interface should therefore state what it governs and point users to the applicable privacy and settings information, without implying that it replaces those explanations. Gemini Apps Privacy Hub
A short decision test for each proposed memory
Before saving a detail, ask four questions:
Was it explicitly provided or approved? If it is only an interpretation, do not store it as a fact.
Will it improve a specific likely future task? Name that task; if none comes to mind, leave it out.
What is its proper scope? Use a project boundary for details that do not belong in general personalization.
Can the user review and remove it? If not, the interface should not present it as a simple, user-controlled memory.
For example, in a room-planning project, “The user chose a compact desk for the study” may be useful until the layout is complete. The café visited during the planning session is likely temporary. A guess that the user “always prefers minimalism” should not be saved unless the user explicitly states that preference and wants it used more broadly. These examples apply the decision test; they are not research findings or claims about a particular product.
A restrained memory system does not need to build a complete profile. It should carry forward a few explicit preferences and practical facts that serve chosen activities, keep local details local, and make correction and deletion understandable. The aim is continuity grounded in what the user actually said—not a claim that an AI knows the person behind the conversation.