How Should an AI Companion Explain Its Memory to Users?
When an AI companion saves or uses information about someone, its explanation should let that person answer six practical questions: what could be remembered, where the information came from, whether saving was confirmed, where it may be reused, how long it remains, and how to inspect, correct, or delete it. The useful moment for this explanation is when a memory is suggested, saved, or used. The card below is a design proposal, not a description of controls every app already offers.
What should a memory disclosure tell the user?
A short phrase such as “I’ll keep that in mind” can sound clear while leaving the underlying state uncertain. Does it mean the detail is in the current chat, stored for later, inferred from another source, or simply reflected in the next answer? A useful disclosure names the state and gives the user a way to verify it.
Design the card so each answer is visible near the relevant action. If a detail is merely suggested for saving, label it as a suggestion. If the app cannot confirm that a persistent memory was saved, say that plainly; do not imply a change took place. The wording should match the system’s actual behavior, including any delay or limits the product can substantiate.
The six answers
User question: What can become memory? — What the card should say: The specific detail or a plain description of its category, such as “You prefer short project summaries.” Avoid a vague label like “personalization.”
User question: Where did it come from? — What the card should say: Identify the source: this chat, an older chat, a connected app, or another source the product actually uses. If it is an inference, label it as an inference.
User question: Was saving confirmed? — What the card should say: State whether the item is saved, pending, suggested, or not saved. Present controls for confirmation when the product supports them.
User question: Where may it be reused? — What the card should say: Describe the relevant destinations or contexts, such as future chats or a named connected feature. Do not promise that it stays in one place unless that is true.
User question: How long will it remain? — What the card should say: Give a supported retention period or explain the condition for removal. If timing varies or is unknown, say so and link to the applicable control or policy.
User question: How can I inspect, correct, or delete it? — What the card should say: Link directly to the applicable memory or activity controls, and explain which action changes which copy or source.
This is a proposed interaction pattern. It should not be presented as a universal standard or as a claim that every companion has item-level memory, confirmation, or a fixed retention period. If the product lacks one of these controls, the disclosure should say what is available rather than suggest a control exists.
How are chat history, saved memory, and connected-app data different?
Users need to know which kind of information they are dealing with because the same detail can exist in more than one place. A clear interface separates at least three concepts:
**Chat history** is a record of a conversation. Keeping or deleting that record is one action, and its effect on personalization depends on the product’s design and stated rules.
**Saved memory** is information the product retains or derives for later personalization. It may be connected to prior chats, but it is conceptually different from the visible transcript. The interface should expose the item or explain why it cannot be inspected separately.
**Connected-app source** is information available from another service the user has linked. Disconnecting the service can affect future access, but does not necessarily remove information already copied, summarized, or included in chat activity.
These distinctions matter in actual product controls. Google’s Gemini Apps Help says that deleting past chats may take a short time to stop their use for personalization, and describes deleting or correcting information associated with past chats. For information remembered from a connected app, it says users may need to delete relevant chats and disconnect the app; doing only one may leave another source available. These are descriptions of Gemini’s controls and behavior, not universal rules for AI companions ([Gemini Apps Help: memory of past chats](https://support.google.com/gemini/answer/16598469?co=GENIE.Platform%3DDesktop&hl=en)).
Google’s separate Connected Apps help page also says disconnecting an app or deleting data in that app does not delete Gemini Apps Activity, and deleting Gemini Apps Activity does not delete data in other services. This illustrates why a disclosure should identify the source and the affected copy rather than use a generic “delete memory” label ([Gemini Apps Help: Connected Apps](https://support.google.com/gemini/answer/16836988?hl=en)).
What does a source-specific explanation look like?
Consider this fictional example: Riley tells a companion in a chat, “I’m planning a weekend in Portland,” and has also connected a calendar containing a Portland event. The companion later uses both the chat and calendar context to suggest an itinerary. Riley deletes the chat. If the calendar remains connected, the event can still be an independent source of information; deleting the conversation does not logically mean that the calendar event was deleted too. This example illustrates source separation. It does not claim that any particular product stores or reuses this fictional information in that way.
A useful disclosure in this situation would name the sources separately: “This suggestion used your past chat about Portland and an event available from your connected calendar.” If Riley removes the chat, the interface should report the status of that chat-related source and explain whether the calendar connection remains available. If the product cannot tell whether a source was used, it should not state that it was.
The same rule applies to correction. If a user says, “That event is not mine,” the interface should identify whether the correction updates a saved memory, changes how a chat is used, or leaves the connected calendar untouched. A correction in one layer should not be described as correcting all sources unless it actually does.
Why is “I remember you” not enough?
Suppose an app replies, “I remember you,” but cannot show a saved item, identify a source, confirm a persistent state, or explain how the user can change it. That wording may be conversational, but it is not evidence that a memory was saved. It could describe the current chat context, a generated response, or a persistent record; without state information, the user cannot distinguish among them.
For designers, this is a useful negative case: do not let friendly language stand in for a receipt. After an action, show an explicit status such as “Saved,” “Not saved,” or “Couldn’t confirm,” but use only statuses the system can verify. Include a route to inspect the item where available. If there is no separate memory record the user can inspect, explain what the phrase means in that product and where its supporting information is managed.
How should users check and manage a memory?
When a companion refers to a detail unexpectedly, the user should be able to follow a short diagnostic sequence:
**Ask what information was used.** Request the specific detail and its source. Treat the response as an explanation to check against the product’s controls, not as proof by itself.
**Open the named source.** Check the relevant conversation, memory settings, activity history, or connected-app settings. Do not assume these are the same record.
**Correct the right layer.** If the saved detail is wrong, edit or remove it in the memory controls when available. If the information comes from a connected service, review that connection or the original item as well.
**Verify the outcome.** Look for a state change or confirmation. If the product cannot confirm a deletion or correction, it should say so and describe any delay or limitation documented for that action.
The controls available will differ by product. Gemini’s help pages, for example, describe turning past-chat memory on or off, finding and deleting past chats, and correcting information directly in a chat. They also explain that connected-app data and Gemini activity have separate management paths. These examples are useful because they make the source distinctions concrete; they should not be copied as a promise that another app has the same settings.
Put the explanation beside the memory action
A six-answer card works best when it appears at the moment the user needs it: before confirming a suggested memory, after a save, or when a response uses information from a past chat or connected app. Keep the status concise, name the source in familiar language, and link the user to the control that changes the relevant record. Where retention or reuse is not precisely known, describe the uncertainty instead of inventing a duration or guarantee.
The test is simple: after reading the explanation, can the user identify what information is involved, where it came from, whether it was actually saved, where it may be used, what keeps it available, and how to change it? If not, “I remember you” is only a phrase. A useful disclosure makes the product’s actual state understandable and gives the user a practical next step.