# Personal AI Assistant Memory: Corrections, Provenance and Migration Build personal AI assistant memory that preserves corrections, tracks provenance, imports only supported context, and stays accurate across new calls\. Published: 2026-10-12T14:36:37.009Z Updated: 2026-10-12T14:36:37.009Z Canonical: https://realtimeavatar.ai/blog/personal-ai-assistant-memory-correction-migration Markdown: [en](https://realtimeavatar.ai/blog/personal-ai-assistant-memory-correction-migration.md) Personal AI assistant memory needs a correction policy, not just more history. Store selected facts with their source, scope and validity; make explicit corrections supersede obsolete versions; and rebuild each new call's context from current records. Treat migration as importing evidence for review, not transferring permissions or guaranteed understanding. The lifecycle below is an application design recommendation, not a Realtime Avatar memory feature. ## Separate history, saved memory and call context History records what someone said. Saved memory records what your application currently treats as useful and valid. Call context is the smaller selection supplied for one interaction. Keeping these separate lets you preserve an earlier conversation without treating every sentence in it as current advice. For example, an assistant's suggestion to try morning meetings is not a user preference. Neither is a quoted colleague's schedule. Attribute statements to their speaker, distinguish inference from confirmation, and provide an inspectable source. A fluent explanation of where a memory came from is not provenance unless it matches a stored reference. ## Follow one preference through import and correction Consider fictional user Mara. She imports an older conversation saying, 'I prefer morning meetings.' Your application creates a candidate preference linked to that import batch and message, rather than immediately adding it to every call. Mara reviews it and confirms that it applies to work meetings. Later she says, 'From Monday, remember that I prefer afternoon meetings for work.' Confirm the intended Monday and whether this replaces the general preference, rather than describing one appointment. The saved record now needs an effective date as well as a write time: a future change should not silently rewrite today's preference. - Identity and scope: Mara's account, work context and the stable meeting-time preference key. - Evidence: source message, import batch, source time when known, and when Mara confirmed the preference. - Validity: morning or afternoon, effective interval, revision, and whether it is active, superseded or deleted. - Lineage: which prior revision this replaces and which summaries or search entries derive from it. Unknown source dates remain unknown. ## Correct the record without reviving stale copies Use one authoritative record per scoped preference. The following sequence is a recommended backend policy; asking a model to favor recent text is not equivalent. 1. Authorize the edit for the signed-in account. Compare the expected revision and commit the replacement plus supersession atomically. If another device already edited it, show the conflict rather than silently overwriting it. 2. Invalidate derived summaries and cached selections. Filter retrieval against authoritative validity before supplying context; an old search entry must not win because its wording is similar. 3. Prevent re-import and delayed extraction from promoting the old morning preference. Compare their source lineage with corrections, not their arrival time. Ambiguous imports remain candidates for review. 4. Confirm persistence before saying 'saved.' If the response is lost, reconcile the same operation identity instead of guessing whether the edit committed. Display the saved value, effective date and revision. On Monday's new call, select the afternoon revision. Exclude obsolete preference passages from replayed context, or explicitly label them historical when the user asks about the change. Import text stays untrusted data: it cannot rewrite server instructions. Keep enough provenance to explain the correction without repeatedly forwarding the original private conversation. ## Migration transfers particular artifacts, not an assistant Google's Gemini import page, checked October 12, 2026, illustrates two distinct paths. Memory import uses a summary of preferences and style generated in the previous app, then pasted into Gemini. Chat-history import uses an exported ZIP. Neither description establishes that another product will interpret every imported preference identically. The same page states these specific exclusions. They are Gemini's documented boundaries, not universal rules for other providers. - Project files cannot be imported through this flow. - Images generated in the previous app are not included in imported chat history. - Files generated in the previous app are not included either; the history transfer carries chat text. Google notes that compatibility and availability vary. This is evidence of a product surface, not universal portability or a privacy endorsement. For your importer, preview accepted, skipped and unresolved material. Keep imported summaries separate from user-confirmed facts, exclude credentials and unapproved work data, and report missing attachments rather than presenting a complete transfer. - [Google Gemini: import memories, chat history and documented exclusions](https://gemini.google/import-memory/) ## Make deletion propagate through your own copies If Mara deletes the preference, removing one row is insufficient while a summary can recreate it. Define whether the request also removes source history, then invalidate dependent summaries, indexes, caches and pending extraction work. Use a minimal deletion marker to reject late jobs without keeping the deleted preference text; disclose the marker's retention. Recheck deletion state when a job commits, not only when it starts. An already-running call may still contain supplied context. Do not claim it forgot instantly: stop using that session if you cannot reliably withdraw the context, then start fresh with a rebuilt selection. Track deletion failures and disclosed backup expiry separately from successful removal from active memory. ## Keep the live-call boundary explicit Realtime Avatar manages speech recognition, language-model responses, speech synthesis and video. Your server supplies instructions and selected context. Your application owns durable memory, permissions, execution and background tasks; RTA does not host your tools. New calls do not automatically inherit personal memory. Tools have a 2.5-second deadline with cooperative cancellation: a handler can still commit after its result is discarded. Slow imports therefore need app-owned durable work and an honest pending state. External language-model endpoints require workspace approval and a host allowlist. The public SDK does not accept arbitrary live audio from your own speech service. - [Realtime Avatar Calls: server-owned instructions and context](https://realtimeavatar.ai/docs/sessions) - [Realtime Avatar Tool calling: execution, deadlines and transcript delivery](https://realtimeavatar.ai/docs/tool-calling) ## A practical memory test matrix Run these cases against storage, assembled context and visible confirmation. They are acceptance criteria, not reported benchmark results. - Import the same archive twice: no duplicate active preference; provenance still identifies the batch. - Correct morning to afternoon: Monday's context contains the applicable revision, while Sunday's follows the earlier interval. - Deliver an old transcript after correction: it cannot promote morning back to active memory. - Race two device edits: one stale revision is rejected or explicitly reconciled; neither silently wins. - Delete during extraction: the late job cannot recreate the preference, and the next context excludes it. - Start a new call after a dropped save response: read authoritative state; report unknown if that read fails. - Import text claiming permission to access another account: no tool authorization or cross-account memory access changes. ## Frequently asked questions ### Will reconnecting reload a corrected preference? Do not assume transport recovery rebuilds context. For a new call, your server must select current memory again. Distinguish a saved edit from its application to the current conversation; 'saved for future calls' is more accurate when the running session still holds the previous context. ### Does deleting an imported chat erase its original copy? Do not promise that. Google's page describes deletion of an imported chat or import batch in Gemini, not deletion at the originating provider. Explain each system's scope and any separate user action needed. Your own derived preferences also need an explicit deletion policy. ### Can imported preferences grant tool access? In this design, no. Keep authorization outside memory. A remembered request to manage meetings cannot establish account ownership or authorize calendar writes. Reauthorize integrations separately and require explicit scope before carrying work preferences into a personal assistant. ### Does disabling transcript delivery mean nothing is retained? No. RTA's optional signed post-call transcript delivery is separate from operational diagnostics. Private session logs can contain conversation text and have a 30-day storage lifecycle. Other records and provider processing have separate retention rules. Do not use diagnostics as your application's memory store. Start with one inspectable preference and prove its correction survives the next call. Then use the Calls documentation to connect that memory policy to a live conversation. - [Review Realtime Avatar privacy and retention boundaries](https://realtimeavatar.ai/privacy) - [The broader personal-agent idea: give your agent a face](https://realtimeavatar.ai/blog/give-your-personal-agent-a-face)