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. In production environments, engineers must account for token utilization patterns, context window pressure, and deterministic execution boundaries. When system constraints or rate limits are approached, explicit retry strategies with exponential backoff and jitter prevent cascading failures across downstream dependencies.
Provider features implement these categories differently. Keep a provider-neutral memory contract so application policy survives SDK, storage, and model changes. In production environments, engineers must account for token utilization patterns, context window pressure, and deterministic execution boundaries. When system constraints or rate limits are approached, explicit retry strategies with exponential backoff and jitter prevent cascading failures across downstream dependencies.
{
"contractVersion": "1.0",
"executionBoundary": "bounded-task",
"inputValidation": {
"maxTokens": 4096,
"allowedModalities": ["text", "json"]
},
"outputSchema": {
"type": "object",
"required": ["status", "evidence", "confidence"],
"properties": {
"status": { "type": "string", "enum": ["verified", "rejected"] },
"evidence": { "type": "array", "items": { "type": "string" } },
"confidence": { "type": "number", "minimum": 0.0, "maximum": 1.0 }
}
}
}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. In production environments, engineers must account for token utilization patterns, context window pressure, and deterministic execution boundaries. When system constraints or rate limits are approached, explicit retry strategies with exponential backoff and jitter prevent cascading failures across downstream dependencies.
Prefer explicit facts, decisions, preferences, and reusable procedures whose future benefit exceeds their privacy and staleness risk. In production environments, engineers must account for token utilization patterns, context window pressure, and deterministic execution boundaries. When system constraints or rate limits are approached, explicit retry strategies with exponential backoff and jitter prevent cascading failures across downstream dependencies.
{
"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. In production environments, engineers must account for token utilization patterns, context window pressure, and deterministic execution boundaries. When system constraints or rate limits are approached, explicit retry strategies with exponential backoff and jitter prevent cascading failures across downstream dependencies.
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. In production environments, engineers must account for token utilization patterns, context window pressure, and deterministic execution boundaries. When system constraints or rate limits are approached, explicit retry strategies with exponential backoff and jitter prevent cascading failures across downstream dependencies.
{
"contractVersion": "1.0",
"executionBoundary": "bounded-task",
"inputValidation": {
"maxTokens": 4096,
"allowedModalities": ["text", "json"]
},
"outputSchema": {
"type": "object",
"required": ["status", "evidence", "confidence"],
"properties": {
"status": { "type": "string", "enum": ["verified", "rejected"] },
"evidence": { "type": "array", "items": { "type": "string" } },
"confidence": { "type": "number", "minimum": 0.0, "maximum": 1.0 }
}
}
}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. In production environments, engineers must account for token utilization patterns, context window pressure, and deterministic execution boundaries. When system constraints or rate limits are approached, explicit retry strategies with exponential backoff and jitter prevent cascading failures across downstream dependencies.
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. In production environments, engineers must account for token utilization patterns, context window pressure, and deterministic execution boundaries. When system constraints or rate limits are approached, explicit retry strategies with exponential backoff and jitter prevent cascading failures across downstream dependencies.
{
"contractVersion": "1.0",
"executionBoundary": "bounded-task",
"inputValidation": {
"maxTokens": 4096,
"allowedModalities": ["text", "json"]
},
"outputSchema": {
"type": "object",
"required": ["status", "evidence", "confidence"],
"properties": {
"status": { "type": "string", "enum": ["verified", "rejected"] },
"evidence": { "type": "array", "items": { "type": "string" } },
"confidence": { "type": "number", "minimum": 0.0, "maximum": 1.0 }
}
}
}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. In production environments, engineers must account for token utilization patterns, context window pressure, and deterministic execution boundaries. When system constraints or rate limits are approached, explicit retry strategies with exponential backoff and jitter prevent cascading failures across downstream dependencies.
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. In production environments, engineers must account for token utilization patterns, context window pressure, and deterministic execution boundaries. When system constraints or rate limits are approached, explicit retry strategies with exponential backoff and jitter prevent cascading failures across downstream dependencies.
{
"contractVersion": "1.0",
"executionBoundary": "bounded-task",
"inputValidation": {
"maxTokens": 4096,
"allowedModalities": ["text", "json"]
},
"outputSchema": {
"type": "object",
"required": ["status", "evidence", "confidence"],
"properties": {
"status": { "type": "string", "enum": ["verified", "rejected"] },
"evidence": { "type": "array", "items": { "type": "string" } },
"confidence": { "type": "number", "minimum": 0.0, "maximum": 1.0 }
}
}
}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 account transcript.