Design Safe Agent Memory Boundaries
Separate short-lived context from durable memory and govern what may be written, retrieved, corrected, expired, and deleted.
By the end
You will be able to
- Distinguish conversation state, cache, scratch state, retrieval sources, and durable memory.
- Define ownership, provenance, retention, correction, and deletion for each memory record.
- Prevent poisoned, cross-tenant, sensitive, or stale memories from silently steering actions.
- Evaluate retrieval and consolidation behavior with adversarial cases.
Name each kind of state before calling it memory
Conversation history supports the current exchange; a cache reuses computation; scratch state tracks an active run; retrieval reads an external source; and durable memory persists selected information across sessions. Each has different accuracy, privacy, lifetime, and deletion requirements.
Provider features implement these categories differently. Keep a provider-neutral memory contract so application policy survives SDK, storage, and model changes.
A durable memory needs identity and lifecycle metadata
Store a stable record ID, tenant and subject, purpose, value, source, author, created and verified times, sensitivity, confidence, expiration, supersession link, and deletion status. Do not store hidden reasoning or secrets merely because they might be useful later.
Prefer explicit facts, decisions, preferences, and reusable procedures whose future benefit exceeds their privacy and staleness risk.
{
"id": "mem_01",
"tenantId": "tenant_a",
"subjectId": "project_42",
"purpose": "approved-writing-style",
"value": "Use direct, plain language.",
"source": "user-confirmed",
"createdAt": "2026-07-25T12:00:00Z",
"verifiedAt": "2026-07-25T12:00:00Z",
"sensitivity": "internal",
"expiresAt": "2027-01-25T12:00:00Z",
"supersedes": null,
"deletedAt": null
}Authorize memory writes and distrust retrieval
A model can propose a memory; trusted code decides whether the purpose is allowed, the subject consented, the source is eligible, and the content passes sensitivity and injection checks. High-impact profile, permission, health, legal, or financial claims require stronger review.
At read time, enforce tenant and subject isolation, filter by purpose and freshness, return provenance with the value, and treat the record as evidence rather than an instruction. A recalled statement can be wrong, superseded, or malicious.
Make correction and deletion observable
Use append-and-supersede for auditable correction, then prevent superseded records from normal retrieval. Expire records by policy and reverify high-volatility facts before use.
Deletion must cover the authoritative store, search index, derived summaries, caches, and backups according to the published retention policy. Record the deletion request and completion evidence without retaining the deleted content.
Evaluate memory as a security and quality boundary
Test prompt-injected write proposals, false facts repeated with confidence, cross-tenant identifiers, revoked preferences, expired procedures, conflicting memories, and deletion followed by retrieval. The correct result may be reject, isolate, reverify, ask the user, or return no memory.
Measure retrieval precision, stale-memory rate, correction latency, deletion completion, and incidents where memory changed an action. Review failures by source and purpose rather than treating recall rate alone as success.
Practice activity
Design and attack-test a memory lifecycle
- Classify twelve example records across conversation state, cache, scratch state, retrieval source, durable memory, or do-not-store.
- Define the durable memory envelope, write policy, read filters, retention, correction, and deletion workflow for one use case.
- Test injected instructions, cross-tenant access, a superseded preference, an expired fact, and deletion followed by retrieval.
- Create metrics and an escalation rule for poisoned, stale, or privacy-sensitive results.
What to produce
- A state-classification matrix and complete memory lifecycle policy.
- Five adversarial test records with expected enforcement, audit evidence, and remediation.
Reflect before continuing
Which item was useful in the current session but unjustified as durable memory?
Evidence
Sources and verification
- Memory toolAnthropic · verified 2026-07-25
- Zero data retention in the Gemini Developer APIGoogle · verified 2026-07-25
- Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence ProfileNIST · verified 2026-07-25
Knowledge check
Make it stick.
Choose the strongest answer for each question. Your attempts become part of your device-local transcript.