03 / LONG-TERM MEMORY
Editable AI memory: beyond saving chat history
Editable AI memory is a set of saved facts or preferences a user can inspect, correct and remove. Chat history records what was said; memory supplies selected context for future answers. The product needs explicit rules for saving, using and deleting that context.
Make each memory understandable
Start with facts a person can recognize. In a nutrition-planning example, “I have 15 minutes to prepare lunch” is more useful than a hidden personality score. Do not infer a medical condition or other sensitive profile from a casual conversation.
| Field | Illustrative value | Why it matters |
|---|---|---|
| Preference | Lunch preparation time: 15 minutes | The user can check what is remembered. |
| Source | Confirmed by the user in preferences | A guess is distinguishable from a saved choice. |
| Updated | When the user last changed it | A stale preference can be reviewed. |
| Owner | The signed-in user | Another account must not retrieve it. |
| Controls | Edit · Remove | The user can correct future context. |
Retrieve only the context this answer needs
Keep the canonical preference on an authorized backend, select relevant active facts for each new request, and include them alongside the current question. For a small set of explicit preferences, a structured record can be enough; a vector database is not automatically required.
Decide what happens if a preference changes while a reply is generating. One understandable rule is that an in-flight reply uses the context captured when it started, and the next new reply uses the updated preference. Make that rule clear in your product.
Editing and deleting are product behavior
Changing preparation time from 15 minutes to 5 minutes should affect the next meal suggestion. It should not rewrite a report or message already delivered. Show when a new recommendation uses the updated preference.
Deleting a row from a screen is not the complete deletion behavior. Define how the canonical record, retrieval indexes, cached context and queued requests stop using the fact. Also document what remains in existing messages, backups or provider retention. Do not promise instant deletion from systems you do not control.
Use a small acceptance matrix
- Read: the user can see the preference, its source and its update time.
- Correct: change 15 minutes to 5 minutes; a new request receives the new value.
- Remove: remove the preference; the next request does not retrieve it.
- Separate accounts: another account cannot read or update that memory.
- Preserve history: existing report and reply text remain distinguishable from newly generated advice.
- Resume: reopen the app and confirm that the saved change is present.
The Table Note web demo illustrates correction and a changed next suggestion. Production storage, authorization, retention and deletion are separate implementation and acceptance work to agree in your scope.
For an ongoing AI coach, AppBento starts with A + C + D. Explore the memory example and decide whether personalization is part of the result your users will pay for.
References and scope
The flow and acceptance criteria are AppBento design recommendations. These primary references cover platform boundaries; they are not endorsements or evidence of native acceptance for the web demo.