Persistent memory is permission to let yesterday’s context shape tomorrow’s action. It should not be a switch that quietly promotes every conversation into a permanent data store. Before enabling it, write a memory contract: what stays inside the live task, what must be queried from a system of record, what may become durable agent memory, and what must expire or never be written.
That contract starts with a plain distinction. A knowledge base holds documents the agent may consult. A CRM or business application owns live operational facts. An audit log records what happened. Durable memory stores selected information for future recall. They may all provide context, but they do not have the same owner, retention logic or authority.
“Memory” is not a useful architecture answer
Ask where an agent keeps memory and you may hear “the chat history”, “a vector store” or “the model remembers”. None of those answers defines the operational behaviour.
Microsoft’s Agent Framework documentation separates chat history, session state, context providers and application-level persistence.[5] Its governance guidance also separates identity, lifecycle, observability and data decisions, including how agents access, store and retain information.[4] A buyer needs the boundary between those responsibilities, not one umbrella label.
The distinction matters most when data changes. A case status can be correct at noon and stale by the next morning. Copy it into durable memory and the agent now has two plausible authorities: the old copy and the current business record. Query the system of record instead and the conflict disappears.
This is also why an audit trail should not automatically feed future prompts. Evidence may need to remain available for investigation while being irrelevant, sensitive or misleading as recalled context. AI agent observability explains the evidence side; this article is about the narrower decision to write and reuse memory.
Four stores, four owners
| Responsibility | Typical content | Authority | Expected exit |
|---|---|---|---|
| Working state | Inputs and intermediate decisions for the live task | The current task or session | Task completion or session expiry |
| System of record | Current case, order, role or availability | The owning business application | Update there, then query again |
| Durable memory | A stable preference or approved project decision | A named business owner | Correct, supersede, expire or delete |
| Audit evidence | What the agent read, decided and attempted | The audit and operations policy | Separate retention and access controls |
This split makes one question much easier: if a value is wrong, where should the correction happen? A live order status changes in the order system. A confirmed output preference changes in durable memory. A faulty execution stays in the audit record, with its correction, but should not become a “lesson” injected into every later task by default.
Decide each write: working, query, durable or discard
Use the decision at the point of writing, not as a clean-up exercise months later.
| Candidate information | Route | Reason |
|---|---|---|
| Files opened to draft the current response | Keep in working state | They belong to the live task |
| Current case status | Query the source | It can change outside the agent |
| A format preference explicitly confirmed by the user | Durable, within a defined scope | It may remove repeated setup if it can be corrected |
| A project constraint with a known end condition | Durable with expiry | It is useful only inside that project and period |
| A versioned operating procedure | Query the source | A memory copy would go stale silently |
| A summary suggested by the agent and rejected | Discard; do not write | It is unverified and has no future authority |
This is not a taxonomy for its own sake. It produces one of four actions. Most live business state should be queried rather than copied. Some context should disappear when the task ends. A smaller set of stable, approved information may be persisted. The rest should never enter the memory store.
Hosting does not settle the decision. A local model or a particular cloud arrangement changes the data flow and threat model, but it does not decide purpose, authority, expiry or correction.
Write the contract before choosing the store
For every category allowed into durable memory, record seven fields:
- Purpose. Which future task benefits from recall? “Personalisation” is too broad.
- Provenance. Did the value come from the user, a system of record, an approved decision or a model inference?
- Owner. Who is accountable for the definition and can retire it?
- Retrieval scope. Which user, project, team or process may receive it?
- Validity. What date or event triggers refresh, review or expiry?
- Correction. How is a value superseded without leaving two competing versions?
- Deletion path. Who can request removal, what can be exported, and which stores are actually covered?
The contract deliberately avoids a universal retention period. Appropriate retention depends on purpose, the business context, applicable requirements and the real architecture. The useful outcome is an explicit decision with an owner, not a number copied into every implementation.
Product controls can expose some of this behaviour. Anthropic, for example, documents optional memory, project-level separation, a view/edit control and an incognito mode that does not add to memory. Those are examples of product choices, not a vendor benchmark or proof that every underlying deletion path is identical.[6]
Treat a memory write as a controlled event
A memory write should carry provenance and scope. It should not be a side effect of producing a fluent answer.
Before writing, the workflow should establish that the information is fit for future use, that its source is known and that its retrieval scope is allowed. It also needs to keep unlike objects apart:
- a verified fact is not the same as a model inference;
- a confirmed preference is not a one-off remark;
- an instruction for this task is not automatically a fact about the user;
- a superseded value is not a second opinion worth retaining.
Correction is where vague memory systems tend to fail. If a person first asks for short summaries and later confirms that a detailed format is now the default, the old value should be superseded or invalidated with an effective date. Simply appending the new statement leaves recall to chance.
The CNIL and CIANum’s July 2026 exploratory note describes the data-protection difficulty created by persistent memory: accumulation and enrichment of personal data, distribution across memory spaces, and reduced visibility into what is held and for how long. It discusses separation, limitation and expiry as possible controls. The note is not a new standalone regulation and should not be presented as personalised legal advice.[1]
Untrusted input must not cross into trusted memory
OWASP lists memory poisoning as an agent-specific risk: malicious or misleading data can be persisted and then influence later sessions or other users. Its AI Agent Security Cheat Sheet recommends controls including validation before writes, isolation between users or sessions, size limits, expiry and review of sensitive content before persistence.[2]
An OWASP article published on 13 May 2026 explains the trust shift clearly. A hostile input is no longer limited to one interaction once it reaches persistent state that the agent continues to treat as part of its operating context.[3] Recalled content should therefore remain data with provenance, not be promoted to trusted instruction merely because it came from the memory store.
The broader tool-permission and external-content problem belongs in the indirect prompt injection guide. The memory-specific rule is simpler: untrusted content cannot become durable memory without a validated write path and an explicit retrieval scope.
Test the lifecycle, not just recall quality
A demo that asks the agent to remember a preference proves very little. The acceptance test should cover the complete lifecycle:
- write an allowed synthetic preference and inspect its provenance;
- recall it inside the intended retrieval scope;
- confirm it does not appear for another user or project;
- change the system-of-record value and verify that authority wins;
- correct the preference and check that the old value no longer competes;
- reach the defined expiry condition and verify non-retrieval;
- request deletion, then run a future task and confirm the behaviour changes;
- attempt a write from an untrusted document and confirm that it is rejected.
These scenarios belong inside the broader pre-production agent evaluation. They do not replace permission tests, general answer-quality checks or incident drills. If a poisoned or stale memory has already caused a bad action, follow the AI agent incident response path. The memory contract should make invalidation and correction possible before that happens.
Deletion needs precise wording. A value disappearing from a user interface does not, by itself, prove erasure from every derived index, backup or audit record. The test should name the stores covered by the deletion path and document any known limits. Do not promise more than the architecture can demonstrate.
Questions to put to a vendor or delivery team
Before accepting “persistent memory” in a proposal, ask:
- Where do chat history, working state, durable memory and audit evidence live?
- Who can trigger a memory write, and from which sources?
- Which identity and retrieval scope travel with the write?
- Which source wins when memory conflicts with the system of record?
- Who can view, correct, invalidate and delete a memory item?
- What event applies expiry, and how is non-retrieval verified?
- What can be exported when the service ends?
- Which derived stores remain after an item disappears from the interface?
- Which tests prove isolation, correction and forgetting?
“The vector database holds the context” is not an answer. It names a component but leaves the memory contract unwritten.
Your agent needs continuity without retaining everything. Last Word can map working state, systems of record, memory writes, retrieval scope and correction or deletion paths before the prototype. See our AI and automation services or describe the workflow you want to test.
Frequently asked questions
What should an AI agent remember?
Only information with a clear future purpose, known provenance, a named owner, an allowed retrieval scope and defined validity, correction and deletion paths. Live business facts that may change should usually be queried from the system of record instead of copied into durable memory.
What is the difference between AI agent memory and a knowledge base?
A knowledge base contains documents the agent may retrieve. Durable memory contains selected information written after an interaction for later reuse. The business application remains authoritative for live state, while the audit log preserves execution evidence. Those responsibilities need separate policies.[4][5]
Should an AI agent retain every conversation?
No. A transcript may contain temporary instructions, stale state, unnecessary personal data and unverified inferences. Each persistent write needs a future purpose. Other context should remain in working state, be queried again from its source, or never be written.[1]
How do you stop AI agent memory becoming stale?
Attach provenance, a validity condition and a supersession rule to every durable category. Query live status from the owning system. When a preference changes, invalidate or replace the old value instead of appending a second version and hoping retrieval chooses correctly.
How do you test AI agent memory deletion?
Delete the synthetic item through the documented path, rerun a task that would have recalled it and verify that behaviour changes. Check each store the deletion claim covers. Removal from a visible summary does not automatically demonstrate erasure from derived indexes, backups or audit evidence.
Sources
[1] https://www.cnil.fr/sites/default/files/2026-07/ia-cianum-cnil.pdf, CNIL / CIANum, “IA agentique et protection des données personnelles : équation à inconnues multiples pour les utilisateurs”, exploratory note, July 2026, consulted 4 September 2026.
[2] https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html, OWASP Cheat Sheet Series, “AI Agent Security Cheat Sheet”, no update date displayed, consulted 4 September 2026.
[3] https://genai.owasp.org/2026/05/13/memory-is-a-feature-it-is-also-an-attack-surface, OWASP GenAI Security Project, “Memory Is a Feature. It Is Also an Attack Surface”, 13 May 2026, consulted 4 September 2026.
[4] https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/governance-security-across-organization, Microsoft Learn, “Govern and secure AI agents across the organization”, no update date displayed, consulted 4 September 2026.
[5] https://learn.microsoft.com/en-us/agent-framework/get-started/memory, Microsoft Learn, “Memory and persistence”, last updated 25 August 2026, consulted 4 September 2026.
[6] https://www.anthropic.com/news/memory, Anthropic, “Bringing memory to Claude”, published 11 September 2025 and updated 23 October 2025, consulted 4 September 2026.