Your AI Agent Needs a Memory Policy, Not Just a Vector Database

An assistant remembers that a project uses PostgreSQL. Two months later, the team migrates to a different database. The assistant continues producing PostgreSQL-specific deployment advice because the old fact is an excellent semantic match for the new question.

Nothing has gone wrong with nearest-neighbor search. The system retrieved the wrong version of the truth.

Now consider a more consequential variation: an assistant stores a statement from an untrusted document and later treats it as permission to take an action. The memory is relevant. It is also unauthorized.

These illustrative scenarios suggest a better starting point for agent memory: not “what can we store?” but “under what conditions may stored information influence a future decision?”

Why this matters now?

On September 23, 2026, Google DeepMind described an upcoming persistent-memory capability for Private AI Compute. Its announced design combines protected cloud execution with encrypted storage and device-derived key control to support continuity across devices. The announcement describes how the capability will work; it should not be read as proof that it is already generally available across every product. [1]

A different September development highlights the behavioral risk. A preprint submitted on September 12 studies persistent memory poisoning: malicious content from an external source is stored and later influences another session. The authors evaluated particular agent configurations, so the work is a warning about a failure mode, not a universal estimate of deployed-agent compromise rates. [2]

Read together, these developments point to two separate requirements. Protecting memory from unauthorized readers is one. Preventing an authorized agent from trusting the wrong remembered content is another. Encryption does not, by itself, determine whether a stored claim is true or whether it authorizes an action.

Separate context, checkpoints, and durable memory

Start with three distinct jobs.

The current context is what the model sees while responding. A checkpoint preserves execution state so a workflow can resume. Durable memory carries selected information into future interactions. LangGraph's documentation makes a related distinction between thread-scoped checkpointers and cross-thread stores. [3]

Do not turn every checkpoint into a reusable user fact. An unfinished tool result, a rejected plan, and a confirmed preference may all appear in execution history, but they should not enter future decisions with identical authority.

Nor should a larger context window become an excuse to replay everything. Anthropic's context-engineering guidance treats the model's working context as a limited resource and recommends curating useful information rather than indiscriminately accumulating it. [4]

For an enterprise assistant, I would keep durable memory narrow: confirmed preferences, source-backed project facts, and explicitly scoped task state. Credentials, access grants, current balances, and other authoritative operational state should remain in the systems designed to own them.

Give every memory a contract

A vector is a retrieval aid, not a complete memory record. My starting schema would include identity, source, purpose, validity, lifecycle state, and lineage.

For example, the following is an illustrative application record, not a vendor API schema. All identifiers and dates are fictional examples. context_only means the preference may inform a response but cannot grant tool permissions.

{
  "memory_id": "mem_demo_042",
  "tenant_id": "tenant_demo",
  "subject_id": "user_demo",
  "key": "preferred_contact_channel",
  "value": "email",
  "purpose": "customer_support",
  "source_event_id": "event_demo_018",
  "source_origin": "authenticated_user_statement",
  "authority": "context_only",
  "recorded_at": "2026-09-20T14:00:00Z",
  "valid_from": "2026-09-20T14:00:00Z",
  "expires_at": "2026-12-20T14:00:00Z",
  "status": "active",
  "revision": 1,
  "derived_from": []
}

The application—not the model—should set identity and authority fields from authenticated context and policy. A model must not be able to elevate a webpage into an authenticated user statement merely by writing a different label.

The example expiry is not a recommended universal retention period. Choose retention by data category and product purpose. Track when a fact became valid separately from when it was recorded: a migration announced today might become effective next month.

Put controls on the write path

Treat a model-suggested memory as a candidate. Before committing it, check whether the product needs it, whether its source supports the claim, whether it contains prohibited sensitive data, and whether it duplicates or contradicts existing state.

Preserve the source's trust level through extraction and summarization. A summary of an untrusted document is still derived from that document. Rewording must not turn it into an instruction from the user.

For conflicting updates, do not blindly select the newest timestamp. A current authenticated statement can supersede an older preference; a freshly retrieved webpage cannot automatically override a confirmed account setting. Use source authority, validity intervals, and product-specific update rules. Leave unresolved conflicts explicit.

