Persistent AI Memory Needs Deletion Rules, Not Just More Storage

Production AI memory should keep durable state outside the model while giving every stored item an owner, scope, retention rule, revision path and deletion procedure. Extra capacity is useful only if obsolete, unauthorized or sensitive information can be prevented from returning as context.

The practical design is a set of separate stores behind a common policy layer: session state for active conversations, semantic memory for reusable knowledge, workspaces for artifacts and a dedicated vault for credentials. Each category needs its own access, lifecycle and recovery rules; combining them in one searchable archive makes correction, isolation and deletion harder to prove.

Start with boundaries, not a database

Keep agent compute replaceable and externalize anything that must survive it. Google Cloud’s architecture guidance recommends stateless production agents with session state in an external service and persistent external storage for long-term knowledge. This separation also lets storage policy evolve independently of the model runtime.

Classify data by purpose before selecting a database or retrieval engine:

• Session state: messages, tool results and variables required by one thread. Scope it to the tenant, user, agent and thread, with a short default lifetime unless the workflow requires continuity.
• Semantic memory: preferences, decisions, facts and procedures selected for reuse. Store provenance, confidence, effective dates and the source record beside each item.
• Workspace: drafts, code, files and intermediate artifacts. Preserve appropriate file or object versions without automatically promoting every artifact into retrievable organizational knowledge.
• Secrets: API keys, tokens and credentials. Keep values in a vault under narrow, time-bound access; a memory record may contain an opaque secret identifier, never the credential itself.

These boundaries are logical rather than necessarily physical. MinIO’s AIStor Memory announcement presents memory, persistent workspaces and secrets as one externally durable system that outlives an individual sandbox. A unified control plane can simplify operations, but it should not give all three categories identical permissions, retention or retrieval behavior.

Give each memory class a different policy

A useful architecture decision matrix starts with the risk created when each class persists for too long or crosses the wrong boundary:

• Session state: retain for the thread or workflow window; retrieve only within that scope; delete the transcript, tool results and session caches together; recover only when continuity is a business requirement.
• Semantic memory: retain while its purpose and provenance remain valid; revise through versioned replacement; remove canonical and derived representations; recover versions and deletion markers together.
• Workspace: retain under project or records policy; expose through file permissions rather than broad semantic similarity; delete versions, previews and temporary copies; recover directory, ownership and version metadata.
• Secrets: retain according to credential rotation policy; never consolidate into semantic memory; revoke rather than merely hide; recover vault configuration and references, then reissue credentials instead of restoring values into ordinary storage.

Scope must be represented as enforceable metadata, not inferred from prompt text. At minimum, a durable record needs a tenant, subject or user, producing agent, thread or workspace, data class and policy identifier. Records intended for wider reuse should require an explicit promotion step rather than inheriting organization-wide visibility because they were useful once.

Make the full lifecycle an architectural requirement

Memory is a controlled transformation pipeline, not a write-and-retrieve feature. The Oracle Agent Memory technical report describes a lifecycle spanning ingestion, extraction, consolidation, retrieval, summarization, revision and removal, with explicit scope across users, agents and threads.

1. Ingest: validate tenant and user identity, classify sensitivity and attach provenance before accepting a record.
2. Consolidate: deduplicate compatible observations while preserving links to their originals. Keep conflicting claims separate until a rule or authorized reviewer resolves them.
3. Retrieve: enforce authorization before ranking, then filter by scope, validity and freshness. Similarity is not permission.
4. Correct: create a new version, mark the superseded statement inactive and rebuild affected indexes so the old representation cannot continue winning retrieval.
5. Delete: suppress the canonical record immediately where policy permits, then propagate the operation to summaries, vector entries, caches and workspace copies.
6. Audit: record which identity created, read, changed, exported or deleted durable state and which policy authorized the action.

Each transition should be idempotent and observable. If consolidation or indexing stops halfway, a durable job record should identify incomplete derivatives; otherwise the system can leave old and new state active without a reliable way to reconcile them.

Deletion must follow every derivative

A successful delete request is not the same as verified deletion. One statement may exist in a transcript, extracted fact, consolidated summary, embedding index, prompt cache, workspace artifact and backup. Assigning a lineage identifier to every transformation makes those copies discoverable when the canonical record changes.

Model deletion as explicit states: requested, blocked by an authorized legal hold where applicable, removed from online retrieval, propagated to derived stores and verified. A user-facing request may finish after online suppression, but the audit record should distinguish that result from later expiry under backup-retention rules.

Use content-free tombstones when replicas or asynchronous jobs could recreate a removed item. Test the control through every retrieval path, not only the primary database: a missing row proves little if an embedding or cached summary remains eligible for a prompt. The acceptance test should begin with a known retrievable item, delete it, rebuild or replay downstream processing and confirm that no permitted query can restore it.

Restore policy along with the data

Authorization belongs before semantic ranking. Retrieving broadly and filtering afterward can expose text to ranking services, logs or prompts before access is rejected. Depending on the isolation requirement, use tenant-partitioned indexes or resource-level access labels, and evaluate authorization at every handoff in a multi-agent workflow.

Agent identity should remain distinct from human identity. A delegated agent receives only the intersection of its service permissions, the user’s authority and the current task scope. Shared memory does not create shared authority, and promotion from a private thread into team knowledge should be an auditable action.

Backups must preserve the relationships that make memory safe: tenant boundaries, access labels, versions, provenance, lineage and tombstones. Restoring content without deletion markers can resurrect material that policy had already removed. Recovery exercises should therefore confirm that an active thread resumes consistently, authorized knowledge remains retrievable, revoked records stay unavailable and credentials are reissued through the vault rather than copied into ordinary storage.

The final architecture review should require evidence for ingestion validation, scoped retrieval, versioned correction, derivative-aware deletion, durable audit events and tested recovery. Capacity, latency and recall still matter, but they cannot compensate for memory that cannot forget the right information or preserve access boundaries after a failure.