Retention and Deletion Policies for Agent Memory

Give transcripts and memories separate clocks

A transcript containing a temporary customer escalation and a memory saying who owns that customer need different deadlines. Extracting the second does not make it harmless or permanently useful. Specify a purpose, owner and expiry trigger for each retained artifact, including memories produced by merging earlier entries.

For a pilot, the following is a proposed operating policy, not a vendor default or legal retention schedule:

• Raw turns: delete after successful extraction, with a hard maximum of 24 hours after capture even if extraction fails.
• Personal memories: expire after 90 days unless the person explicitly reviews and renews them.
• Shared operational memories: review every 90 days; give incident details and temporary assignments a shorter deadline tied to their purpose.
• Deletion receipts: keep identifiers, outcomes and timestamps for 90 days without retaining memory text.
• Recovery copies: define a separate maximum backup lifetime, such as 30 days, and verify it against every recovery tier.

Adjust these example periods to the actual work. A durable deployment decision can justify a longer reviewed lifetime than a teammate’s travel dates. For admission criteria, use what an agent should remember and forget.

Make extraction failure end in expiry

Model the transcript pipeline as captured, extracting, extracted or expired. Successful extraction should trigger raw-turn deletion only after the resulting memories are durably saved. Failed extraction can retry within the capture deadline; reaching that deadline should discard the turns and record the failure. An unavailable model must not silently turn a one-day staging buffer into a permanent conversation archive.

Keep source identifiers and derivation links without keeping the original transcript body. If one turn produces three memories, record all three relationships. If several memories merge, preserve their lineage so a later deletion request can find the affected result. Delete the intermediate prompt and model output too if your worker persisted them for debugging.

Check the agent’s own storage separately. Claude Code’s memory documentation explicitly excludes auto-memory files from transcript retention cleanup: its memory index and topic files remain until edited or deleted. Clearing transcripts therefore cannot serve as the deletion procedure for everything a coding agent learned.

Enforce expiry during recall and cleanup

Assign an absolute expires_at when writing a memory. Do not extend it merely because retrieval found the entry: a frequently recalled but obsolete incident workaround would otherwise live indefinitely. Renewal should require an owner’s decision or a documented update rule. A merge should preserve the earliest applicable deadline unless someone explicitly authorizes a new retention purpose.

Every list, direct read and search path should exclude expired entries before returning content. Run a separate deletion worker to remove them. For your own Postgres store, assume an agent_memory table with id, workspace_id and timestamp-valued expires_at columns. This parameterized statement deletes expired entries for the workspace bound to $1:

DELETE FROM agent_memory
WHERE workspace_id = $1
  AND expires_at <= CURRENT_TIMESTAMP
RETURNING id;

PostgreSQL’s DELETE documentation confirms that WHERE selects rows and RETURNING reports those actually deleted. Record deletion work durably in the same transaction, then retry external index cleanup until acknowledged. Treat the example as one database operation, not a complete deletion service.

Delete the fact wherever it can return

A request to forget a customer contact must reach more than one Markdown path. Your deletion inventory should include extracted entries, merged summaries, embeddings, search documents, cached recall responses and exported memory files. Track the customer or person described by a memory separately from its author: deleting only entries written by that person misses facts colleagues recorded about them.

Close the extraction race before removing records. Register the deletion request and reject writes derived from affected source identifiers; then cancel or drain queued work and delete the derivatives. Otherwise a delayed worker can recreate the memory after the deletion endpoint reports success. Keep minimal suppression records for the retry and recovery window, with their own expiry and access controls.

Define the limit for running sessions too. A central deletion cannot retract text already delivered into an agent’s conversation. Where removal from active use matters, terminate affected sessions, clear managed local copies and start fresh ones. Report unmanaged exports or copies as unresolved rather than claiming that an empty search result proves complete deletion.

Assign deletion rights before offboarding

For a custom memory service, a reasonable policy lets people delete their own personal entries, gives designated maintainers authority over shared entries and reserves bulk workspace deletion for administrators. Enforce that policy in the service using authenticated identity and workspace ownership. An instruction asking the agent to seek permission is insufficient enforcement.

Offboarding needs two independently recorded outcomes: access revoked and retained memory resolved. Disable the departing person’s access and capture jobs first. Delete their personal memory according to the declared departure rule; do not automatically promote it into team memory. For shared entries they authored, assign a new accountable owner and review the contents, especially personal details and temporary responsibilities.

Require an owner and deadline for any retention exception. Have the offboarding ticket enumerate managed laptops, VM volumes and CI artifacts that received memory exports. The distinction between authorship and ownership belongs in the initial design; team memory versus personal memory explains that boundary.

Publish a separate recovery-copy deadline

State when recall stops, when active copies are removed and when the last recovery copy expires. PostgreSQL’s vacuuming documentation explains that DELETE does not immediately remove an old row version; VACUUM later removes dead versions and makes space reusable. From that distinction, do not infer that a successful DELETE proves physical erasure across storage and backups.

Object versions need explicit attention. AWS documents that a simple DELETE in a versioning-enabled S3 bucket adds a delete marker while earlier versions remain. Permanent version deletion or noncurrent-version lifecycle expiry is a separate operation. If transcripts or database dumps land there, verify those version rules rather than testing only whether an ordinary GET returns the object.

Keep backups inaccessible to agent recall. Before restoring service from an older backup, replay applicable deletion records, enforce current expiry and rebuild indexes from the filtered data. Test the oldest permitted restore point. A deletion receipt should distinguish active-store completion from pending backup expiry and name the remaining deadline.

Managing memory deletion with SPYN3

SPYN3’s opt-in context layer exposes context_delete; deletion needs the separate write:memory key permission, and every memory write is audit-logged. Automatic capture is separately opt-in and requires the workspace’s own model key. Raw turns are deleted after extraction; extracted memories remain. These facts describe extraction cleanup, not a configurable retention schedule or guaranteed backup-erasure deadline. Establish those requirements before enabling capture, and include agent-local copies in your deletion procedure.

Prove forgetting with a controlled memory

Create a synthetic memory containing a unique phrase, derive a summary from it and let one extraction job pause before committing. Delete the source, resume the worker and verify that the phrase cannot return through listing, direct reads, text search, semantic search where enabled or managed local memory files.

Repeat after expiry, after offboarding and after restoring a backup. Start fresh agent sessions so earlier conversation context cannot confuse the result. Track the oldest overdue transcript, overdue memory count, unresolved deletion jobs and time until backup expiry. Assign an operator when any deadline is missed. Keep the test phrase and identifiers in the verification record; leave real conversation bodies out of it.