Separate transcripts, working state, and durable memory
Enterprise AI teams often treat memory as one storage feature, but it serves at least three distinct purposes. A transcript records what the user and model said for debugging, review, or audit. Working state holds temporary information needed to complete a task, such as a ticket identifier, selected filters, or workflow progress. Durable memory carries useful information across sessions, including language preferences, organizational roles, approved constraints, or confirmed facts. Applying one retention rule to all three usually keeps too much data or removes useful state too early.
The first engineering rule is not to promote entire transcripts into long-term memory. Raw conversations routinely contain personal data, confidential business details, speculative statements, and model errors. A safer pattern is to extract candidate memories at a task boundary, then evaluate their type, source, confidence, and intended use. “The user prefers Traditional Chinese” may be an editable preference. “The customer will purchase a product next quarter” should not become a permanent fact unless an authoritative system confirms it.
Build a retention matrix around purpose
Every memory class needs a stated purpose. If the team cannot explain which feature needs a field, who will use it, and when it stops being useful, the field should not be retained by default. Retention periods should reflect business necessity, sensitivity, update frequency, contractual or regulatory obligations, and whether the information can be retrieved again from its system of record.
- Raw transcripts:Keep them briefly when needed for incident investigation, dispute handling, or quality review. Otherwise, delete or de-identify them early.
- Task summaries:Retain only decisions, pending actions, and source references required by the next workflow step. Let them expire when the task is closed.
- User preferences:Language, notification choices, and output formats may live longer, but users should be able to inspect, correct, and clear them.
- Enterprise knowledge references:Store document identifiers, versions, and permission context instead of copying controlled document text into an uncontrolled memory field.
- Uploads and vectors:Files, extracted chunks, summaries, and embeddings must share a lifecycle. Deleting the original while leaving searchable derivatives is incomplete deletion.
- Audit events:Record who performed an action, when it happened, and which policy decision applied without duplicating the full sensitive payload.
Useful metadata for each memory item includes purpose, source, owner, sensitivity, creation time, expiration time, legal-hold status, and policy version. These fields make scheduled deletion and authorization checks enforceable. Expiration should be executed by the system rather than left to occasional manual cleanup. Any extension should have a documented reason, an approver, and a new review date.
Deletion must reach every copy and derivative
A database row marked deleted does not mean the information is gone. One conversation may exist in the primary database, vector store, object storage, search index, cache, analytics pipeline, application logs, and backups. It may also have been sent to a model provider or observability service. The architecture therefore needs a data-flow inventory that names every processor, its retention behavior, its deletion interface, and the boundary of responsibility.
A practical workflow first stops use of the data and then removes physical copies asynchronously. When a deletion request arrives, create a tombstone that immediately excludes the item from application queries, RAG retrieval, and background processing. Then delete the transcript, extracted text, summaries, attachments, vectors, indexes, and caches. If backups cannot be edited record by record, give them a bounded lifetime and reapply the deletion ledger during restoration so erased records do not reappear after disaster recovery.
Keep minimal evidence that deletion completed: a request identifier, scope, completion time, and result for each storage system. Do not preserve the deleted content inside the proof. Legal holds or investigation requirements should be modeled separately from ordinary retention, with restricted access and a recorded justification. When the hold ends, the original expiration policy must resume instead of silently converting the data into permanent storage.
Make retention a testable system capability
Retention and deletion cannot live only in a privacy document. Engineering teams need executable policy rules, scheduled jobs, access isolation, and an operator interface. If users can clear a conversation or disable memory, the interface should explain whether the action merely hides the screen, deletes one transcript, or also removes preferences, uploads, and derived data. Administrators should not receive unrestricted transcript search simply because they operate the system.
Test the lifecycle with a seeded conversation containing an attachment, a summary, and vector embeddings. Locate it in every store, trigger expiration or deletion, and verify that online retrieval stops immediately, background cleanup eventually finishes, failed steps can be retried safely, and restored backups cannot revive the record. When policies change, test how old data is migrated and whether tenant-scoped deletion jobs can ever cross organizational boundaries.
The most reliable starting point is to store less by default, keep raw conversations briefly, and admit only confirmed information with a clear purpose into durable memory. Expand retention later when real workflow failures, support needs, or audit obligations justify it. When an AI system spans LINE, ERP, CRM, cloud platforms, and multiple model providers, an experienced integration team can help enforce one lifecycle policy across every copy rather than only the most visible database.