If you’ve used an AI coding agent for more than a day, you’ve hit the same wall I have: every new session starts from scratch. It doesn’t remember your preferences, that the staging database is flaky, or that last week’s clever workaround was actually a bug.

Anthropic published a research post on Friday, November 6 — “The components of agent memory” — that explains how it’s attacking exactly this problem with Claude. The core idea is borrowed from neuroscience: memory isn’t one thing, and the interesting work happens offline.

Notes, not brain surgery

When Anthropic says “agent memory,” it means knowledge Claude gains from experience — conversations, tasks, mistakes — that it saves as context it can read in a later session, usually a folder of memory notes. It is not retraining the model, and it’s not the summary a long conversation gets compacted into. It’s closer to a notebook.

That raises the hard question: how does Claude know what’s worth writing down, before it knows what the future will need? Anthropic’s answer is that memory is a prediction — writing down a verified fact is a bet that a future session will want to trust it without re-checking. On CL-Bench 1.0, where Claude answers database questions and can write a memory after each one, Opus 5 was the first model to fully close the loop: its entries included the rule, how it knew the rule was true, and warnings about traps it had found.

The Pokémon test: less is more

The most entertaining evaluation is also the most revealing. Anthropic had Claude play Pokémon Red — a game that punishes you for forgetting where you are and what you were doing — with a folder of memory files it could read and write as it played.

Claude Sonnet 3.7 assumed everything might matter. Ten thousand steps in, it had written 413 memory files across 225 folders — a separate file for nearly every battle, item, and character it met — and earned one badge. Its detailed record kept going stale as the game state changed, so it spent more and more time rummaging through its own notes instead of playing.

Claude Fable 5 wrote nine files in two folders, plus one top-level global.md acting as a dashboard: current goal, a plan for tackling gyms, and its own rules for using memory. It earned four badges. The difference was judgment about what to save: map position and money can be read off the screen every turn; strategy and tested rules exist only if Claude writes them down. Opus 5.5 took the same spare approach and beat the game outright. The instinct is to log everything; the evidence says a small, curated memory beats a comprehensive one.

Dreaming: the overnight shift

The second half of the post is about what happens between sessions. Researchers at Letta and UC Berkeley proposed “sleep-time compute” — using idle time to reorganize what a model already knows — and Anthropic calls the same idea dreaming: Claude re-reads its session logs offline, fixes mistakes, merges duplicates, and builds new structures like wikis.

Dreaming matters because memory notes go stale and go wrong. In one Pokémon run, Claude wrote down (incorrectly) that the PokéCenter was on the east side of Mt. Moon. It then walked off a one-way ledge and looped the same mistake three times before giving up and trudging back to Pewter City, never reaching Cerulean City. When Anthropic ran dreaming on that same memory folder, Claude checked the note against the session transcript, caught its own error, and rewrote it — and with the corrected note, it walked straight through to Cerulean City. The transcript is the ground truth; dreaming is the fact-check.

Dreaming also builds things a single session can’t. Anthropic fed Claude about 350,000 internal documents from Stainless (a company it acquired in May) and had it build a wiki over 128 dreaming sessions. Performance on a 25-question test climbed from 13% to 48% of graded criteria as the wiki grew, and using the wiki plus a search tool beat search alone.

The caveats are the interesting part

None of this is free, and Anthropic is honest about the trade-offs. Dreaming costs compute, and checking all memories continuously isn’t practical. Wikis can also grow past the point of usefulness: on one task, Claude’s wiki ended up larger than the documents it summarized — a Borges map of the territory. And the top layer of the memory hierarchy — the notes injected into every session — has to stay small, because a wrong note gets carried everywhere. Claude Code handles this by loading only the first 200 lines (or 25 KB) of its MEMORY.md as an index.

There’s also a counterintuitive finding about steering. Telling Claude what memory is for helps, but telling it exactly how to use it can backfire: a rule to “record only failures” cost Opus 5 and Opus 4.7 much of the performance boost memory gave them. Explicit prompting helped older models most — telling Sonnet 4.6 to read its memory nearly doubled its score — while Sonnet 5 already reads its memory unprompted nine times out of ten.

Why this matters beyond Claude

This is a research post about one company’s agent, but the pattern is general — and if you run Claude Code, you can see the shape of it in your own MEMORY.md today: a file that grows session by session, where the difference between useful and junk drawer is exactly the judgment this post is about.

We’ve spent two years making models smarter inside a conversation. The next two will be about making them smarter between conversations — and it turns out the way forward looks a lot like sleep.