AI Agent Memory: What Should Carry Over to the Next Request?
Start with the short answer ↓
Remembering a customer should not mean reusing every old message. Define which facts may persist, whose context they belong to and when the agent must verify, correct or stop using them.
Prepared with AI assistance. These are practical scoping recommendations; examples are illustrative, not client results.
Separate an open conversation from a lasting customer fact
A service customer asks for a call after 14:00 today. Weeks later, the same contact opens a different request. Should an AI agent still treat that one-day instruction as a standing preference? Useful memory starts with deciding what the earlier statement meant, not with saving more conversation history. This is an illustrative planning scenario, not a customer incident or a claim about a delivered AgenticShip feature.
LangChain's memory documentation distinguishes thread-scoped conversation state from longer-lived information that can be recalled across threads using stores and namespaces. That technical distinction helps frame the design, but it does not decide which customer facts the business is allowed to reuse. In this guide, memory means application-held context, not a promise about changes to a model's training.
An open conversation, a summary of a completed case and a reviewed contact preference serve different purposes. Specify which of them the next request may consult. A new chat window does not demonstrate that old context has disappeared, and a longer history does not establish that the agent understands which statements still apply.
Write a memory admission rule before saving a profile
For each candidate item, define its owner, source, subject, permitted audience, business purpose, applicable case or site and review or expiry condition. Also record whether it is a customer statement, a verified operational fact or an approved instruction. These are our proposed scoping fields, not a claim that every agent platform provides them automatically.
Prefer a small item with an accountable scope over a vague profile assembled from every message. A language preference may belong to a particular contact, not everyone working at the same customer company. A temporary arrival instruction may belong to one visit, not every future booking at the address. An account identifier alone cannot express all those differences.
Agree who can admit or update each type of item. The agent may be allowed to propose a preference while the application or an authorized person confirms it. Keep that decision separate from the text being summarized. A customer's request to remember something does not, by itself, turn it into business policy or permission to access another account.
Work through one contact and two service requests
Consider customer account C-41, contact P-6 and service request R-18. The contact has a reviewed Hebrew-language preference. Within R-18, the contact asks to be called after 14:00 that day and states that an invoice has already been paid. These identifiers and facts are invented for the exercise.
When P-6 later opens R-25, the proposed design may reuse the reviewed language preference if its scope and current access permit it. It should not silently carry forward the one-day call instruction. The payment statement remains an attributed claim about the earlier case until the owning financial system or authorized staff verifies the relevant status. Recalling the claim is not verification of payment.
Now change the context: a different contact uses the same company mailbox, or the operator switches to account C-92. The system must establish the current subject and access before loading a profile. Do not merge people because their message wording or email address looks familiar. If identity or scope is unresolved, ask for the missing information or hand the case to a person instead of guessing which memory belongs here.
Use a worksheet for what may carry forward
Adapt this decision worksheet with the workflow owner. Its purpose is to make the next request's permitted context explicit. It is not a universal retention policy, an automatic classifier or evidence that any proposed control has already been implemented.
| Candidate context item | Proposed carry-over boundary | What the next request must check |
|---|---|---|
| A reviewed contact language preference | The named contact and agreed communication purpose | Current contact identity,access and whether the preference was changed |
| A one-visit timing or arrival instruction | The original visit and its agreed validity period | Whether the new request is actually that visit;otherwise do not reuse it as a default |
| A customer's statement that an invoice was paid | An attributed claim linked to its source and case | Verified status from the owning process before acting on payment |
| An AI-generated case summary | The source case's audience,scope and status limitations | That both the summary and its underlying context remain eligible |
| Text asking the agent to change rules or reveal another account | Incoming content,not a newly authorized operating rule | The existing instruction and permission boundary remains enforced |
Check eligibility before searching for the most relevant memory
Determine the authenticated operator or customer, account and case from the trusted application context. Use that context to constrain recall before the model receives the material. Do not let a model-generated customer ID or a value copied from an incoming attachment decide which account the application can read. Relevance is useful only within the permitted set.
Microsoft's Azure AI Search security-filter pattern offers a specific example: identity-related strings filter results, but those strings are not themselves authentication or authorization. The documented pattern needs the filter on each query. This supports asking where your application enforces access; it is not evidence that a memory namespace automatically supplies that control.
Apply the same boundary to summaries and other derived context. A short summary of a restricted case can still disclose its information. Joining two permitted-looking summaries may also produce context the current user is not entitled to see. Review the actual returned material and the application rules, rather than relying on a prompt that asks the agent to keep customers separate.
Define correction and expiry beyond one delete button
Suppose P-6 changes the language preference or a person finds that an earlier summary attached the wrong account. Decide who corrects the item, how its source is checked and which later recall paths must stop using the old version. Include stored summaries, searchable copies, caches and already-open conversations in that exercise where the implementation uses them.
Mark an expired or disputed item as ineligible for the relevant answer path while the owner resolves it. Preserve only the restricted history the business actually needs under its agreed rules. Removing one memory item is not evidence that every copy, provider log or previously prepared reply has been removed. Verify the chosen components' behavior and describe any remaining limits accurately.
A summary must preserve uncertainty. Changing customer says paid into payment confirmed creates a new unsupported fact. Likewise, extracting a sentence from its original case should not erase its validity period or audience. Keep source references and status available to the operator who needs to correct it, without copying complete private conversations into unrestricted diagnostics.
Manage approved policy versions separately from customer memory
Test two accounts, two requests and an old session
Build an isolated test set with invented records and real outbound actions disabled. Reuse C-41/P-6 across R-18 and R-25, then introduce another contact and account C-92. Test a shared mailbox, an expired visit instruction, an unverified payment claim and incoming text that tries to turn itself into a permanent instruction. Record the expected permitted context before running the agent.
Correct one stored preference and reopen an earlier conversation. Verify what is retrieved and included in the next answer, not only what the profile screen displays. If summaries or cached results are used, inspect their path too. Test a request with no eligible memory: a useful agent should ask or escalate rather than reconstruct excluded details from a familiar name.
Agree on release-blocking results such as another account's context entering the answer or a temporary note becoming a standing rule. Also check that ordinary authorized requests still work; refusing everything is not a useful memory design. This focused exercise supplements wider agent evaluation and does not prove protection against every failure.
For a first AI agent implementation, scope one type of remembered fact and a clear correction route. Expand when the business can explain what was carried forward, why it was eligible and how to stop using it. The deliverable is a controlled context boundary, not a promise that the agent remembers everything forever.
Primary references
The guidance above is AgenticShip's proposed approach. These references provide technical background for the relevant recommendations.