AI memory: what to verify before you trust it
An AI system that remembers useful context can save time. But the word memory does not tell you what is kept, who can read it, or what happens after you delete an entry. Those are separate questions, and a useful answer should be specific about each one.
Four questions to ask
How does information become a saved record?
Does the system save automatically, after a user action, or through an approval step? Can you see the exact text before it becomes persistent? Does a conversation remain stored even when no memory entry is created?
A confirmation button is meaningful only if the product explains what it confirms: saving an entry, using it in future answers, or both.
How is a saved record used?
Ask which product features can retrieve it and whether it can be sent to an external model provider. A memory panel in the interface does not, by itself, show what enters a model request. Request a clear data-flow explanation for each chief-of-staff route and provider.
Who can read it?
Check access as the record’s owner, another regular member, a workspace administrator, and a support operator. Include search, exports, attachments, logs, and background jobs in the review. A personal-looking interface does not prove personal-only access.
What does deletion remove?
Separate removal from the visible list, the primary database, derived indexes, logs, and backups. Ask how long each copy remains and whether restoring a backup can bring deleted data back.
Confirmation is not an access rule
A product can ask someone to approve a memory and still make that record available to administrators or send it to a model provider. Approval, role-based visibility, model access, and deletion are distinct controls. Verify each one rather than treating a single confirmation step as a complete privacy guarantee.
Make the map testable
For every kind of retained information, record the source, who approves it, what uses it, which roles can retrieve it, and how deletion works. Keep the evidence date and the product version beside the answer. If one part has not been tested, mark that part as unknown instead of filling the gap with an assumption.
What the current Opitor review establishes
Opitor’s public materials describe a Memory feature. The current review has not verified its production creation or approval flow, model access, role-based visibility, or backend deletion, retention, and backup behavior. Screenshots reviewed for this project showed manually entered records; they do not prove an AI-proposed confirmation flow. Do not assume personal-only access, confirm-before-use behavior, or permanent deletion based on those materials.
The same discipline applies to messages: the deployed revision is unknown, and production administrator/non-member checks across all private-message read paths remain pending. The questions and answers page records those current limits.
Where Opitor fits
Opitor’s public materials describe Memory as a product feature, but this review has not established its production workflow or privacy controls. Treat creation, model use, access, and deletion as open verification questions until current product evidence answers them. See the FAQ for the latest documented limits.
Updated 2026-09-25