Adapted from the Hebrew guide "When the Agent Remembers Something That Has Changed: Managing AI Memory in an Organization" on AI NEWS IL (published 8 September 2026).
Memory helps an agent keep context. It can also return an old price, a changed preference or a procedure that was cancelled. Storing something well does not make it correct today.
This guide turns that risk into decisions and tests for an agent pilot. The examples are hypothetical, not case studies or measured results.
The direct answer: every memory needs a correction path
Do not let an agent keep every detail forever just because storage is available. Decide what is worth keeping, where it came from, when it was last checked and what happens when it changes. If validity cannot be checked, the agent should go back to the approved source or ask for clarification.
The goal of memory is to cut repeated work, not to create a second store that nobody owns.
What the AWS post adds
On 4 September 2026 AWS published a guide to designing lifecycle policies for AgentCore Memory. It describes the risk of stale information piling up and suggests patterns for evaluating, consolidating and reducing memories, with an AWS example implementation.
Do not read it as saying every memory is deleted automatically, that every component ships preconfigured, or that one policy fits every organization. The useful point for any stack is the difference between storing information and maintaining knowledge. The process below is an applied proposal, not an AWS benchmark.
Step 1: Map what the agent actually stores
List the types of information that enter memory in the process you chose: a language preference, a meeting summary, a service request status, an explanation of a procedure. Each changes at a different rate and means something different. Do not mix a detail a user shared about themselves with an organizational rule approved in a formal document.
Trace a real path. An agent may write a summary to a database, keep chat history and add a snippet to a separate search index. Fixing one place does not fix the others. Pick a non-sensitive example and follow it: which message created it, where it was stored, who can read it and in which answer it comes back.
Step 2: Separate memory from the source of authority
In a hypothetical case, a sales rep asks the agent about promotion terms early in the month. The agent stores a summary. The promotion then ends and the approved page is updated. If the old summary wins over the current page, wrong terms can reach a customer.
Decide in advance which source may answer questions about price, eligibility or process stage, and when it must be rechecked. Conversation memory can explain what the customer asked. It should not become the terms document.
Attach to each item a source ID, a creation date, a last-checked date and an owner. If two sources conflict, do not ask the agent to pick the more convincing one. Set a professional tiebreak rule or route the question to a person.
Step 3: Set validity by use, not by an arbitrary number
No single number of days fits all memories. A ticket status, a language preference and an operating guide change at different speeds. Define recheck triggers: a source document changes, a request closes, the user gives an update, or a date set by the process arrives.
If you also use periodic checks, write down why the interval fits the use case and what harm could happen between two checks. Do not copy a technical default as a business policy.
Stopping the use of an item in answers is not the same as deleting it from the system. An item may need to leave retrieval results immediately, while other copies follow a separate data policy. This guide does not say how long personal data may or must be kept. For sensitive or regulated data, involve the right owners before changing policy.
Step 4: Build a way to update, retire and delete
Define the action for when an employee reports that the agent remembers something wrong. Who receives the report, how is the item found, and who may fix it? Adding a new message that says "ignore the previous one" is not enough. If both versions stay available with no rule to decide between them, another question can bring the old information back.
After a fix, test retrieval in several phrasings: a direct question, an indirect one and one that includes the old wording. Also try a new conversation, so a fix in one session is not mistaken for a fix in the store. For deletion requests, define a check for each storage layer you manage. Seeing no result in one interface does not prove every copy is gone.
Step 5: Watch for summaries that lose the condition
Merging several memories into one summary can make retrieval easier. It also changes how the information is represented. In a hypothetical case, the sentence "an item can be exchanged within a week if the packaging is sealed" becomes "exchange within a week". The answer sounds clear, but the condition is gone.
Before approving a summarization mechanism, test it on examples with exceptions, numbers and conditions. Do not remove professional distinctions just to save space. Two customers with similar names are not the same person, and two versions of a procedure are not always duplicates. Keep markers that tell items apart: process ID, scope, version and access permission. When you cannot merge with confidence, keep items separate or send them for review.
Step 6: Test in more than one language without mixing permissions
A team may use the same concept in Hebrew, English and an acronym. Prepare test questions in the common phrasings, including product names and internal terms. The aim is not to show that the model knows a language. It is to check that the agent reaches the same approved source whatever the language of the question. If translation created a separate memory, make sure a source update reaches that retrieval path too.
A language test does not replace a permission test. Sign in as an ordinary employee and as someone with a different role, and compare what each can retrieve. A memory created in a manager's conversation should not reach another team just because the topic is similar.
Step 7: Measure memory quality and decide whether to expand
Prepare a small test set with valid information, changed information, a contradiction and information the agent must not see. For each question, write the expected source and the success condition. Count how many answers relied on an old version, how many corrections reappeared and how many cases needed human review.
Response time alone is not enough. A fast answer based on wrong information is not an improvement.
End the pilot with a defined decision. If the agent uses the right sources and the correction path works, add one more information type and test it separately. If not, narrow what it may remember or go back to direct retrieval from the approved source.
What should be ready at the end of the pilot
- A list of information types the agent may keep.
- A map of authoritative sources.
- An owner for each process.
- A test set that can be rerun.
- A short record of one correction from report to verified answer. Use test data rather than real personal details.
Also set a stop condition. If old information returns after a fix, pause memory for that information type and point the agent to the approved source until it is resolved. This is a pilot design suggestion, not a feature every product guarantees. Make sure the team can actually do it and that someone has the authority to decide.
One step to take now
Pick one process and prepare five questions about information that may change. Update the approved source, rerun the questions and check that the agent uses the new version and shows the right source.
This English adaptation was prepared with AI assistance.
Yaniv Shenhav.
Top comments (0)