You spend twenty minutes explaining your product, your competitors, and how you like reports written. The agent does a good job. On Monday you open a new chat, ask for the same report, and it asks who your competitors are.
Nothing broke. The agent simply had no place to keep what it learned. “Memory” is the usual name for the fix, but the word covers several different mechanisms, and they fail in different ways. This guide separates them and shows what belongs in each.
What is AI agent memory?
AI agent memory is everything outside the model that decides what the model can see on a given turn. The model itself does not learn from your conversations. It reads a block of text called the context window, produces a response, and keeps nothing. Every form of memory is a way of saving information somewhere else and putting the right part of it back into that window later.
That gives two questions for any memory feature: where is the information stored, and what causes it to be loaded again?
Types of AI agent memory at a glance
| Kind of memory | What it holds | How long it lasts | Who writes it | Typical failure |
|---|---|---|---|---|
| Context window | Everything the model sees this turn | One model call | The harness assembles it | Too much in it; important details get less attention |
| Session history | Messages and tool results from one conversation | As long as the conversation is stored | Saved automatically | A new conversation starts empty |
| Compaction summary | A condensed version of older history | The rest of that conversation | A model, when history gets long | A detail you needed is summarized away |
| Instruction files | Standing rules: conventions, commands, preferences | Until someone edits the file | Mostly you | Grows long, contradicts itself, gets ignored |
| Agent-written memory | Notes the agent saves about you and the work | Until edited or deleted | The agent | A wrong or outdated note is treated as fact |
| Retrieval memory | Facts extracted from past conversations, searched on demand | Until removed or invalidated | An extraction pipeline | Retrieves something similar but wrong, or misses the right item |
| Workspace files and artifacts | The work itself: data, drafts, reports, code | As long as the storage lasts | The agent and you | The workspace is temporary and the files vanish |
Why does my AI agent forget things between sessions?
Your agent forgets because each new session starts with a fresh context window, and nothing from the last one is loaded unless the product around the model loads it. Claude Code's documentation states this directly: each session begins with a fresh context window, and only specific files carry knowledge across. See How Claude remembers your project.
Forgetting inside one long conversation has a different cause. When history approaches the window limit, many systems compact it: a model writes a summary and the older messages are dropped. In Anthropic's API, compaction triggers at 150,000 input tokens by default, and content before the summary is not sent again. Anything the summary left out is gone from the model's view.
So there are two fixes. Information that must survive a long conversation should be written down before compaction. Information that must survive into next week needs a store that a new session actually reads.
What are CLAUDE.md and AGENTS.md files?
They are plain Markdown instruction files that a coding agent loads at
the start of every session. You write down what you would otherwise
repeat: build commands, conventions, and “always do X” rules.
AGENTS.md is an open format for this,
now stewarded by the Agentic AI Foundation under the Linux Foundation.
CLAUDE.md is Claude Code's equivalent.
These files cost context on every session, so short wins. Claude Code's docs suggest keeping each file under 200 lines and note that longer files reduce how reliably the instructions are followed. They also note that the files are context, not enforcement. A rule that must always hold belongs in a permission or a hook.
A multi-step procedure that only matters for some tasks is better packaged as a skill, which loads when relevant. Our Agent Skills vs MCP guide covers that format.
Can an AI agent write its own memory?
Yes. Several systems give the agent a tool for saving notes that later sessions read. The common design is ordinary files.
Anthropic's
memory tool
lets Claude create, read, edit, and delete files under a
/memories directory. It runs client-side: Claude requests
the file operation and your application performs it against storage you
control. The docs tell implementers to validate every path, cap file
sizes, and expire files that have not been read in a long time.
Claude Code's auto memory works similarly. Claude saves notes about
your preferences, corrections, and project decisions as Markdown files,
with a MEMORY.md index. Only the first 200 lines or 25KB of
the index load at session start, and topic files are read on demand. You
can open, edit, or delete any of it.
The appeal is that you can inspect it. When the agent believes something wrong, you can find the line and fix it.
How do I give an AI agent long-term memory?
Store facts outside the conversation and load the relevant ones into context when a new task starts. If you are building the agent yourself, there are three common routes.
- Files the agent maintains. The memory tool pattern above. Simple and easy to audit. It depends on the agent keeping the files tidy.
- A framework store. LangGraph separates short-term memory, which is thread state saved by a checkpointer, from long-term memory kept in a store under namespaces you choose, readable from any thread.
- A dedicated memory layer. Mem0 offers an API for adding and searching memories, hosted or self-hosted. Letta pins editable memory blocks into the agent's context and keeps all state in a database, so evicted messages can still be retrieved. Zep builds a temporal knowledge graph and records when a fact stopped being true.
If you are using an agent product instead, the question is simpler: does it keep your conversations, your files, and your preferences, and can you see and edit what it remembers?
How well does long-term AI memory actually work?
Published benchmarks say it is still hard. LoCoMo is a dataset of very long conversations, averaging about 300 turns across up to 35 sessions. Its authors found that long-context models and retrieval both helped, and that models still trailed humans by a wide margin, especially on temporal and causal questions.
LongMemEval (ICLR 2025) uses 500 questions to test five abilities: information extraction, multi-session reasoning, temporal reasoning, knowledge updates, and abstention. The authors report a 30% accuracy drop for commercial chat assistants and long-context models when they must remember information across sustained interactions.
Two of those abilities deserve attention. Knowledge updates test whether the system notices that a fact changed. Abstention tests whether it admits it does not know. Those are the failures that hurt in real work. Vendors often publish their own scores on these benchmarks, so read the setup before comparing numbers.
A worked example: a weekly competitor report
Suppose an agent prepares a competitor report every Monday. Here is where each piece belongs.
| Information | Where it belongs | Why |
|---|---|---|
| This week's pricing pages and changelogs | Context window, then a workspace file | Needed now; saved as a snapshot for next week's comparison |
| Your follow-up questions about this week's draft | Session history | Only matters inside this conversation |
| The competitor list, the audience, and the report format | Project instructions | True every week; should load every time |
| The method: sources to check, how to verify, how to cite | A skill | A procedure, loaded when the task runs |
| “Keep it under one page” and “we stopped tracking Acme in August” | Agent-written memory | Preferences and decisions learned along the way |
| Past reports and raw snapshots | Workspace files and artifacts | The record itself; too large to keep in context |
Notice what memory does not hold: last week's prices. Those live in a dated file, and the agent reads the file when it needs the comparison. A memory that says “Acme charges $49” will be wrong the week Acme changes its pricing, and nothing will flag it.
What should an AI agent not remember?
An agent should not store secrets, facts that change often, or details that only mattered once.
- Secrets. API keys, passwords, and tokens belong in a credential store. Memory is text that gets pasted into prompts. Anthropic's memory tool docs recommend validation that strips sensitive data before a write.
- Facts with a short shelf life. Prices, headcounts, and statuses. Store where to look them up.
- Anything the agent can look up. Claude Code's auto memory skips what it can derive from the codebase. The same rule works elsewhere: a connected tracker is the source of truth for ticket status.
- One-off details. The file name from a single task helps nobody next month.
- Guesses. An inference saved as a fact comes back later with no sign it was ever a guess.
- Other people's personal information, unless you have a reason to keep it and a way to delete it.
What goes wrong with AI agent memory?
Three problems cause most of the trouble: stale memories treated as true, context bloat, and privacy.
Stale memories. A saved note carries no doubt. The agent reads “the user is on the Pro plan” with the same confidence a year later. Useful defenses are dates on memories, a habit of checking the live source before acting, and a place where you can review and delete entries. Zep records when a fact became invalid, and Claude Code stamps memory files with a modified time for the same reason.
Context bloat. Loading every memory on every turn crowds the window with material unrelated to the task, and costs tokens each time. Anthropic's context engineering guide describes loading information just in time instead. This is why index files are capped and why retrieval exists.
Privacy and scope. A memory saved in one project can surface in another. Ask of any memory feature: who can read it, which work it applies to, and how you remove an entry. A memory store is also a place where injected text can persist, so an agent should not save instructions it found in a web page or document.
How this works in Dexto
We built Dexto so the Monday-morning problem does not happen. Each layer above has a home, and you do not have to assemble them yourself.
Conversations persist. Dexto Cloud keeps the durable record of sessions and runs, including conversation history, so you can return to a conversation and continue it. The platform primitives page describes what is stored.
Projects hold standing instructions. A project groups related chats with optional instructions, skills, apps, and connections. The competitor list and report format from the example go there once.
Memory is agent-written and visible. Dexto's Memory learns preferences and decisions from your conversations. Tell it that weekly updates should be short and bulleted, and the next update follows that. You manage what it has saved in the Brain app. Dexto's agents are instructed to keep stable preferences, project facts, and decisions in memory, and to keep secrets, raw transcripts, temporary task state, and guesses out of it.
Skills hold procedures. The Skills Library keeps repeatable methods out of the permanent prompt and loads them when a task calls for them.
Files and artifacts hold the work. Dexto has a persistent cloud computer where it stores files, runs code, and opens browsers, so last week's snapshots are there for this week's comparison. Finished reports can be saved as artifacts, which collect in one app across chats. Workspace files and artifacts have different lifecycles, so promote the work you want to keep. Our AI sandbox platforms comparison explains why a lasting workspace matters.
Loops run the recurring part. A Loop runs a task on a schedule, such as every Monday, and you can check what happened after each run.
Together these are the persistence and context jobs of an agent harness.
Does a bigger context window replace memory?
No. A larger window lets one conversation run longer before compaction, but a new session still starts empty, and every token in the window is paid for on every call. LoCoMo and LongMemEval both found that long-context models still struggle with information spread over many sessions. Window size is one factor when choosing a model; it does not decide what should be kept.
Is RAG the same as agent memory?
Not quite. Retrieval-augmented generation searches a body of documents and adds the matches to the prompt. Agent memory often uses the same search techniques, but the content is different: it is written during the agent's own work, it is about you and your projects, and it has to be updated or retired as things change. RAG answers “what do the documents say?” Memory answers “what did we already decide?”
How do I try an agent that remembers?
Pick one task you explain to an agent every week. In Dexto, put the standing instructions in a project, state your preferences once, and schedule it as a Loop. Start at app.dexto.ai, or read the docs first.