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.

Published by Dr. Yaniv Shenhav, founder and CEO of the Israeli Institute for AI (IIAI), which runs practical AI training and adoption programs for organizations worldwide. The site is available in English, Hebrew and Arabic: https://www.iiai.co.il/en?utm_source=hashnode&utm_medium=syndication&utm_campaign=agent-memory-guide

Short answer: what makes an enterprise AI knowledge base (RAG) reliable?

A trustworthy AI knowledge base does not start by dumping every file into one folder. It starts with a list of sources, each with an owner, a validity date and permissions. You decide which document wins when two disagree, attach filterable metadata to every chunk, require every answer to cite a source and version, and test the questions where the right answer is "no valid source."

The goal is not a model that never errs. The goal is that a mistake becomes detectable: which source was returned, when it was approved, who may see it, what was missing and who fixes it. A knowledge base that cannot retire an old document or respect a permission change can give a fluent, wrong answer even when the model has not changed.

1. Build a source register before you index (ownership and freshness)

One row per source, not per folder. Each row answers: what is the document, who owns it, who is it for, when is it valid, what replaces it, and how is it removed from the index. Do not assume the newest file is the authoritative one: upload date can be later than content date, and a copy moved between folders can look new while being outdated.

Set a precedence order per type of information. A signed procedure might beat a training deck, and a numbered correction notice might beat the procedure until a new version is published. With no precedence rule, the correct state is "conflict" - do not ask the model to pick the document that sounds more convincing.

2. Separate active, historical and draft content

Historical documents matter for audit and learning, but they must not compete silently with the active one. Keep them in an access-controlled archive and take them out of the normal answer path with a status field and an effective date. A draft stays outside the active base until the content owner approves it; a file named "final" is not an approval.

Useful metadata: source_id, owner, audience, status, effective_from, reviewed_at, version, supersedes.

3. Preserve permissions end to end (access control for RAG)

Access to the knowledge base is not permission to see everything in it. At import, store the source's audience. At search time, filter results by the user's identity. In the answer, prevent showing, quoting or linking a document the user may not open. A broad service account is no reason to widen what a user sees.

Start with read-only access. Only the knowledge-base admin imports, disables or rebuilds. The model never gets write permission to the source documents. Deleting, changing an audience or replacing a version are logged admin actions, not the result of a chat.

4. Plan ingestion you can verify

A typical pipeline: ingest, extract text, chunk, embed, index, retrieve. Log each run with its sources, versions, successes and failures. A file is not searchable just because it was sent to an API; check that it reached a completed state. If ingestion is partial, keep the previous version active or block the topic. Do not ship a half-update without a flag.

5. Require a source the user can open

The answer should show a clear source name and a link that opens with the user's permissions. For testing, also keep source_id, version and chunk id. A citation shows the system linked a claim to a file; it does not prove the claim follows from it. Compare each material claim with the source sentence, check the context was not cut, and check the source was valid at answer time.

6. Build an acceptance test for questions and retrieval

For each test question, record the expected result at three levels: which sources should be retrieved, what may be concluded from them, and the correct decision state (answered, needs-clarification, conflict, no-valid-source). This separates retrieval failures from wording failures. If the right document never reached the context, a better prompt is not the fix.

Include: an ordinary question, a paraphrase, an English technical term, a superseded document, two conflicting versions, a user without permission, a file that failed ingestion, a question with no answer, and a deleted link.

7. Update and remove without a gray zone

Define a change path: the content owner approves a version, the admin ingests it, regression tests run, and only then does the active alias switch. Keep rollback, but never restore a document withdrawn for safety or privacy reasons. When a permission is removed, check every copy: source, cache, index, saved results and test environment.

Hypothetical example: an expense-reimbursement procedure

This is a proposed design, not tested at AI NEWS Israel and not a description of real results. Operations wants an assistant to answer travel reimbursement questions. There is an active procedure, an old training deck and a draft for next year. The procedure and an approved correction notice are active; the deck is marked superseded; the draft stays out. The answer states a rule or amount only if it appears in a valid source, with a link to the clause, the version and a decision state. Stop conditions: no active source, two equal sources in conflict, user not authorized, file not fully ingested, or an answer that adds a condition the source does not contain. "Please contact Operations" is a valid result - not a quality failure.

Failure cases

• Two active versions: stop with "conflict" and show both to the content owner.

• Partial ingestion: do not switch to the new index; log the file and error.

• Over-broad source permission: fix the sharing or remove the source until decided; an app-level filter is not a substitute for source controls.

• A valid document not retrieved: treat it as a retrieval failure; check extraction, chunking, metadata and query before changing answer wording.

• A citation that does not support the claim: block the claim and add the case to the regression set.

Published by Dr. Yaniv Shenhav, founder and CEO of the Israeli Institute for AI (IIAI), which runs practical AI training and adoption programs for organizations worldwide. The site is available in English, Hebrew and Arabic: https://www.iiai.co.il/en?utm\_source=hashnode&utm\_medium=syndication&utm\_campaign=kb-freshness-guide