Memory in AI Agents: What They Remember Between Sessions and What They Don't
AI agent memory is the set of notes that survive a session: written instructions, automatic notes and external stores. What each one holds and how it works.
Why doesn’t an agent remember by itself?
A language model does not learn while you talk to it. What it knows during a session is whatever sits in its context window: instructions, history, tool results. When the session ends, that window disappears. The next session starts blank.
That makes memory a design problem, not magic. It is part of what is called context engineering. Someone has to decide what gets stored, where, who writes it and how it is loaded again. If nobody decides, the agent asks the same questions again, repeats mistakes you already corrected and forgets the project conventions.
What types of memory exist?
In practice three forms show up, each with a different owner:
| Type | Who writes it | What it contains | Example |
|---|---|---|---|
| Permanent instructions | A person | Rules and conventions | A CLAUDE.md file with the project commands |
| Automatic memory | The agent | Lessons from corrections | “In this repo, tests run with pnpm test” |
| External memory | Tools or processes | Data you can query | A database of decisions or a vector index |
The first two are files the tool loads at startup. The third is usually queried only when needed, so it does not fill the context window. Anthropic offers the memory tool in its API for this: Claude asks to create, read, edit or delete files inside a /memories directory, and your application runs those operations against storage you control. That way the agent reads only what it needs for each task instead of loading everything up front.
How does automatic memory work?
Claude Code has two mechanisms. The first is CLAUDE.md, instructions a person writes. The second is auto memory: notes Claude writes itself from your corrections and preferences. According to its documentation, both “are loaded at the start of every conversation” and Claude “treats them as context, not enforced configuration”.
Auto memory is scoped per repository and shared across worktrees. It lives on your machine, in a folder with a MEMORY.md index and one file per topic, and it is not shared with other machines. At the start of a session only the first 200 lines or 25 KB of the index are loaded, whichever comes first; anything beyond that is not read. You can view, edit or delete those notes with the /memory command: they are plain markdown files.
Subagents are a separate case. They do not inherit the main conversation’s auto memory, but they can be given their own persistent memory through the memory field in their configuration.
Why does it matter to a designer?
Because memory defines how fast a team learns with an agent. A designer working with agents can write down decisions that used to live in someone’s head:
- Which components of the design system must be used and which are deprecated.
- What “done” means for an interface change.
- Which copy and tone must be respected in microcopy.
- Which screens or folders must not change without review.
That information is what stops the agent from inventing colors or duplicating buttons in every session.
How do you design memory that works?
A few practical rules:
- Separate facts from notes. What is always true (commands, conventions) goes into instructions. What is learned over time goes into automatic memory or into a log you can review.
- Keep it short. The shorter and more concrete the text, the more likely it is followed. A file that grows without control becomes noise.
- Put what is critical first. If the agent only reads the first lines, what matters must be there.
- Review the memory. An automatic note can be wrong. Read it as if it were someone else’s code.
- Use technical controls for non-negotiables. A hook that blocks deleting protected folders works better than a sentence in memory.
Example
Illustrative example: a product team uses an agent to maintain its component system. In the first week, the agent creates a new button every time it needs one. The team writes in the instructions file that the system’s Button component is the only one allowed, and adds a rule: “if you need a new variant, propose it in an issue before creating it.” The next week, the agent stops duplicating buttons. When it makes a new mistake, the team fixes it in the same file, not in the chat, so the next session has it.
What happens when memory grows?
Over time, memory fills up with notes that contradict each other: one says you use a color, another says you removed it. An agent that reads both may pick the wrong one, or neither. Treat memory like a changelog: every so often, delete what is obsolete and merge what repeats. A simple practice is to date each note and record which decision supports it. If a note has no support, delete it. The same goes for memory the agent writes itself: a lesson that is correct in one repository can be false in another, so check which project it was saved in.
What you can do tomorrow
Open the instructions file or the memory of a project you use every day. Look for three things: a note that is no longer true, a rule repeated in two places, and a sensitive detail such as a key, an email or an identifier. Delete or move the first, merge the second and take the third out of the file. Then ask the agent to explain what it remembers about the project and compare its answer with what you know.
Common mistakes
- Believing the agent “already knows” what you did in another session when nothing was stored anywhere.
- Storing keys, tokens or customer data in a versioned memory file.
- Letting memory grow with old notes that contradict the new ones.
- Trusting that a memory instruction prevents an action. It is context, not a technical prohibition.
- Not reviewing what the agent wrote on its own. A wrong automatic note repeats in every session.