cd /news/ai-agents/agent-memory-is-not-a-junk-drawer-wh… · home › topics › ai-agents › article
[ARTICLE · art-166835] src=dev.to ↗ pub= topic=ai-agents verified=true sentiment=↑ positive

Agent Memory Is Not a Junk Drawer: What Anthropic's Dreaming Experiments Teach About Building It

Anthropic published a research post on agent memory arguing that agents should store what they learn from experience rather than everything the environment already reveals, and describing an offline "dreaming" process that audits and rewrites memory notes between sessions. In experiments, a dreaming pass caught an incorrect note that had trapped Claude in a loop during a Pokémon Red run and corrected it, while wiki-style linked memory built over roughly 350,000 files scored 87% versus 73% for search alone on multi-document merger questions but showed no clear gain on single-document tasks. A concurrent-write failure that captured only 41 of 57 graded facts was fixed to 57 of 57 by giving each contract its own page and a single writer.

by read3 min views4 publishedNov 10, 2026

Most agent memory I see in production is a junk drawer: every tool result, every user message, every "fact" the agent thought was interesting, appended to a vector store and retrieved by cosine similarity forever.

Anthropic just published a research post, The components of agent memory (Nov 6, 2026, by Lance Martin), that argues for something more deliberate. Here is what they tested, what the numbers say, and how I'd apply it to an agent you're building today.

Anthropic's definition is narrow on purpose: knowledge an agent gains from experience (users, tasks) and keeps between sessions, saved as context it can read later. It is not weight updates, not in-context learning inside one chat, and not compaction (summaries that replace older turns).

They describe memory as layers:

And a process beside them called dreaming: offline passes (building on the sleep-time compute idea from Letta and UC Berkeley) where the agent rereads transcripts to correct notes, build wikis, fill gaps and decide what gets promoted to the top layer.

The clearest example is Claude playing Pokémon Red, compared about 10,000 steps into the game:

global.md The difference is what each model considered worth remembering. Money and map position can be read off the screen every turn, so storing them is redundant and goes stale. Strategies, plans and tested rules exist only if the agent works them out and writes them down.

Lesson: don't store what the environment already tells you. Store what the agent learned.

On Continual Learning Bench (CL-Bench) 1.0, a database question task where the agent gets the correct answer after each attempt and can write memory for later sessions:

Lesson: with a strong model, a short "here is a memory folder, here is what it's for" beats a rulebook. With a weaker model, add explicit "read memory first, test your theory" steps.

In the Pokémon run, Claude wrote down (wrongly) that the PokéCenter was on the east side of Mt. Moon, declared "Mt Moon DONE", walked off a one-way ledge and kept looping back to the previous route. Without a fix, it never reached Cerulean City.

A dreaming pass checked that note against the session transcript, caught the error and rewrote it. With the corrected note, Claude went back into the cave and reached Cerulean City.

Lesson: a memory note is a claim. Keep the raw transcript so something can audit the claim later.

Anthropic built wikis with dreaming over a corpus of about 350,000 files (~420M tokens) from Stainless, with 25 evaluation questions:

On 24 merger questions where more than half needed info from several documents, the wiki-based answers scored 87% vs 73% for search alone on those multi-document items. But on a Harvey LAB legal brief task where most criteria came from a single document, the wiki showed no clear gain. On another task, the wiki grew larger than the source documents: a map as big as the territory.

Lesson: build linked representations when answers need joining facts across sources. If one text search finds the answer, a wiki is just maintenance cost.

On one LAB acquisition task, several agents wrote contract terms into one shared table at the same time and overwrote each other. The brief built from that wiki included only 41 of 57 graded facts (72%).

After a reflect-and-rewrite loop on the instructions, each contract got its own page, written by one agent, quoting terms word for word. Result: 57 of 57 facts (100%).

Lesson: tell the memory builder what actually matters for the downstream task, and avoid many writers on one shared page.

Promoted notes are loaded into every session, which costs tokens and carries any wrong note everywhere. Claude Code's auto memory loads only the first 200 lines or 25 KB of MEMORY.md, used as an index of what it knows and where to find it. Anthropic's docs also warn that longer instruction files reduce adherence.

Lesson: the always-loaded layer is an index, not an encyclopedia. Push detail down and leave a link.

Here's how I'd translate this into an agent you can ship (my synthesis, not Anthropic's code):

How does your agent decide what to remember, and does anything ever check those memories against what really happened?

── more in #ai-agents 4 stories · sorted by recency
── more on @anthropic 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/agent-memory-is-not-…] indexed:0 read:3min 2026-11-10 · —