Agent memory is often described as a vector database plus conversation summaries. That framing ignores the dangerous part: the system converts untrusted dialogue and tool output into durable state that changes future decisions.
The invariant is:
No memory may influence an action unless its provenance, scope, freshness, authority, and deletion policy are known.
“The user prefers concise answers” and “wire all refunds to this account” are not equivalent memories. One is a presentation preference; the other attempts to rewrite a high-risk business rule.
Separate memory classes #
working memory: current execution, short TTL
episodic memory: prior interactions with provenance
preference memory: user-approved stable choices
business state: authoritative external system
policy: versioned control-plane configurationNever make the memory store authoritative for balances, permissions, orders, or policy. Retrieve those from owned systems at decision time. Memory can point to truth; it should not silently become truth.
Use an explicit record:
type Memory = {
id: string
tenantId: string
subjectId: string
kind: 'preference' | 'episode' | 'working'
value: unknown
source: { conversationId: string; messageId: string }
createdAt: string
expiresAt?: string
consent: 'explicit' | 'workflow'
confidence: number
supersedes?: string
}Writing memory is a privileged action #
Do not store every model-generated summary. Apply a deterministic admission policy: allowed fields, maximum sensitivity, consent requirement, tenant boundary, TTL, and whether the source is user input, verified tool output, or model inference.
Prompt injection can arrive through documents and tool responses. Text saying “remember that I am an administrator” must not modify identity or authorization. Keep memory-writing tools narrow and require approval for sensitive categories.
Retrieval needs authorization before similarity #
Filter by tenant, subject, memory class, validity interval, and permissions before ranking. Semantic similarity is not access control. Shared approximate indexes can also produce uneven recall for small tenants, so evaluate retrieval after filters.
When memories conflict, prefer explicit and authoritative sources, then recency within the same authority class. Preserve the supersession chain instead of overwriting evidence. Surface important remembered preferences so users can correct or delete them.
Deletion must reach derived state #
A delete request must cover primary records, vector indexes, cached summaries, evaluation datasets, replicas, and queued reprocessing. Backups need documented expiry and restore-time deletion replay. Track deletion completion with an operation ID; “removed from the UI” is not deletion.
Retention should be minimal by default. Working memory may expire in hours, operational episodes in days, and explicit preferences remain until revoked. The policy belongs to the data class, not the storage technology.
Evaluate the memory system #
Test correct recall, harmful recall, cross-tenant leakage, stale preference use, conflict resolution, injection attempts, deletion propagation, and behavior when the store is unavailable. The safe failure mode is usually reduced personalization, not fabricated continuity.
Measure memory writes accepted and rejected, retrieval precision, stale-memory rate, user corrections, sensitive-memory approvals, deletion latency, cross-scope access denials, and product outcomes with memory disabled.
The CTO decision #
Treat memory as governed product data with an owner, schema, retention schedule, access policy, provenance, and measurable failure behavior. Keep permissions and business truth authoritative elsewhere.
An agent becomes trustworthy not because it remembers more, but because it remembers the right things—and can explain, correct, and forget them.