Agent memory is any retained context an AI system can retrieve and use in a later step or session. That may include the current task, a user-controlled preference, a summary of prior work or a pointer to an authoritative record. The feature can reduce repetition and improve continuity, but it also carries old mistakes, hostile instructions and excessive access forward. Buyers should ask what is stored, why it is needed, who can retrieve it, how it changes and how it disappears.
The right architecture rarely resembles one unlimited conversation history. It separates temporary reasoning state from durable preferences and regulated business records. The AI workflow approvals guide helps define human authority, while the AI guardrails review covers controls around untrusted inputs and consequential actions.
Key takeaways
- Create memory only for a named task benefit and owner.
- Keep authoritative business facts in their source systems and retrieve them when needed.
- Bind every memory read and write to current identity, tenant and purpose.
- Treat summaries, embeddings, caches and backups as part of the same lifecycle.
- Test poisoning, staleness, cross-user retrieval, correction and deletion before scaling.
Classify memory before evaluating products
Working memory holds the immediate task and should usually expire quickly. Episodic memory summarizes a prior interaction or outcome. Preference memory stores a user-controlled choice such as response language. Semantic memory may contain reusable organizational knowledge. An authoritative record, such as an employee entitlement or approved contract, should normally remain in its governed system and be retrieved under current permissions rather than copied into a free-form memory store.
For each class, write purpose, source, subject, writer, reader, retention, correction route and prohibited use. The NIST AI Risk Management Framework encourages lifecycle risk management rather than a one-time model review. That matters here because memory behavior emerges from models, retrieval, identity, stores, ranking, prompts and operational policy together.
| Memory class | Good use | Default lifecycle |
|---|---|---|
| Working context | Steps and artifacts for the active task | Expire at task end |
| User preference | Explicitly chosen language or format | User-visible and revocable |
| Case summary | Handoff context with source references | Retain with the case policy |
| Organizational knowledge | Approved reusable guidance | Version and refresh from source |
| Authoritative record | Entitlement, balance or legal status | Do not duplicate as free-form memory |
Design identity, authority and provenance into retrieval
Authorization must occur at retrieval time using the current user, agent, tenant and purpose. A memory written when someone had access does not remain safe after a role change. Store provenance with the item: originating record, writer, creation time, applicable policy, version and confidence where relevant. Generated summaries should link to source evidence and identify that they are summaries rather than becoming indistinguishable from human-approved facts.
Assume retrieved text is untrusted. It may contain a prompt injection, a mistaken conclusion or content intended for another workflow. OWASP's LLM application risks include prompt injection, sensitive-information disclosure and excessive agency. Enforce tool permissions outside model text, validate output before use, and never let a retrieved instruction silently expand the agent's authority.
| Threat | Example | Required control |
|---|---|---|
| Stale context | Old role influences an access recommendation | Current-source retrieval and age limits |
| Poisoned memory | Untrusted document plants a durable instruction | Content isolation and write approval |
| Cross-tenant leak | Similarity search returns another customer | Tenant filter enforced before ranking |
| False summary | Generated note omits a contractual exception | Source links and correction workflow |
| Incomplete deletion | Text is gone but embedding remains | Lifecycle inventory and deletion verification |
Buy a capability, not a memory label
Ask a supplier to demonstrate the complete data path. Where are raw text, summaries, vectors, logs and backups stored? Can separate tenants use separate keys and indexes? Which administrators can inspect content? How are exports, legal holds, regional storage, model-provider retention and subcontractors handled? The NIST Privacy Framework helps connect data processing to individual privacy risk rather than treating retention as a storage-cost setting.
Require deletion and correction evidence, not only policy language. Change a preference and prove the old value no longer affects retrieval. Remove a case and confirm indexes, caches and replicas follow the stated lifecycle. Change a user's role and test that prior context does not bypass current access. Ask how the provider handles a model or embedding upgrade, because re-indexing can create a new copy and alter retrieval behavior.
Evaluate memory with realistic cases
Build an evaluation set around decisions, not trivia recall. Include a first-time user, returning user, corrected fact, revoked permission, two similar customers, stale policy, malicious document, ambiguous preference and deleted case. Score whether the right memory was retrieved, whether the source was authorized and current, whether irrelevant context was excluded, and whether the final action respected policy. The NIST Generative AI Profile supports risk-based evaluation for generative systems.
For an internal service-desk agent, task memory may hold troubleshooting already attempted, while an employee's actual entitlement stays in the identity platform. A case summary should link to ticket events and mark uncertain inferences. After a transfer to another department, the agent must ignore the earlier entitlement even if it remains semantically similar. The model evaluation guide provides a broader pattern for representative and adverse test sets.
Define a memory service contract
A memory service needs an explicit contract between the product, identity layer and agent runtime. Define which caller may propose a write, which policy decides whether it is retained, and which fields are immutable. A useful record includes a stable item identifier, subject, tenant, memory class, source reference, creation reason, policy version, expiry and sensitivity. Keep generated text separate from these control fields. The model can propose a summary, but it should not be able to rewrite its tenant, source or deletion policy through natural-language output.
Retrieval should return more than text. Return source, age, authorization result and memory class so the application can decide how the item may be used. A user preference might safely influence formatting, while a case summary may only support a draft that cites the current case. If the authoritative source is unavailable, define whether the workflow pauses, uses a clearly dated cache or continues without the memory. Silent fallback to a stale item is a product decision disguised as infrastructure behavior.
Write conflicts need deterministic handling. Suppose a user states a new shipping preference while an older support summary says the opposite. An explicit user-controlled preference should supersede the derivative summary for its stated purpose, but it should not alter an open order already governed by a confirmed address. Record the supersession link and effective time. When two sources have equal authority, ask for confirmation or preserve both as unresolved rather than allowing retrieval rank to decide truth.
Stage rollout by memory class
Begin with low-consequence, user-visible preferences that can be inspected and revoked. Next, add short-lived task continuity with strict expiry. Introduce case summaries only after source links, correction and access-revocation tests work. Durable cross-session knowledge should come last because it expands the affected population and the time during which a mistake can influence behavior. Keep each class behind a separate control so an incident in one category can be disabled without removing all continuity.
For each stage, compare task completion, repeated-question rate and user correction with the no-memory baseline. Also measure unauthorized retrieval attempts, stale-item use, deletion completion and the percentage of outputs that depend on a memory without a reachable source. Expansion should require both useful continuity and acceptable control evidence. If users frequently correct a memory class, narrow what is stored before tuning retrieval to surface it more aggressively.
Operate correction, expiry and incident response
Give users a visible way to inspect and revoke personal preferences and to flag a wrong case summary. Separate correction of the source record from correction of a generated derivative. Monitor retrieval age, source availability, authorization denials, correction rate, cross-boundary test results and incidents in which memory influenced a harmful action. High retrieval frequency is not a success measure if the context increases rework.
Prepare a selective isolation mechanism. A team should be able to stop writes, quarantine one source, disable a memory class or fall back to current-record retrieval without disabling the whole service. The UK NCSC's secure AI development guidance places security across design, development, deployment and operation. Record affected memories, downstream actions, corrections and criteria for safe restoration after an incident.
Agent memory purchase checklist
- Each memory class has a purpose, subject, owner and prohibited use.
- Current identity and tenant policy gate every read and write.
- Provenance distinguishes source records, human notes and generated summaries.
- Retention covers raw content, vectors, caches, logs, exports and backups.
- Users and operators can correct, revoke and verify deletion.
- Evaluation includes poisoning, staleness, role change and cross-tenant attempts.
- The service can isolate one memory source or class and recover safely.
Frequently asked questions
Does every AI agent need long-term memory?
No. Many tasks work better with the current request plus fresh retrieval from approved sources. Add durable memory only when continuity creates measurable value that cannot be achieved more safely through a task record or user-controlled preference.
Is a vector database the memory?
It can be one storage and retrieval component, but memory behavior also depends on source ingestion, identity filters, ranking, prompts, model use, correction and retention. Evaluate the end-to-end behavior rather than treating a database feature as the complete control boundary.
How long should agent memory be retained?
Use the shortest period that supports the stated purpose, subject to applicable record obligations. Working context may last minutes; a case summary may follow the case schedule; a preference may persist until revoked. Review retention whenever the purpose, source or affected population changes.
Conclusion
Good agent memory is bounded context with a lifecycle, not an unlimited archive. Separate memory classes, retrieve authoritative facts under current access, preserve provenance and rehearse correction and isolation. Buyers who demand those behaviors can gain continuity without allowing yesterday's permissions, errors or hostile content to govern tomorrow's actions.