Should AI Companion Memory Be Editable? A Practical Correction Flow for Project Details
Yes. AI companion memory should let people inspect, correct, confirm, and delete ordinary remembered details—and then show how those changes affect later replies. A useful design task is correcting a mistaken project memory, such as an assistant remembering that a photo series is planned for a gallery when the person only said they might submit it. The goal is a visible, low-friction correction flow, not a promise that every remembered detail will always be perfect.
Why ordinary project memories need correction controls
Memory can make an ongoing conversation more useful by carrying forward preferences or project context, so people do not need to repeat them. Current product documentation describes memory as a source of personalization, while also acknowledging that it may not retain every detail or may get details wrong. OpenAI’s memory guide explains that remembered information can come from different sources and that available controls vary. Google’s Gemini memory guide likewise says memory can inform project suggestions and directs users to correct Gemini in chat.
A small error can become a recurring nuisance when a system treats an old possibility as a settled plan. Imagine someone discussing a weekend woodworking project: they considered using cedar, then chose birch. If the companion later suggests cedar finishes as though that choice were final, the problem is not that the system remembered the conversation. It is that the person needs a way to inspect the remembered claim, revise it, and see whether the revision is used.
This is a design recommendation, not a claim that every conversational product already provides the same controls. Microsoft’s human-AI interaction guidance names efficient correction, explanations of system behavior, and communicating the consequences of user actions as separate design considerations. Applied to memory, those principles suggest that a correction should be simple to make and its practical effect easy to verify. Microsoft Research’s human-AI interaction guidelines
What a person should be able to inspect
A useful memory view should present individual claims in ordinary language: “For the desk organizer, you chose birch,” or “You are considering a photo series about neighborhood signs.” It should avoid converting tentative language into certainty. Where the underlying conversation can be shown, a source link or short context preview can help the person tell whether a summary is accurate. The memory view should also make clear that it may be a selective summary rather than a complete record; OpenAI’s documentation explicitly describes its memory summary as high-level and says it may not show every detail or source.
For each item, show its status in a way the person can understand: saved and available for future personalization, awaiting confirmation, corrected, or removed from active use. These labels are a proposed interface pattern. The underlying principle is supported by Microsoft’s guidance to explain why a system acted and to communicate how user actions will affect future behavior. That does not require exposing internal model mechanics. It requires enough information for a person to answer: “What did you remember, and what will change if I edit it?”
A correction flow in five steps
A practical correction flow can start where the error appears. If the assistant says, “Since the gallery submission is next month…,” the person should be able to open the contributing memory or choose a correction action beside the response. A memory explanation should identify the relevant claim without implying that the assistant has perfect access to every reason behind its output. Current OpenAI memory controls may surface sources that contributed to personalization, while noting that sources may not show every factor. OpenAI’s guide to memory sources and corrections
The person then selects the smallest useful action: edit the claim, delete it, or mark it as uncertain. Editing might change “Submitting the series to a gallery” to “Considering whether to submit the series.” Deleting is appropriate when the detail is no longer wanted at all. Uncertainty can preserve useful context without promoting a tentative thought into a firm commitment. That uncertainty option is a design suggestion; it should not be presented as a feature of a named product unless verified there.
Before saving, show the exact revised wording and ask for confirmation when the edit changes meaning or could substantially reshape later suggestions. A small typo fix may not need a separate confirmation step; replacing a firm plan with an open possibility may. This distinction is an inference from correction and disambiguation guidance: Microsoft recommends making correction easy and engaging the user when the system is uncertain about their goal. Confirmation should protect the person’s intended meaning, not add friction to every routine edit.
After confirmation, show a plain result such as: “Updated. I’ll treat the gallery submission as undecided in future project conversations.” If the person deletes the item, say that it was removed from active memory, and make the product’s actual scope clear. Do not say that all traces have vanished unless that is known to be true. Existing systems illustrate why precision matters: OpenAI explains that a saved memory and its original chat can be stored separately, while Gemini’s guide says correcting a remembered detail can be done in chat and that deleting relevant chats may take a short time to affect personalization. Those product-specific behaviors should not be generalized into a universal deletion promise. OpenAI memory guide and Gemini memory guide
Finally, let the person test the change in a natural follow-up. They might ask for finish ideas for the organizer. If the assistant uses birch, the person has a concrete signal that the correction influenced reuse. If it repeats cedar, provide a route back to the memory item or a way to flag the mismatch. The important design choice is to make reuse observable, while avoiding a guarantee that one successful response means the system will never make the same mistake again.
When to edit, delete, or confirm
Use edit when the remembered idea is still useful but its wording or details are wrong: “The shelf is 80 cm wide,” corrected to “The shelf is 90 cm wide.” Use delete when the item should no longer guide future replies—for example, an abandoned project preference. Use confirm when a proposed memory is ambiguous or a change could turn an exploratory comment into a decision. A clear interface should make these actions distinct rather than treating “don’t say that” as identical to “remove the memory.” OpenAI’s documentation makes a similar distinction: asking the system not to mention something changes personalization behavior but does not itself delete the underlying source.
The interface can also offer “not sure” or “ask me next time” for details whose value depends on the moment. For example, someone may usually prefer short captions but want a longer description for a particular portfolio page. This is a proposed way to preserve flexibility, not a verified feature claim. The guiding question is whether the memory expresses a stable preference, a temporary choice, or a possibility that should stay open.
Design for a calm, usable interaction
Keep the correction control close to the memory or response it affects. Use familiar words such as “Edit,” “Delete,” and “Confirm,” and avoid making people compose a special prompt to repair a routine factual mistake. Microsoft’s guidance explicitly calls for efficient correction and granular feedback. Apple’s current generative AI design guidance also recommends making refinement or reversal easy and signaling when a user’s adjustment has taken effect. Apple’s Human Interface Guidelines for generative AI
For consequential edits, offer a concise before-and-after view. Do not silently merge conflicting versions or replace a person’s correction with an inferred preference. If the person says, “I chose birch for this organizer, but I still like cedar for outdoor projects,” preserve the scope of both claims rather than flattening them into a general wood preference. This is a design inference: Microsoft recommends scoping services when uncertain, and its guidance on cautious updates supports avoiding disruptive changes over time.
A lightweight history of changes can help people recover from an accidental edit, especially for project facts they may want to restore. But history should be understandable and under the person’s control. If an interface offers undo, say what it restores and whether the restored claim becomes active again. Apple’s guidance specifically points to undo and clear feedback as useful patterns for refining generated results; applying that pattern to memory editing is a reasonable extension, not a statement that the guideline prescribes a particular memory-history feature.
How to tell whether the flow works
Evaluate the flow with ordinary project scenarios and observable tasks. Can a person find the mistaken detail after it appears in a reply? Can they change “decided” to “considering,” confirm the updated wording, and find out what the system will use next? Can they remove an obsolete choice without confusing that action with asking the assistant to avoid mentioning it once? These are test questions for a proposed design, not reported test results.
A useful review can track whether people complete these tasks, whether they understand the difference between editing and deleting, and whether corrected details are reflected in a later relevant response. It should also check failure paths: the detail cannot be found, two memories conflict, the correction is not yet reflected, or the user cancels before saving. In those cases, the interface should acknowledge the state and offer a clear next step instead of saying “fixed” when it cannot verify the change. This follows from the guidance to make correction efficient and communicate action consequences; the measures themselves are recommendations.
Make memory correctable, then make the correction visible
AI companion memory should be editable because ordinary project details change, and a remembered summary can be incomplete or mistaken. A strong correction flow lets a person inspect a specific claim, edit or delete it, confirm meaning where needed, and see how the change is expected to affect future personalization. The experience earns confidence through visible, accurate feedback about each action—not by implying that memory is infallible or that one correction guarantees every later response will be right.