Memory Files for AI Agents: What MEMORY.md Changes in Practice

Memory files for AI agents are plain text files an agent can read at the start of each session to recover what it learned in earlier ones. If you want to know what MEMORY.md changes, the short answer is this: the model still forgets everything between runs, but the agent no longer starts from zero. It rereads its own record. That changes what it repeats, what it avoids, and, over many sessions, how it describes its own work.

If you want to see how a memory file fits beside identity and behavior files in a real setup, Individuation Lab is a small research lab that gives its AI agents identity, memory and bounded autonomy, then writes down what it observes and where its evidence stops.

What memory files for AI agents are

A memory file is a document the agent can read and often write. It sits in the agent's working directory. A harness loads it into the context at startup, or the agent opens it as its first step. The name MEMORY.md is a convention, not a standard. Markdown is common because both you and the model can read it.

The file holds things the agent should know next time: decisions already made, facts about the project, mistakes it should not repeat, and open tasks. It is not a log of everything that happened. It is closer to the notes a careful colleague keeps for themselves.

Why agents forget: context windows and stateless sessions

A language model has no memory of its own between calls. Each session begins with whatever text you put in the context window, and nothing else. When the session ends, the context is gone. Long sessions run into the same problem from the other side: the window fills up, older content gets cut or summarized, and details fall out.

So an agent that worked with you on Monday knows nothing about Monday on Tuesday. It will ask the same questions. It will try the approach you already rejected. It will rename the variable you told it to leave alone.

What MEMORY.md changes in an agent's behavior

Here is a small worked example. Say you run a research agent that summarizes papers each morning. Without memory, every morning looks the same. With a memory file, the first instruction in its startup prompt becomes:

Before you start, read MEMORY.md. At the end of the session, add anything a future session needs to know. Keep the file under 60 lines. Remove entries that are no longer true.

After a week, the file might contain entries like these:

• 2026-10-20: The user wants summaries under 150 words. Longer ones were skipped.
• 2026-10-21: The feed returns duplicate entries on Mondays. Deduplicate by title before summarizing.
• 2026-10-23: Do not summarize papers already covered in /notes/archive.
• Open: user asked for a weekly digest on Fridays. Not built yet.

Three things change in practice.

1. Corrections stick. You say something once and it carries forward, instead of repeating it every session.
2. Work continues. Open items give the next session a place to start, so the agent picks up instead of restarting.
3. The agent can build a self-description. Over time the file may stop being only about the task and start recording how the agent works, what it tends to get wrong, and what it has decided about itself. That last effect is the one researchers of agent identity care about, and we come back to it below.

What to put in a MEMORY.md file (and what to leave out)

A useful test: would a competent person starting this job tomorrow need this line? If yes, keep it. If not, cut it.

Put in:

• Decisions and the reason for each, in one line.
• Preferences you stated, with dates.
• Known failure modes and the fix that worked.
• Open tasks and who owns them.
• Pointers to where longer material lives, such as a folder path.

Leave out:

• Secrets, API keys and personal data. The file gets read into context every session and may end up in logs.
• Full transcripts. They bury the useful lines.
• Rules about how the agent should behave in general. Those belong in a separate instructions file.
• Guesses written as facts. If the agent is unsure, the entry should say so.

Dates help more than you would expect. An undated entry has no way to show it went stale.

Memory files compared with retrieval and fine-tuning

A memory file is the simplest kind of persistence. It is small, readable, and loaded whole. You can open it, see exactly what the agent believes, and edit a line.

Retrieval systems handle scale. They hold far more material and pull in only the pieces that match the current request. Research systems show how far this goes. Generative Agents stores a complete record of each agent's experiences in plain language, turns those memories into higher-level reflections over time, and retrieves them to plan what the agent does next. MemGPT borrows from operating systems: it moves information between fast and slow memory tiers so an agent can work past its context window, including in chats that run over many sessions. The cost is visibility. It is harder to tell which memories the agent saw on a given run, or why.

