Anthropic Explains How Claude Decides What to Remember — Why a Wrong Memory Note Gets Trusted Later, and Why Only Part of Memory Loads Each Session (2026)

The post defines agent memory narrowly. It's "knowledge that Claude gains from experience—including interactions with users and tasks it's been assigned—and that it retains between sessions, saved as context it can read later."

It also lists what it leaves out: changes to model weights, in-context learning within a single conversation, and compaction, which it describes as summaries that replace older turns so Claude can keep working.

The evidence comes from a few evaluations: Continual Learning Bench, Claude playing Pokémon Red, a corpus of internal documents, and a legal benchmark built around a merger.

The first idea in the post is that writing a note is a bet. In Anthropic's words, "Memory is, occasionally, a prediction." It goes on: "By writing down a rule, an agent predicts that the pattern it's describing will be relevant again."

On the Continual Learning Bench task, Claude answered database questions, was told the correct answer, and could write a memory before the next question. Each question started in a fresh session, with one exception: the memory directory carried over.

An older model left scattered files of untested guesses. The post says "Claude Opus 5 was the first of these models to close the loop", with entries that held a rule, how it knew the rule was true, and warnings about traps.

A rule, its evidence, and the trap it avoids is a format you can check later.

The Pokémon comparison is the clearest example in the post. Around 10,000 steps into the game, one older model had written 413 memory files across 225 folders and earned one badge. A newer model had written nine files in two folders, plus one top-level file called global.md, and earned four badges.

The difference was what each model thought was worth saving. The older model logged every battle, item, and character, and the post explains why that hurt: "Sonnet 3.7's detailed record was continuously going out of date."

The newer model saved what the game didn't show. The post puts the distinction this way: "memory files about strategy, plans, and tested rules exist only if Claude works them out, and they disappear unless Claude writes them down." Things like the player's money or map position can be read off the screen every turn, so storing them is redundant.

Claude Code's documentation draws a similar line for auto memory. It describes auto memory as the place for your preferences, corrections, and "project context Claude can't derive from the code". Facts that live in the code, the README, or the build files can be read directly when needed. A note that copies them can drift from the source.

The post's guidance on steering is short: "We've found that it helps to tell Claude what memory is for, but not how to use it."

Anthropic tested specific rules about what to write. When the rule told the models to record only failures, the stronger models lost much of the gain that memory had given them. The conclusion: "For stronger models, giving them freedom to judge salience was more effective than setting fixed rules in advance, and those rules could end up weakening performance."

Older models were different: prompting one to read its memory first and test its theories raised its score. For frontier models, Anthropic describes its default as simple guidance to create notes when a person asks or when something is clearly worth remembering.

This finding is about rules for what an agent writes into memory. It doesn't evaluate the project instructions you give Claude for coding work. If you've added a line to your CLAUDE.md telling Claude to save only certain kinds of notes, the research is a reason to test whether that line helps, not proof that it hurts in your setup.

Read this finding closely. The post states the risk directly: "Since Claude writes to memory based on what it judges to be salient in-session, a note that's wrong from the start or that drifts as the environment changes can be read, and trusted, by Claude in a later session."

In the Pokémon run, Claude noted the wrong side of a mountain for a landmark, marked the mountain as finished, and walked off a one-way ledge back onto the route it had come from, more than once.

The fix Anthropic tested was dreaming: a pass that checks notes against the original session transcripts. Claude compared the wrong note with the transcript, found the error, and rewrote the note. With the corrected note, it went back into the cave and reached the next city. The post explains why that worked: "The transcript gave Claude a ground truth to validate its memory against."

What this means for Claude Code's auto memory

Claude Code's auto memory is plain files on your machine. The documentation says you can run /memory to browse them, and "Everything is plain markdown you can read, edit, or delete."

There's one detail in the docs that connects directly to the research. Claude Code deletes old session transcripts after the cleanupPeriodDays retention period, but "excludes the memory files in the memory directory from that retention sweep." Memory files stay until you or Claude edits or deletes them.

Put those two facts next to each other. A note can outlast the session transcript it came from. If the note was wrong, the record that could show it was wrong may already be gone. Anthropic's dreaming pass relied on that record. For local auto memory, the check falls to you, against the code and the current state of the project. Our guide to why Claude Code forgets your corrections covers the opposite failure, where a correction never makes it into a note at all.

The post describes a hierarchy. Notes can be promoted to the top layer, which the agent's harness loads into context at the start of every session, so Claude doesn't need to search for them. The post then sets limits on that layer: "Injected memories use up valuable tokens, and an incorrect note can be carried into every session."

It adds that loading a note doesn't guarantee Claude acts on it, citing Claude Code's own documentation that longer instruction files reduce adherence. Its conclusion: "So the top layer of the memory hierarchy has to stay relatively small".

The post then names Claude Code's auto memory as an example of the same design. The documentation spells out the numbers: "The first 200 lines of MEMORY.md, or the first 25KB, whichever comes first, are loaded at the start of every conversation." It continues: "Content beyond that threshold is not loaded at session start."

The rest lives in topic files, which Claude reads on demand. MEMORY.md works as an index that points to them.

Claude Code also enforces the limit when Claude writes. If MEMORY.md is near a limit, Claude Code reminds Claude to shorten it. If it's over, the write still succeeds, but Claude Code returns an error telling Claude to rewrite the index, "because everything past the limit is dropped on the next load."

