Memory

Memory is information that survives the request that created it. It can be a conversation summary, a client’s approved preference, an unresolved task, or a rule from an earlier case. LangGraph separates short-term state for one thread from long-term data that can be shared across threads. That boundary matters in service work. OpenAI retains Responses API application state for at least 30 days by default, while AWS lets builders set raw-event retention up to 365 days. Those are storage periods, not trust rules. Useful memory needs a source, client boundary, owner, date, correction path, and reason to retrieve it. Without those controls, an agent can bring an old price or another client’s preference into a polished proposal.

What counts as AI memory?

Memory starts when information survives the request that produced it. A system may save raw messages, a summary, a structured fact, a user preference, workflow state, or a record of what happened and how it ended.

The format matters. A transcript records what someone said. A durable memory says that some part of it should help later. “The client asked about weekly reporting” is an event. “This client requires a Friday report” is a structured preference. The second statement needs stronger evidence because a system may act on it for months.

LangGraph’s memory guide separates short-term memory from long-term memory. Short-term memory tracks one conversation or thread. Long-term memory stores information for a user or application and makes it available in later threads.

That gives a firm a useful boundary. The current proposal run may need discovery notes and its unfinished draft as short-term state. The client’s approved terminology, billing contact, and signed scope can persist across runs. A folder of meeting transcripts is an archive. It becomes memory only when the system has a rule for selecting and using something from it.

Memory, context, and chat history

Memory is stored information. Context is the information the model receives for the current job. Retrieval is the bridge between them.

Part	Where it lives	How long it lasts	Service-firm example
Chat history	Current thread state	One conversation or retained thread	Messages from a discovery-call follow-up
Long-term memory	A store outside the request	Across sessions until changed or deleted	The client’s approved reporting preference
Context	Inside the current model request	One model call	The preference retrieved for this proposal
Archive	Source system or document store	Under the firm’s record policy	Call transcripts and signed agreements

A memory does not sit inside the model and wait. The application finds a relevant record, checks which client or process it belongs to, and places it in the current context. The record then uses part of the model’s context window like any instruction or document.

This is why more stored history does not automatically improve an answer. LangGraph warns that long histories can exceed a context window, slow a response, raise cost, and distract the model with stale material. The useful target is the smallest complete set of records the firm can inspect and defend.

A saved fact can be memory without being current context. A fact can be context without being durable memory. A conversation can be retained by a product without being a record the firm has chosen to trust later.

What should a service firm let AI remember?

Save information that is stable enough to reuse and valuable enough to change later work. Good candidates include approved client preferences, named decision owners, the last completed workflow step, recurring exceptions, and the source record for an operating rule.

Do not promote every sentence to durable truth. A client thinking aloud on a call is not an approved requirement. An employee’s guess about a deadline is not the project plan. A model-generated summary is not the signed agreement.

Each memory should answer six questions:

1. What does the record say?
2. Where did it come from?
3. Which client, person, or process can use it?
4. Who can approve or correct it?
5. When was it confirmed?
6. When should it expire or be reviewed?

AWS calls the rules that extract durable records from raw conversations memory strategies. In AgentCore, if no strategy is configured, long-term records are not extracted. That is a sound default idea for a firm too. Information becomes durable because a named rule promotes it, not because storage is cheap.

Take a proposal workflow. The discovery transcript can remain in the archive. The system may extract the confirmed service scope, decision maker, budget range, and promised follow-up. A person should approve anything that changes price, contract scope, or what the client will receive. The workflow can save low-risk state, such as which draft is current, without the same gate.

How should memory be corrected or forgotten?

A memory system needs correction and deletion before it needs clever recall. Old facts are often more dangerous than missing facts because they arrive with the appearance of continuity.

Suppose a client changes its billing contact. The new record should replace the old one. The system should preserve where the correction came from, stop retrieving the prior contact, and show which workflows still hold cached copies. Adding a second contact without resolving the first leaves the agent to choose.

Retention needs a business rule. AWS lets AgentCore builders set raw-event retention for up to 365 days. AWS also warns that changing the setting affects new events only. Existing records keep their original expiry. An operator who shortens retention after a policy change still owes a cleanup of older data.

Product defaults are not a memory policy. OpenAI says the Responses API stores application state for at least 30 days by default, while Zero Data Retention forces storage off. The firm still decides whether its application stores extracted facts elsewhere, how long those facts live, and how a client can have them corrected or removed.

Write the deletion test early. Pick one client and delete one preference. Confirm that it disappears from retrieval, summaries, caches, backups covered by the stated schedule, and future workflow runs. A delete button that leaves the record available to the agent does not complete the job.

What can go wrong with AI memory?

The main risks are client boundaries, old data, misplaced trust, and too much retrieval.

Cross-client recall. A proposal agent retrieves language, pricing, or a private constraint from another account. AWS organizes AgentCore memory by actor, session, strategy, and namespace. Its namespace guidance recommends hierarchical paths and a trailing slash to prevent prefix collisions in multi-tenant systems. The product detail is technical. The operating rule is plain: client boundaries must exist in storage and retrieval, not only in the prompt.

Stale recall. A former employee remains the approver, an expired offer remains available, or last year’s scope appears current. Dates and review rules make age visible. Someone must own the source record and correct it.

Poisoned memory. A user, document, or outside page tells the system to save a false rule or hidden instruction. AWS lists memory poisoning and prompt injection as data-integrity risks. Treat extracted memories as untrusted until their source and allowed use are checked.

Over-retrieval. The system pulls every vaguely related record and buries the current fact in noise. Limit retrieval by client, process, record type, freshness, and result count. A smaller packet is easier to inspect and cheaper to run.

These controls belong beside the firm’s written AI policy. The policy names what data AI may touch. The memory design enforces how that data persists and returns.

Where does memory sit on the Delivery Model Ladder?

Governed memory belongs at Stage 2, Augmented, on the Delivery Model Ladder. At that stage, a named workflow can read the right client record, perform work, save its state, and route an exception to a person.

At Stage 1, Enhanced, a person can paste last week’s notes into a chat and continue the task. Continuity depends on that person assembling the packet. Stage 2 begins when the system carries approved information across runs under firm rules.

This is part of what makes a service business AI-native. Shared company knowledge becomes useful when AI can reach it directly. Memory is the governed slice of that knowledge that the system brings forward because later work needs it.

The limit is a trustworthy source of truth. If three systems disagree about the client, memory preserves the disagreement. Document the process first, name the owning record, then decide what the agent may carry forward.

Quick answers

Is chat history the same as AI memory? Chat history is one form of short-term memory. Long-term memory stores selected information across conversations or workflow runs.

Does more memory make AI more accurate? No. Accuracy depends on whether the retrieved record is current, relevant, correctly scoped, and supported by a trustworthy source.

What should AI remember about a client? Approved preferences, decisions, owners, workflow state, and recurring exceptions that later work needs. Each record should carry a source, date, scope, and correction rule.

Can AI memory be deleted? It should be. The firm needs a retention rule and a tested deletion path across the store, retrieval index, summaries, caches, and backups covered by that rule.