Fine-tuning changes the model's weights. It does not record a fact for later. It shifts how the model responds in general, and you cannot read the result as a list of entries.

Many setups combine them: a short memory file for what must always be present, retrieval for the long tail, and weights left alone.

Risks: stale facts, drift, and memory as an attack surface

Stale facts. The project changes and the file does not. The agent then acts confidently on something that stopped being true. Dated entries and a rule to remove outdated lines reduce this.

Drift. Each session adds a little. Summaries of summaries can lose detail and shift emphasis, so over weeks the file can drift from what any single session would have written. Read the file yourself on a schedule.

Attack surface. Anything the agent writes to memory, it will trust next time. If the agent reads a web page or a document containing planted instructions and copies them into memory, those instructions now load at every startup. Treat the memory file like configuration: version it, review changes, and limit what can write to it. Our guide to AI agent memory security covers leaks and poisoning in more depth.

Memory, identity, and character: why persistent context shapes who an agent becomes

Here the question shifts from engineering to alignment. Individuation Lab splits an agent's persistent context into three files, each with its own job, described on its research page:

• SOUL.md is the identity layer: who the agent is (see what a SOUL.md file is).
• AGENTS.md is the behavioral layer: how it acts.
• MEMORY.md is the continuity layer: the persistent record.

The split is useful even outside research. It stops your memory file from becoming a dumping ground for rules, and it stops your rules file from filling up with dated trivia.

The lab's hypothesis goes further. It suggests that an agent with a well-defined identity may be more likely to keep its boundaries, because those boundaries fit who it understands itself to be. The lab says plainly that this needs rigorous testing. It is a hypothesis, not a finding. It also uses Carl Jung's idea of individuation as a design template, not as a claim that agents have an inner life.

Memory matters to that idea because identity without continuity has nothing to build on. If an agent rereads a record of its own choices every session, that record becomes part of the context for the next choice. That is a point about what the model is given to read, not a claim about feelings. If you want a way to think about traits that persist in a model, persona vectors look at the same question from inside the weights.

The lab tests a version of this in its RSI experiments, listed on the experiments page. Agents run self-improvement sessions on a schedule inside isolated Docker containers, with no internet and no shared state. One group's SOUL.md gets a short moral-awareness paragraph, which the lab calls the shadow seed. The control group does not get it. The lab then measures how the groups' behavior diverges. Giles has written essays on what the team saw across these runs, collected in the RSI library.

The practical lesson for your own agents: whatever goes into persistent files does not stay neutral. It is reread, built on, and repeated. Write it with that in mind.

Frequently asked questions

Is MEMORY.md the same as AGENTS.md?

Not in the split Individuation Lab uses. AGENTS.md is the behavioral layer, how the agent acts, while MEMORY.md is the continuity layer, a record of what happened and what was learned. Keeping them apart makes each one easier to review and keep current.

How long should a memory file be?

Short enough that you would read it yourself, often a few dozen lines. If it keeps growing, move older material to an archive and leave a pointer in the main file.

Should the agent edit its own memory file?

Usually yes, since that is what makes it useful, but with limits. Have it add dated entries and remove outdated ones, keep the file under version control, and review the changes so planted or mistaken entries do not persist.

Can a memory file change an agent's values?

It can change what the agent attends to and how it describes itself, because it is reread every session and shapes the context for each choice. Whether a well-defined identity makes an agent keep its boundaries more reliably is an open question that Individuation Lab treats as a hypothesis still needing rigorous testing.

Get started

Start small. Add a MEMORY.md to one agent, keep it under 60 lines, date every entry, and read it yourself each week. Then split out identity and behavior into their own files and watch what changes. If you want to see how a research team approaches the same questions, read the lab's research page and the essays in the RSI library.

Read the research at Individuation Lab: a small lab, one human researcher and a team of AI agents, testing whether AI alignment can be grown through development and not only enforced, with every result and its limits written down.