AI memory should retain information that improves future work and can still be checked, corrected or removed. Saving every conversation is not a useful policy. It mixes durable facts with temporary instructions, outdated decisions and sensitive details that may have no reason to persist.
For a small business using an assistant repeatedly, the design question is practical: what should be remembered, where should it live and how will the next user know whether it is still true? A short, well-maintained record can be more useful than a large collection of unlabelled notes.
Separate working context from durable memory
Working context is the information available for the current task: instructions, retrieved documents, conversation and tool results. Durable memory is information retained for use in later tasks. Retrieval is the process of selecting relevant stored information when needed.
These functions can overlap in a product, but the distinction helps you decide what belongs where. A temporary export path may matter during one job and have no value afterwards. A stable preference for invoice terminology may remain useful.
Anthropic’s September 2025 context-engineering article discusses context as a finite resource and describes approaches such as retrieval, compaction and structured notes. The practical lesson is to curate what the system sees rather than assume that more text always improves the result.
A memory record should have a purpose. If nobody can explain how it helps a future task, there may be no reason to retain it.
Give each retained fact a source and scope
A useful memory says what is known, where it came from, when it was established and where it applies. “Use the approved template for this client’s monthly report” is more useful when linked to the actual template and client scope.
Avoid broadening a local preference into a global rule. A customer’s request for a short email does not necessarily mean every future report should be short. A workaround for one software version should not become permanent guidance for all versions.
Distinguish facts from preferences and decisions. Facts may need verification, preferences may need confirmation when context changes, and decisions should retain their assumptions.
| Memory type | Example | Maintenance need |
|---|---|---|
| Stable preference | Use a specified brand spelling | Change when owner updates it |
| Project decision | Chosen accounting system | Keep scope and rationale |
| Operational fact | Current filing provider | Recheck when provider changes |
| Temporary state | Waiting for a document | Expire when resolved |
| Sensitive credential | Password or recovery key | Keep out of ordinary assistant memory |
The table is a proposed design for a business workflow, not a description of every assistant product.
Store references when the source should remain authoritative
A price list, policy or contract can change. Copying its entire content into a memory note creates another version that may become stale.
Where appropriate, retain a reference to the authoritative source and a short explanation of why it matters. Retrieve the current document when the task requires current information.
This does not eliminate the need for historical evidence. If a decision relied on a particular version, preserve that version in the proper records system and identify it explicitly. Current guidance and historical evidence serve different purposes.
The assistant’s memory should help find the right record. It should not quietly replace the recordkeeping system for contracts, financial statements or other controlled documents.
Decide how temporary information expires
Temporary notes need an end condition. “Waiting for the supplier’s revised quote” should expire or change once the quote arrives. Otherwise the assistant may keep acting as if the decision is blocked.
Use a date, event or review trigger appropriate to the information. A vendor price may need checking at purchase time; a task status may need updating when the task closes.
Do not apply an arbitrary expiry to every fact. A stable brand name and an outstanding payment have different lifetimes. The rule should follow how the information changes.
Make expired or uncertain notes visible as such. Silently deleting context that explains a decision can be unhelpful, while treating it as current can be worse. Archive history separately from current operating instructions where the workflow requires it.
Resolve conflicts instead of adding another contradictory note
Suppose one memory says a report is monthly and a later instruction changes it to quarterly. Appending “quarterly” without marking the older note as superseded leaves the assistant with conflicting evidence.
Update the current record and preserve a short history if needed. Identify the source of the change and its effective scope. If the change applies to one project, do not rewrite unrelated projects.
When two sources conflict and neither clearly supersedes the other, keep the conflict explicit. The assistant should request or seek the missing clarification rather than choose whichever note happens to be retrieved first.
A memory system that cannot correct or retire information will accumulate errors even if every original note was reasonable when written.
Keep secrets and unnecessary personal details out
Ordinary assistant memory is not the right place for passwords, private keys or recovery codes. Use the appropriate credential system and provide access through controlled tools where authorised.
Personal information should have a clear purpose and retention basis. A detail mentioned once in conversation does not automatically need to become a durable profile.
For a business, decide which categories may be stored and who can inspect or delete them. The policy should reflect the actual product’s storage, access and retention behaviour.
Avoid a blanket claim that information is private because it is called memory. Check where it is stored, which systems process it and what administrative controls exist.
Work through a client-reporting example
Imagine an assistant that prepares monthly supplier-spend reports. Useful retained information might include the approved report format, the definition of spending categories and the location of the source ledger.
The current month’s invoice totals should come from the ledger, not from a memory of last month’s conversation. A temporary note that a supplier name needs reconciliation should be resolved when the records are corrected.
If the owner changes a category definition, update the definition with an effective date. Historical reports may still need the old definition for comparison, so preserve that distinction in the records.
The example shows how memory can support a workflow without becoming a second, uncontrolled accounting database. Durable instructions guide the task; current figures come from the authoritative source.
Test retrieval with questions that expose mistakes
A memory test should check whether the assistant retrieves the relevant information, respects its scope and notices when it is stale or contradicted. A correct answer on one familiar question is not enough.
Create a small set of cases: a current preference, a superseded instruction, a project-specific rule, an expired temporary note and a question for which no memory should apply.
The January 2026 guidance on agent evaluations supports defining observable outcomes and testing repeated behaviour. Apply that method to memory: inspect the answer and, where available, which sources were used.
Do not reward the assistant for confidently recalling something it should have rechecked. For a price, legal rule or provider status, the correct behaviour may be to verify the current source.
Measure usefulness without rewarding accumulation
A large memory count is not evidence of a better assistant. Useful measures include fewer repeated explanations, accurate retrieval, correct handling of changes and the absence of unrelated information in outputs.
Review a sample of retained notes. Can a person understand each one without reconstructing the entire conversation? Is the source identifiable? Is the scope narrow enough? Is there a reason to keep it?
Remove duplicate notes and combine genuinely identical preferences carefully. Do not merge distinct decisions merely because they contain similar words.
Track failures in both directions: forgetting something important and applying something that should not have been used. The second can be harder to notice because the answer may sound confident and familiar.
Treat retrieved memory as information with a trust level
A stored note can originate from a user instruction, an imported document or an assistant’s summary. Those origins have different authority. An external document should not gain permission-granting power merely because its text was saved.
Keep source attribution through summarisation. If a supplier claimed that an action was approved, the memory should not turn that into “the owner approved the action”.
This is the same boundary discussed in our prompt-injection guide. Retention does not convert untrusted content into an authorised instruction.
For consequential actions, use the current authorised scope and the application’s controls. A vague historical note should not silently authorise sending data, making payments or changing access.
Give the owner a way to inspect and correct the record
The people relying on the assistant should be able to see what is retained and request corrections within the product’s supported controls. Hidden, unreviewable assumptions are difficult to manage.
Make updates precise: what should change, which projects it affects and whether the old record should be removed or retained as history. Verify that the persisted result matches the requested change.
When a memory-based answer relies on information that has not been checked recently, say so where it affects the decision. That allows the user to decide whether a current verification is needed.
The operating target is a small set of useful, attributable records whose status can be understood. Keep what helps the next task, connect it to its source and make correction part of normal use.
Make deletion part of the test
Create a harmless test preference, confirm that it is used in the intended scope, then remove it through the supported controls. Ask a fresh question that would previously have triggered it and check that the removed preference no longer governs the answer.
Deletion may involve more than one store if the workflow copies notes into several systems. Document the actual locations rather than assuming that clearing a chat removes every retained record. The owner needs a usable correction and removal process, not only a way to add information.
Questions
Should an assistant remember every conversation?
No. Retain information with a clear future purpose, appropriate scope and a way to maintain or remove it.
What is the difference between memory and retrieval?
Memory is retained information; retrieval selects relevant information for a task. A system can retrieve from authoritative documents without copying everything into a memory note.
How should outdated information be handled?
Mark it as superseded or expired and update the current record. Preserve historical evidence separately when it is needed.
Should passwords or recovery codes be stored in assistant memory?
No. Keep credentials in the appropriate secure system and use controlled access methods.





