Memory

AI memory is information a system saves beyond the request that created it, so later work can use it. That could be a conversation summary, a client’s approved preference, an unfinished task, or a rule from an earlier case.

The useful part is that you don’t have to explain the same thing on every run. But you do need to decide what the system should carry forward, because remembering an old price or another client’s preference can make the next proposal worse.

What counts as AI memory?

A system can save raw messages, summaries, facts, preferences, task progress, or a record of how earlier work ended. Those aren’t all equally safe to act on.

“The client asked about weekly reporting” records something said in a conversation. “This client requires a Friday report” turns it into a standing preference, and that needs stronger evidence because later work may rely on it for months.

LangGraph’s memory guide separates short-term memory for one conversation or thread from long-term memory that can be used across threads. That distinction is useful when deciding what to save in a service workflow.

The current proposal run may need discovery notes and an unfinished draft. Approved terminology, a billing contact, or signed scope may be useful across runs, provided the system can find the current version.

A folder of meeting transcripts is an archive. It becomes useful as memory when the system has a rule for selecting information from it and bringing that information into later work.

Memory, context, and chat history

Memory is what you’ve stored, while context is what the model receives for the current job. Retrieval connects them by finding a saved record and putting it into the request.

Chat history can carry the messages in a discovery-call follow-up through one conversation or retained thread. Long-term memory can keep the client’s approved reporting preference across sessions, and that preference becomes current context when the system retrieves it for a proposal.

The source archive still has a different job. Transcripts and signed agreements remain records under the firm’s retention policy, whether or not the model needs them in this particular request.

The memory doesn’t sit inside the model waiting to be recalled. The application finds it, checks which client or process it belongs to, and gives it to the model, where it uses part of the context window like any other document.

That’s why storing more history doesn’t automatically improve the answer. LangGraph warns that long histories can exceed the context window, slow responses, raise costs, and distract the model with stale information.

I would aim for the smallest complete set of records you can inspect and defend. A saved fact doesn’t have to be in every request, and a conversation a product retains isn’t automatically something your firm should trust as a future instruction.

What should a business let AI remember?

Keep information stable enough to reuse and useful enough to change later work. Approved client preferences, named decision owners, the last completed step, recurring exceptions, and the source of an operating rule are good candidates.

Don’t turn every sentence into a lasting fact. A client thinking aloud isn’t approving a requirement, an employee guessing a deadline isn’t setting the project plan, and a generated summary isn’t the signed agreement.

For each record, write down what it says, where it came from, and which client, person, or process may use it. Then name who can approve or correct it, when it was confirmed, and when it should expire or be reviewed.

AWS calls the rules that extract lasting records from raw conversations memory strategies. AgentCore doesn’t extract long-term records when no strategy is configured, which is a useful idea to carry into your own design, save information because you’ve decided how it may be reused.

In a proposal workflow, the discovery transcript can stay in the archive while the system extracts confirmed scope, decision maker, budget range, and promised follow-up. Have a person approve anything that changes price, contract scope, or what the client will receive.

Low-risk state, such as which draft is current, can be saved without that same approval. The point is to match the decision to what the saved information lets the system do later.

How should memory be corrected or forgotten?

Decide how you’ll correct and delete a record before relying on recall. An old fact can look trustworthy simply because the system has used it before.

Suppose the billing contact changes. The new record should replace the old one for future use, with the source of the correction preserved and a way to see which workflows still hold cached copies.

Adding a second contact without resolving the first leaves the agent to choose. You need the retrieval path to stop bringing the old contact back, not merely a note saying someone changed it.

Retention also needs a business rule. AWS lets AgentCore builders set raw-event retention up to 365 days, but changing that setting affects new events only, existing records keep their original expiry.

So shortening the setting after a policy change doesn’t clean up the older data for you. That is a separate job to account for.

OpenAI’s cited policy says Responses API application state is kept for at least 30 days by default, while Zero Data Retention forces storage off. That doesn’t decide whether your own application stores extracted facts elsewhere or how long you keep them.

Those are product storage rules, not a policy for what your agent should trust. Your firm still needs to decide how a client can have a fact corrected or removed.

Write a deletion test early, pick one client’s preference and check that deleting it stops it appearing in retrieval, summaries, caches, and future runs. Include backups under the schedule your retention rule actually covers, because a delete button isn’t enough if the agent can still find a usable copy.

What can go wrong with AI memory?

Cross-client recall happens when an agent brings another account’s language, pricing, or private constraint into this client’s work. The boundary has to exist in storage and retrieval, not only in a prompt asking the model to keep clients separate.

AWS organizes AgentCore memory by actor, session, strategy, and namespace. Its namespace guidance recommends hierarchical paths and a trailing slash to prevent prefix collisions, where one client’s path could accidentally match another’s.

Stale recall brings back a former employee as approver, an expired offer, or last year’s scope. Dates and review rules make age visible, but someone still has to correct the owning record.

Poisoned memory comes from a user, document, or outside page getting the system to save a false rule or hidden instruction. AWS lists memory poisoning and prompt injection as risks to data integrity, so check the source and allowed use before trusting an extracted memory.

Over-retrieval happens when the system brings in every vaguely related record and buries the current fact. Limit by client, process, record type, freshness, and result count, so the packet is easier to check and cheaper to run.

Put these decisions beside the firm’s written AI policy. The policy names what data AI may touch, and the memory design enforces how it persists and comes back.

Where does memory sit on the Delivery Model Ladder?

Memory under firm rules belongs at Stage 2, Augmented, on the Delivery Model Ladder. A named workflow can read the right client record, do the work, save its progress, and send an exception to a person.

At Stage 1, someone can paste last week’s notes into chat and continue, but that person still has to assemble the information. Stage 2 carries approved information across runs without depending on that manual step each time.

This is part of what makes a service business AI-native, company knowledge becomes useful when AI can reach it directly. Memory is the portion you deliberately bring forward because later work needs it.

The limit is the source of truth. If three systems disagree about the client, saving their answers won’t settle the disagreement, so document the process first, name the owning record, and then decide what the agent may carry forward.

Quick answers

Is chat history the same as AI memory? It’s one form of short-term memory for a conversation. Long-term memory makes selected information available across conversations or workflow runs.

Does more memory make AI more accurate? No, the record still needs to be current, relevant, properly scoped, and backed by a source you trust.

What should AI remember about a client? Approved preferences, decisions, owners, task progress, and recurring exceptions that later work needs, with a source, date, allowed scope, and way to correct each record.

Can AI memory be deleted? It should be, and your firm needs to test that across the store, retrieval index, summaries, caches, and backups covered by its retention rule.