Modern digital workspace representing structured AI memory data

Long-term memory for conversational AI is often introduced as a simple collection of key-value facts. Over time, product teams add confidence, provenance, expiration, user correction, language variants, privacy labels and retrieval rules. A schema migration that ignores those semantics can make the system remember stale information, misread a preference as a fact or restore data a user deleted. Memory storage needs the same discipline as any other stateful production system, with extra attention to meaning and consent.

1. Model memory items as typed records

Give each memory item a stable identifier, type, value, source, creation time, last-confirmed time, retention rule and deletion state. Distinguish facts, preferences, intentions and inferences. “The user lives in Kyoto” should not be stored the same way as “the user may travel to Kyoto next month.” A typed record lets retrieval logic treat uncertainty and time differently instead of relying on a prompt to infer the distinction later.

Provenance matters because a fact may come from an explicit user statement, a connected service, a generated summary or a model inference. Store the source category and the evidence needed to explain the memory. Avoid retaining more original conversation text than necessary; a minimal reference or user-approved summary may be sufficient.

2. Use expand-migrate-contract for schema changes

Do not change the meaning of a field in place while old workers still write the old format. First add new fields and make readers tolerate both versions. Then migrate existing records in controlled batches, record progress and compare old and new retrieval behavior. Only after the new format is stable should the system stop writing the old representation.

Each migration should be idempotent and restartable. Track a migration version on each record or partition. If a batch fails halfway through, rerunning it should not duplicate memories or overwrite a newer user correction. Keep a rollback plan for schema code, but do not blindly roll back user data after the user has made a newer choice.

3. Treat deletion as a tombstone with defined propagation

Deleting a memory item is not the same as setting its value to an empty string. A tombstone or equivalent deletion marker can prevent an older replica or backup process from reintroducing the record. Define how deletion propagates through summaries, vector indexes, caches, derived profiles and asynchronous jobs. The system should distinguish an item that never existed from one that was intentionally removed.

Test deletion during an active conversation, during a migration and while background summarization is running. If a job started before deletion, it should check the current deletion state before writing its output. A successful UI response should correspond to a verified backend state, with a clear explanation of any copies that must expire or be retained for a lawful reason.

4. Keep retrieval compatible with uncertainty

When memory schemas change, retrieval may silently select different fields or rank records differently. Build golden tests for common questions and edge cases: stale preferences, conflicting facts, ambiguous pronouns, low-confidence inferences and corrected information. Compare not only whether the right item was retrieved, but whether the generated answer expressed the right level of certainty.

Use a fallback path when a record cannot be parsed. Failing open by turning malformed metadata into a confident statement is risky. Failing closed may be better for identity-sensitive claims, while a low-impact preference can be ignored and asked again. Make the policy explicit by memory type.

5. Observe migration without exposing contents

Track migration completion, parse failures, duplicate IDs, retrieval regressions, deletion propagation lag and unexpected memory resurrection. Prefer counts and anonymized record identifiers over raw memory text. If an incident requires payload inspection, use controlled access with a reason, time limit and audit record.

Separate technical schema version from product policy version. The database may support a new field before the application is ready to use it. Keeping those versions distinct allows teams to roll out code safely and explain why a memory is retained or retrieved.

6. Add memory semantics to release gates

Before deployment, verify that the new schema preserves user corrections, expiry, opt-out and deletion. Test an old record through the new reader, a new record through the old worker if coexistence is expected, and a deletion event through every asynchronous path. Measure whether answer quality changes for a stable evaluation set. If a migration changes user-visible behavior, document it and provide controls that let users inspect and correct the result.

NIST’s Generative AI Profile recommends lifecycle risk management for generative systems. Applying that idea to memory infrastructure means treating schema changes as product changes, not just database maintenance. Typed records, explicit provenance and deletion semantics keep long-term memory useful without making it irreversible or mysterious.

7. Define migration acceptance criteria

Before release, set explicit pass conditions: no deleted test fact reappears, no newer correction is overwritten, all supported record versions can be read, and retrieval quality remains within an agreed tolerance. Run the tests against a copy of representative data, including malformed records and records with missing optional fields. Measure both migration completion and the user-visible behavior after migration. If a record cannot be converted safely, route it to a review queue rather than silently dropping its provenance. A migration dashboard should show progress, errors and rollback readiness, while avoiding raw memory content in broad operational views. These controls make schema evolution measurable and reduce the chance that a database change becomes a trust incident.

Sources