Anthropic's memory-tool documentation is useful here because it places storage operations in the application's handler and calls out responsibilities such as sensitive-data validation, expiration, and path validation. The existence of a memory tool does not remove the need for application-side controls. [5]

Retrieval needs gates before ranking

For this design, the read path starts with the authenticated tenant and subject. Restrict the searchable candidate set to records the requester may access. Exclude revoked, expired, superseded, and purpose-incompatible entries before semantic ranking wherever the storage system supports that filtering.

Recheck authorization and lifecycle status before inserting selected records into context. This protects against changes between retrieval and use. If the policy service is unavailable, fail closed rather than assuming an old access decision remains valid.

After these checks, rank for relevance and pack only the necessary evidence into the working context. Keep source and time information visible to the agent. Return “not known” when the remaining evidence is insufficient instead of encouraging the model to bridge gaps with an old memory.

Most importantly, memory retrieval must not grant action authority. A remembered preference for email does not approve sending a message today. Sensitive or irreversible actions still need current authorization and the product's approval policy.

Forgetting must reach the copies

In a proposed production design, deleting the primary row is only the beginning. Trace where the fact has spread: embedding indexes, summaries, caches, checkpoints, exported artifacts, and retained event data may all require separate handling.

Use lineage IDs to locate derived records. Mark a fact unavailable to future reads immediately, invalidate the serving caches, and schedule deletion or approved regeneration of dependent summaries. Make the completion state observable rather than returning a reassuring message before propagation has occurred.

Backups need an explicit policy. A restored backup should not silently resurrect previously revoked memories; reapply the revocation ledger before the restored system serves traffic. Describe backup retention and deletion limits honestly rather than promising instant erasure from every copy.

There is a further boundary: removing a memory record is not the same as removing information used to train model weights. Avoid treating operational memory deletion as proof of model unlearning.

Test the lifecycle, not a recall trick

The original LongMemEval benchmark tests information extraction, multi-session reasoning, temporal reasoning, knowledge updates, and abstention. Those categories remain a useful starting point; a remembered name alone does not demonstrate a reliable memory system. [6]

For this application, I would add a lifecycle test sequence. First, store a source-backed project fact and verify useful recall. Then update it, revoke its source, remove the user's access, and finally delete it. After each change, run a new conversation and inspect both the answer and the retrieved records.

Add cases for two users with similar histories, concurrent conflicting updates, irrelevant but highly similar records, an untrusted document requesting a permanent preference change, and a restore from an older backup. None should gain authority merely by being semantically close to the query.

Measure stale-fact use, unsupported claims, cross-user leakage, incorrect abstention, memory-write rejection, and deletion-propagation time alongside task success and latency. Separate retrieval failures from answer-generation failures. Anthropic's evaluation guidance supports combining deterministic checks, calibrated model grading, and human review rather than treating one fluent answer as sufficient evidence. [7]

Build memory that can disagree with itself

The most useful memory system is not the one that preserves the most text. It is the one that can explain where a claim came from, recognize when it changed, refuse to use it outside its scope, and stop recalling it when instructed.

Before adding another retrieval layer, define the write policy, validity model, authorization boundary, and deletion contract. Then test whether memory actually improves the work the assistant is supposed to do.

An agent should remember useful context. It should not inherit permanent authority from everything it once read.

Sources and further reading

[1] Google DeepMind. “Advancing Private AI Compute with secure, server-side memory.” September 23, 2026. https://deepmind.google/blog/advancing-private-ai-compute-with-secure-server-side-memory/

[2] Huang, Zhang, and Jia. “When Malicious Instructions Persist: Persistent Memory Poisoning Attack on Harness-Based Agents.” arXiv:2609.13889, September 12, 2026. Preprint; results are specific to the tested settings. https://arxiv.org/abs/2609.13889

[3] LangGraph documentation. “Persistence.” https://docs.langchain.com/oss/python/langgraph/persistence

[4] Anthropic. “Effective context engineering for AI agents.” September 29, 2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

[5] Claude Platform documentation. “Memory tool,” especially “Security considerations.” https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool

[6] Wu et al. “LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory.” ICLR 2025; arXiv version 2, March 4, 2025. https://arxiv.org/abs/2410.10813

[7] Anthropic. “Demystifying evals for AI agents.” January 9, 2026. https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents