If you use AI coding agents, you may have given one somewhere to keep notes between sessions. On 6 November 2026 Anthropic published an engineering write-up, "The components of agent memory", on what happens when an agent decides for itself what to write down. Its most useful finding runs against instinct: more notes didn't help, and strict rules about what to note made things worse.
One thing to keep in mind throughout: these are Anthropic's own experiments on its own Claude models, in its own setups. They're informative, but they aren't independent benchmarks, and the numbers belong to those specific tests.
What "memory" means here
"Memory" gets used for several different things, so the definition is worth having exactly:
"By "agent memory," we mean 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."
Just as useful is what it leaves out: "It excludes other ways models can learn or manage context, such as changes to their weights (the internal parameters set during training), in-context learning (knowledge gained within a single conversation), and compaction (summaries written by Claude that replace its older turns so it can continue working in a new context window)."
So this is about notes an agent saves and reads back later. It isn't about the model itself learning or being retrained.
413 files and one badge, or nine files and four
The clearest example comes from having Claude play Pokémon with a folder of memory files. Anthropic compared "one run each of Claude Sonnet 3.7 and Claude Fable 5, when each was about 10,000 steps into the game." The difference was stark:
- "Ultimately, Sonnet 3.7 wrote 413 memory files across 225 folders and earned one badge (badges mark a player's progress through the game)."
- "Fable 5, by comparison, wrote nine files in two folders, plus a single top-level file called global.md, and earned four badges."
That's one run each, not an average, so read it as an illustration rather than a measurement. But the explanation is the useful part. Some of what the older model saved, like the player's money or position on the map, "can be read off the screen every turn, so storing it is redundant. By contrast, memory files about strategy, plans, and tested rules exist only if Claude works them out, and they disappear unless Claude writes them down."
Recording everything also had a direct cost. "Around step 10,000, for example, Sonnet 3.7 started its fourth folder of "master" memory files. Over the next 17 steps, it created six files, deleted nine others, and took no actions in the game itself." And the notes didn't stay accurate: "Sonnet 3.7's detailed record was continuously going out of date."
Fixed rules backfired, for the stronger models
The obvious fix would be to tell the agent exactly what to record. Anthropic tested that on a benchmark called CL-Bench, giving the models specific rules about what to write to memory. With a rule to "record only failures", both Opus 5 and Opus 4.7, in the article's words, "lost much of the performance boost that memory gave them." Its 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."
Guidance did help an older model. For Sonnet 4.6, prompting it to read its memory files before answering, and then to test its theories, "nearly doubled its benchmark score". Sonnet 5 did that unprompted: "Without being prompted to, it read its memory before answering 9 out of 10 times."
Anthropic's own practice with its current models: "we typically give simple guidance to create memory notes when a person asks them to or when something is clearly worth remembering, and we leave that judgment up to Claude."
Checking notes against what actually happened
Notes can be wrong, and a wrong note can do damage in later sessions. The article describes a step it calls dreaming: going back over saved transcripts, outside a session, to check and reorganise the notes. It credits the idea's roots: "Researchers at Letta and UC Berkeley proposed sleep-time compute as a way for models to use idle time between interactions to reorganize their existing context." (The name and the comparison to how sleep consolidates human memory are the authors' analogy, not a claim about how the software works.)
The example is concrete. In one run, Claude wrote down the wrong side of a mountain for a landmark, walked off a one-way ledge, and kept the wrong note. With dreaming, it checked the note against the session transcript, caught the error and rewrote it. "The transcript gave Claude a ground truth to validate its memory against." With the corrected note it went on to the next city. In the run with the uncorrected note, it "dropped back onto that earlier route three times", and that run never reached the next city.
What to take from it if you use coding agents
- Don't save what the agent can see anyway. Anything it can read from the code, the repository or the environment each time is redundant in memory, and it goes stale.
- Do save what only exists if it's written down. Decisions, the reasons behind them, rules you've tested, and plans.
- Be careful with rigid rules about what to record. In these tests, a fixed rule hurt the stronger models. Simple guidance and the agent's own judgement did better.
- Keep the record of what actually happened. A transcript or log gives you, or the agent, something to check notes against when they might be wrong.
- Review the notes now and then. A wrong note gets trusted and acted on, as the example above shows.
Source: Anthropic, "The components of agent memory" (published 6 November 2026; read 8 November 2026). All results are from Anthropic's own tests of its own models.