So the practical question for any note is where it sits. A line in the first 200 lines of MEMORY.md is there when the session starts. A line further down, or a detail in a topic file, is only there if Claude goes looking for it. Our guide to Claude Code auto memory explains where those files live and how to turn the feature off.

The same applies to instruction files you write: the documentation suggests under 200 lines per CLAUDE.md file, because "Longer files consume more context and reduce adherence." Subdirectory files have their own cutoff, covered in our guide to the subdirectory CLAUDE.md limit.

One of the later experiments is easy to miss and relevant to anyone sharing memory between agents or people. Claude built a wiki from a set of contracts. Several agents wrote to one shared table of contract terms at the same time. When Anthropic graded a brief built from that wiki, 41 of 57 graded facts had survived. The post found why: the shared table summarized terms poorly and was missing some, "because agents had overwritten one another's work."

The improved instructions gave each contract its own page, written by a single agent, "which quoted the terms word for word rather than summarizing them into a shared table." With that change, all 57 facts made it into the brief.

One writer per page avoids overwrites, and quoting the source keeps details a summary can drop.

Claude Code's documentation notes that "All worktrees and subdirectories within the same git repository share one auto memory directory." If you run parallel sessions in several worktrees of one repository, they share that directory. The memory documentation doesn't describe how simultaneous writes to the same file are handled, so it's worth checking MEMORY.md after a day of parallel work. Anthropic's Managed Agents guide takes a similar split between writers, covered in our piece on the two memory stores in Claude Managed Agents.

The post doesn't present wikis as a general answer. On questions that needed facts from several documents, Claude did better with the wiki than with search alone. On a legal task where most criteria could be met from a single document, the wiki showed no clear gain. On another task, the wiki grew larger than the documents it was built from. The post's verdict on that case: "Claude had made an extremely detailed wiki that effectively abstracted nothing." The post also lists open questions, including how to keep memory accurate when checking every note costs compute.

Saving everything, just in case. A large memory that goes stale costs time to search and can mislead.

Writing strict rules about what to save. For stronger models, Anthropic found fixed rules could weaken performance.

Trusting a note because it's in memory. A note can be wrong from the start, and Claude can read and trust it later.

Letting MEMORY.md grow. Anything past the first 200 lines or 25KB isn't loaded at session start.

Step 1: Read what auto memory saved

Run /memory, open the auto memory folder, and read MEMORY.md and the topic files. Check each entry against the code or the current state of the project, and fix or delete what's no longer true. Don't count on finding the original session, since transcripts are cleaned up on a schedule.

Step 2: Keep MEMORY.md an index under the limit

Keep one line per entry in MEMORY.md, and move detail into topic files. Put the entries Claude needs at the start of every session near the top. Remove anything that copies what Claude can read from the code.

Step 3: Give each page one writer, and quote decisions

If several sessions or teammates add to the same notes, give each subject its own page. When a fact comes from a document, a ticket, or a decision record, copy the exact wording rather than a summary.

Anthropic's post is about memory the agent writes for itself, based on what seems important in the moment. There's another kind of memory with a different property: the decisions and conventions you've confirmed yourself. You know an entry is right when you write it, and you may want it in more than one tool and on more than one machine. Claude Code's documentation says auto memory is machine-local.

MemoryLake is a memory layer for keeping those confirmed entries in one place you maintain, available to the assistants you connect, such as ChatGPT, Claude Code, and Codex.

You write the entries yourself, in your own words. Nothing is read out of, written to, or deleted from your MEMORY.md, your auto memory topic files, your CLAUDE.md files, your Claude chats, or any vendor's store. Claude Code's auto memory keeps working the way Anthropic describes it.

Step 1: Create an API key

Sign in and generate a key from the dashboard. The key belongs to your MemoryLake workspace and is separate from your Anthropic account.

Step 2: Upload your first memories

Start with the entries you checked in Step 1 above and confirmed are still true. One decision per entry, with the source quoted word for word and the date you confirmed it.

Step 3: Connect your AI & agents

Connect Claude Code and any other assistants you use. The same confirmed entries are available on each machine and in each tool.

The first difference is a shorter index. MEMORY.md can hold pointers and the few things every session needs, while confirmed decisions live where you can look them up.

The second is a clearer source of truth. When an auto memory note and a confirmed entry disagree, you know which one you wrote after checking.

The third is one writer for what matters: the decisions you've confirmed have a single author.

Save what Claude can't read elsewhere. Strategy, decisions, and tested rules belong in memory. Facts in the code don't.

Write rules with their evidence. A rule, how you know it's true, and the trap it avoids is easy to check later.

Check notes against the source. A wrong note can be trusted in a later session.

Keep the top layer small. Only the first 200 lines or 25KB of MEMORY.md load at session start.

Prefer one writer per page. Shared pages with several writers can lose facts.

Quote, don't summarize, important terms. Exact wording keeps the details intact.

Anthropic's post explains, with its own evaluations, how Claude decides what to remember. Notes are predictions. Stronger models do better when told what memory is for rather than given fixed rules. A note that's wrong from the start can be read and trusted in a later session, which is why Anthropic tested dreaming against original transcripts. And the layer that loads every session is kept small on purpose, which in Claude Code means the first 200 lines or 25KB of MEMORY.md.

For your own setup, that comes down to three habits: check what auto memory saved against the source, keep MEMORY.md a short index with the important entries at the top, and give important facts one writer and their exact wording.