Agent memory is the set of mechanisms that let an agent store information outside the context window and pull it back when needed. It addresses a very concrete experience: close the session and the model remembers nothing; start a new task and the preferences you stated last week, the naming convention you agreed on, and the mistake you corrected all have to be explained again.
The term heated up noticeably in 2026 because agent task durations grew. One-shot Q&A needs no memory, but an agent working for days across many sessions on the same project must be able to carry forward what has already been established and what already went wrong.
Grab It in One Sentence First
The context window is the desk; memory is the filing cabinet. The desk is cleared daily; the cabinet has to survive across days and projects.
Think of a new assistant. On day one you explain your preferences: reports fit on one page, don't schedule meetings Friday afternoon, client A's contact person changed. If they wake up with amnesia every morning, you re-explain daily — not because they lack ability, but because they have no files. Agent memory is that cabinet, plus rules for what gets filed, where, and when it comes back out.
The Usual Categories
The common taxonomy borrows from cognitive psychology. It isn't rigorous, but it guides implementation well enough.
Working memory is the live context, gone when the session ends. Episodic memory records what happened — what was discussed on a given day and why a decision went that way. Semantic memory holds stable facts and preferences — the user's role, the project's stack, the team's naming conventions. Procedural memory holds how things got done — which workflow succeeded, which approach was rejected.
The engineering difficulty isn't storage; it's retrieval and updating. Store too much and noise drowns signal at retrieval time. Retrieve too much and you burn the context budget. Worse, facts change: the user moves roles, the project switches frameworks, last month's agreement is overturned. The system has to recognize that an old memory has been superseded rather than feeding the model two contradictory statements at once.
Common Implementations
File-based memory is the simplest and most widespread: put a Markdown file at the project root and read it into context at session start. AGENTS.md in the coding-agent world is exactly this pattern — no vector store, no extra service, and Git gives you versioning and review. Its limit is that it doesn't filter itself; as the file grows it eats the window.
Vector-retrieval memory turns memory entries into embeddings stored in a vector database and retrieves by semantic similarity. It's flexible and scales, but it's inherently insensitive to facts changing over time — the stale statement and the current one are equally close in meaning.
Graph memory stores entities and relations in a knowledge graph, and some implementations attach time information to each edge so a fact can carry the period in which it held. Where state has to be tracked across many sessions, these approaches generally outperform pure vector retrieval on temporal-reasoning evaluations.
Tiered memory treats context as RAM and external storage as disk, with the agent deciding when to page content in and out. MemGPT is the representative work in this line.
In practice these get mixed: stable preferences in a file, conversation history in vector retrieval, relationships and state in a graph.
Versus Neighboring Concepts
Versus context engineering. Context engineering governs what goes into this turn's window; memory is one of its sources. They nest rather than compete.
Versus RAG. RAG retrieves from an external knowledge base — documents, manuals, web pages — that is relatively stable and not tied to a particular user. Memory retrieves what this agent itself experienced: private, incrementally written, and liable to be overturned by later facts. The technology overlaps heavily; the lifecycle does not.
Versus context compaction. Compaction swaps history for a summary when the window fills, and its scope is the current session. Memory has to survive across sessions. Compaction is often the first stage of memory extraction.
Versus fine-tuning. Fine-tuning writes information into weights, changing behavioral tendencies at high cost and slow update speed. Memory lives outside the model and can be added, edited, or deleted at any time. Personalization should almost always go to memory, not fine-tuning.
Where People Get It Wrong
"A big enough context window removes the need for memory." It doesn't. However large, the window clears at session end, and the fuller it gets the more attention is diluted and the more it costs. Memory's value is retrieving a small amount of the most relevant material on demand, not carrying everything.
"More memory is better." Once a memory store grows, the dominant failure mode shifts from "can't recall" to "recalls wrongly." Retrieving an expired preference is worse than remembering nothing, because the model will act on it. Forgetting and updating matter as much as writing.
"Memory is a reliable source of fact." Most memory entries are extracted from conversation by the model itself, and that extraction step hallucinates too. Facts involving money, permissions, or compliance shouldn't rest on memory alone; verify against an authoritative source.
"Memory can be freely shared." In a multi-user system, memory inherently carries personal information. Whose memory it is, who may read it, how long it's retained, and how it's handled on export are privacy questions that belong in the design phase, not a retrofit.
When to Build It
One-shot Q&A and stateless API calls need no memory. Consider it seriously when any of these appear: the same user returns repeatedly, tasks progress across multiple sessions, the team wants one person's correction to stick for everyone, or you notice yourself pasting the same background at the start of every conversation.
Start simple: fix stable preferences in a hand-maintained file, run for a while, see which entries actually get used repeatedly, and only then decide whether vectors or a graph are warranted. Teams that jump straight to the complex option usually end up storing a great deal and retrieving little that helps.