The source record is corrected on Tuesday. On Thursday, the agent still acts on Monday's version.
The current CRM record, policy page, and product catalog all agree. Yet an earlier summary, inferred profile, or extracted fact may still be entering the agent's context. The first operating question is not whether the model is wrong. It is which state surface supplied the stale fact and who can correct it.
When remembered context can change a future answer or action, it is production data. A forward-deployed team should govern it as a data store: define what may be written, who or what it describes, where it may be reused, how long it survives, and how an authorized person can inspect, correct, and delete it.
Memory has become an explicit platform surface
Current product documentation makes the category visible.
Microsoft Foundry's memory preview exposes long-term stores, item-level create, read, update, list, and delete operations, per-user scope, default time to live, and direct remember-or-forget behavior. Google Cloud's Memory Bank documentation documents revisions, rollback to a prior revision, deletion behavior, and a separate expiration policy for revision history.
These are useful controls. They do not decide which facts deserve persistence, prove that a scope maps to the correct subject, or settle whose evidence should win when a stored assertion conflicts with a system of record. Product capability does not assign enterprise owners or complete the policy.
The deployment still needs an operating contract.
Separate four kinds of state
“The model remembers” is too vague to govern. At least four kinds of state can affect an agent interaction:
| State | What it does | Operating question |
|---|---|---|
| Working context | Carries information inside the current model call or active task | What entered this run, and from where? |
| Conversation state | Preserves prior messages or response items across turns | Which conversation owns it, and when does that object end? |
| Retrieved knowledge | Selects material from documents, databases, or search at request time | Which source is authoritative now? |
| Durable memory | Stores an extracted or explicit fact for reuse across later sessions | Who may write, inspect, correct, expire, and delete it? |
The inventory matters because one deletion claim cannot cover every surface. A team may remove a durable record while the old value remains in an active conversation, a generated summary, a search index, or a downstream artifact. The in-scope stores depend on the actual design.
OpenAI's current data-control documentation illustrates the distinction. It lists different application-state behavior for Responses, conversations, files, and vector stores, with some state kept for a defined period and some objects held until deletion. Exact behavior depends on the endpoint and configured data controls.
Conversation state, retrieved knowledge, and durable memory are not interchangeable. A production design should name each surface, its owner, and its lifecycle.
A memory write needs a contract
Treat an explicit “remember this” request, an automated extraction, and an administrative update as different write paths. For each durable record class, decide:
- Purpose: which workflow outcome requires this fact to persist?
- Subject and scope: which person, account, case, team, or process may retrieve it?
- Source and provenance: which event or authoritative record supports it, and when was that evidence observed?
- Write authority: can a user write it directly, may the system infer it, or must a named owner approve it?
- Status: is it a preference, unverified assertion, verified fact, temporary instruction, or disputed item?
- Use boundary: may it personalize language, filter options, propose work, or influence execution?
- Retention: when does it expire, and does an update extend that period?
- Correction and deletion: who can change or remove it, which in-scope copies exist, and how is completion verified?
This is my proposed memory contract, not a description of any vendor's internal governance.
Suppose an account-routing agent remembers that Dana owns the western region. That fact might be allowed to suggest a queue. It should not override the current territory table, reassign an account, or authorize a compensation change. The same string can be useful context in one step and unacceptable authority in another. Memory can inform work without becoming the system of record.
Correction is an operating path
A memory system can faithfully preserve a bad input. The error may be ordinary: a person changes roles, an account changes ownership, or an extractor mistakes a proposal for an approved decision. It may also be adversarial. The OWASP AI Agent Security Cheat Sheet names memory poisoning as malicious data persisted to influence future sessions or other users.
Persistence changes the security boundary. A prompt injection confined to one session is one problem. A malicious instruction summarized as a trusted fact and retrieved next week is another.
Correction therefore needs more than an edit gesture. The operator must locate every affected scope, distinguish the stored record from its source evidence and revision history, invalidate applicable retrieval paths and caches, and verify that later sessions no longer receive the bad fact. If a corrected item can be rolled back, the authority to use revision history also needs control.
NIST's AI Risk Management Framework Core does not prescribe an agent-memory schema. It does call for documented knowledge limits, privacy requirements, ongoing review, clear roles, internal controls, and safe decommissioning. The memory lifecycle is one place those responsibilities become concrete.
Test forgetting before recall earns trust
Teams often demo memory with a recall test: tell the agent a fact, start a new session, and confirm that it remembers. That proves persistence. It does not prove control.
Run a correction drill with authorized synthetic data:
- Write a false but harmless fixture through each permitted path: user instruction, automated extraction, and administrative update.
- Confirm which scope receives it and which later sessions retrieve it.
- Inspect the stored item, source reference, status, timestamps, retention value, and available revision history.
- Correct the source of truth, then use the approved correction or deletion path for the stored fact.
- Start fresh sessions and verify that the old value is neither retrieved nor used. Check the secondary stores, summaries, caches, and downstream artifacts the design actually employs.
- Verify expiry with a short test TTL, including whether an update resets the clock.
- Retain independent evidence of the drill without keeping the synthetic record longer than intended.
The test passes when the old value is absent from every in-scope retrieval path, the corrected value is used only within its approved boundary, and the evidence shows which operator completed the change.
Put the memory contract in the handoff
The handoff should identify every state surface, record class, scope rule, authoritative source, write path, use boundary, retention rule, inspection interface, correction and deletion procedure, revision policy, and operating owner. Acceptance should include both successful recall and successful forgetting.
The permanent operator should execute the drill. The FDE can observe, diagnose, and refine the runbook. If only the original builder knows where a remembered fact lives or how to remove it, the capability has not transferred.
Persistent memory can make an agent more useful. It also creates a new place where yesterday's context can govern tomorrow's work.
Before allowing it to influence a consequential action, ask the receiving team to find one stored fact, explain why it was allowed, correct it, verify the old value is gone from future retrieval, and identify the evidence owner. If the team can only demonstrate recall, it has demonstrated persistence. It has not yet demonstrated control.