Agent memory — what an AI system may carry from past runs

Golden rule: Agent memory is not a warehouse for everything the model has ever seen. It is a controlled system of reminders, evidence, and corrections. If it cannot be explained, sourced, and deleted, it should not be long-term memory.

Memory is not a longer context window

The context window is the workbench of the current moment. Memory is the filing cabinet an agent returns to across runs. These two are often confused because both eventually become text shown to the model. Operationally, they are different things.

A longer context helps with one long task. Memory handles repeated work: what the user prefers, how a project works, what failed last time, which decision still applies, and what should not be reopened next time. The more an agent acts over time, the more it needs memory outside the model itself.

Three layers worth separating

Working memory holds the current plan, intermediate results, and facts needed for the next step. It usually lives inside one task run and disappears when the task is done.

Episodic memory stores what happened: decisions, errors, human interventions, and task outcomes. It is useful for audit and for preventing the agent from repeating the same dead end.

Semantic memory stores more stable knowledge: project rules, user preferences, system names, internal vocabulary, and verified procedures. It should not be an unlimited diary. It should be a structured source that can be retrieved and corrected.

For example, a user changes their preferred language from Czech to Polish, or a team retires an old project rule. Store the new record with its source and validity, mark the old one as no longer valid, and do not retrieve it merely because it resembles the new request.

The biggest risk is a bad memory

Memory increases usefulness and risk at the same time. An agent that remembers a bad assumption can carry it into later tasks as if it were obvious truth. Personalization then stops looking like a model error and starts looking like “the system knows what you want” — except it knows it wrong.

That is why memory needs provenance, age, and confidence. Every record should have a source: who created it, which event produced it, when it was last used, and whether a human confirmed it. Memory without metadata is a rumor with an API.

Retrieval matters as much as storage

Storing something is cheap. Pulling the right thing at the right time is harder. An agent does not need to see its whole past; it needs a small, relevant slice with a clear reason for entering the context.

Good memory therefore combines retrieval, filters, priority rules, and permission to stay silent. If a record is not clearly relevant, it should not be pushed into the prompt just because it exists. Overstuffed memory can degrade an answer as reliably as missing memory.

Operating rule: memory must be readable, deletable, and testable

Memory is both a product feature and a security surface. The user or administrator must be able to see what the system remembers, correct it, and delete it. For sensitive data, it must be clear whether it belongs in long-term memory at all.

Teams should test not only whether memory helps, but also when it hurts: old preferences, changed roles, cancelled projects, conflicting instructions, private data, and records imported from an untrusted source. Memory that nobody evaluates is just a slower way to reproduce old mistakes. Long-lived conversation state and its management are distinct parts of an agent system, rather than merely a longer single prompt. OpenAI: Conversation state

Sources

• OpenAI: Conversation state
• NIST Privacy Framework