Anthropic's Agent Memory Research: What Memory From Sessions Can't See

Agent memory built from an agent's own sessions can only hold what that agent saw, and Anthropic's new research shows both how well that works and where it stops. On November 6, 2026, Anthropic published The components of agent memory, written by Lance Martin. It lays out four layers of memory, an offline process it calls dreaming, and a set of experiments in which memory lifted Claude's scores by wide margins. The part it leaves alone on purpose is the knowledge that never passed through the agent's sessions: why a service is built the way it is, what was decided in a Slack thread, which incident changed a default. That has to come from somewhere else.

What did Anthropic's "components of agent memory" post find?#

Anthropic defines agent memory narrowly. In the post, it means "knowledge that Claude gains from experience," kept between sessions and saved as context Claude can read later. Weight changes, in-context learning and compaction are out of scope. The post describes four layers, from bottom to top:

1. Transcripts: the searchable log of what happened in a session.
2. Memory notes: short lessons and rules Claude writes, either tagged in the log or saved to a memory folder.
3. Memory representations: structures such as a wiki, which Anthropic describes as "a collection of pages written and maintained by Claude that gathers what Claude knows about one subject."
4. Injected context: the small slice loaded into every new session.

An offline pass called dreaming moves information between those layers.

The bottom line:

• Anthropic's post treats agent memory as knowledge Claude gains from its own experience, stored in four layers: transcripts, notes, representations and injected context.
• Memory helped a lot in its tests. Opus 5.5 rose from 0.655 to 0.838 on a CL-Bench database task, and a dreaming-built wiki plus search beat search alone.
• By definition, that memory holds only what the agent experienced. Team decisions in Slack, tickets, pull requests and incident reviews never enter it unless something else brings them in.
• Anthropic's wiki tests had Claude read collections of documents, such as one software company's internal files. That points toward a shared context layer every agent can query.

How much did agent memory help in Anthropic's tests?#

Memory helped every model Anthropic tested on its database task, though the size of the gain tracked how well each model used it. The test setup compared each model's mean reward on the same task with and without memory. On CL-Bench 1.0, run on Claude Managed Agents, Opus 5.5 went from a mean reward of 0.655 without memory to 0.838 with it. Opus 5 went from 0.564 to 0.828. Sonnet 4.6 barely moved, from 0.330 to 0.364. Its notes were lists of untested guesses, and it often skipped reading them. When Anthropic prompted Sonnet 4.6 to read its memory and test those theories, it reached 0.641.

The post also tested rules about what to save. Telling stronger models to record only failures cut their gain, by 0.234 for Opus 5. Anthropic's conclusion is that for capable models, "giving them freedom to judge salience was more effective than setting fixed rules in advance."

The Pokémon Red runs make the same point. Sonnet 3.7 wrote 413 memory files across 225 folders and earned one badge. Fable 5 wrote 10 files of strategy and tested rules and earned four. Opus 5.5 kept a small goal-tracking folder and beat the game.

What is dreaming, and what did the wiki experiments show?#

Dreaming is Anthropic's name for an offline pass in which Claude reviews past transcripts and its current memory, then fixes mistakes and writes new notes or representations. In one Pokémon run, a wrong note put a PokéCenter on the far side of Mt. Moon. With the wrong note left in place, Claude dropped off the same ledge three times and never reached the next city. With dreaming, it fixed the note against the transcript and reached Cerulean City.

The wiki tests are the most useful part for engineering teams. Anthropic gave Claude a corpus of internal documents from Stainless, about 350,000 files and roughly 420 million tokens, plus 25 questions. As dreaming scaled from two sessions to 128, the wiki on its own went from meeting 13% of graded criteria to 48% (Anthropic, 2026). Wiki plus search reached 61%, against 53% for search alone (same post, 2026), and saved about 20,000 tokens per question. In a second test, built on Harvey's LAB benchmark and a set of merger documents, Claude answered 24 questions about the merger. On the items that needed several documents, it scored 87% with the wiki and 73% with search alone.

Anthropic's Managed Agents announcement from May 2026 offers dreaming as a research-preview feature that reviews sessions and memory stores, then curates memories.

What can memory from sessions see, and what can't it?#

Session memory is what an agent keeps from its own past runs: transcripts, the notes it chose to write, and anything built from those. It covers what happened while the agent was working, and nothing else.

Anthropic is direct about one limit. Writing a note "is, occasionally, a prediction," the post says, and "no model can really know what will happen in future turns." That is a salience problem inside the agent's own experience.

A team has a second problem, which is everything outside that experience. Take a mobile API endpoint that the code marks as deprecated but nobody deletes. The reason sits in a Jira ticket and a Slack thread from last spring: one large customer pins an old app version, and support agreed to keep the endpoint until their contract renews. An agent asked to "clean up deprecated endpoints" has never been in that thread. Its notes are accurate about every session it ran, and the endpoint still gets deleted.

Stack Overflow's 2026 results point the same way. Project goals and requirements topped the list of trusted context sources at 85%, and coworkers were the first place developers go for specific answers, at 72% (Stack Overflow, 2026). A transcript holds neither unless someone pastes it in.

Where does Anthropic's research point beyond the single agent?#

Three details in the post point past one agent's sessions.

First, the wiki experiments started from bodies of documents, such as the Stainless corpus, and not from Claude's own chat history. Over 128 sessions, Opus 5 agents explored those files, wrote and corrected linked wiki pages, and checked claims against the sources. The raw material was organizational knowledge that existed before any agent session began.

Second, shared writing was hard. When several agents wrote to one shared table of contract terms at the same time, they overwrote one another and only 41 of 57 facts survived. When each contract got its own page, written by a single agent that quoted the terms word for word, every criterion could be met, up from 72%.

Third, Anthropic says plainly that "memory can also drift and become irrelevant as the environment changes." Code, teams and decisions change faster than any one agent's sessions sample them.

Academic work on shared memory reaches a similar view. Researchers writing on memory for multi-agent systems in March 2026 call consistency across agents "the most pressing open challenge" for shared memory. A June 2026 paper on fleet memory for LLM agents names four ways shared knowledge fails, two of which are stale facts spreading and contradictions that never get resolved.

How does Anthropic's agent memory work in Claude Code and the API today?#

Anthropic ships memory in several products, each with its own owner and scope. This table uses Anthropic's documentation for each row.

Claude Code loads only the first 200 lines or 25KB of MEMORY.md into each session, so injected context stays small by design. The Managed Agents docs also suggest one read-only store shared across sessions for "standards, conventions, domain knowledge." So Anthropic expects shared reference material, and leaves open who writes it and how it stays current. Other vendors made similar choices: GitHub Copilot memory shares repository facts with collaborators and expires them after 90 days by default, as we covered in GitHub Copilot memory only knows GitHub.

Frequently asked questions#

Persistent memory for coding agents across sessions and repos, what do teams use?#

A common setup combines each agent's own memory for one developer's lessons, checked-in files like CLAUDE.md and AGENTS.md for agreed rules, and a shared context service over MCP for knowledge that spans repos. Our comparison of memory MCP servers covers the tools.

Memory MCP server for a whole team, not one developer's machine?#

A team needs a server that reads the systems where decisions are recorded. The Model Context Protocol is an open standard that Claude, ChatGPT, VS Code and Cursor all support, so one endpoint can serve every developer and agent. Check whether answers follow the permissions in each source.

Memory layer for Claude Code and Cursor that is shared across an engineering team?#

Neither tool can host it, because Claude Code and Cursor each store memory in their own format and location. Our answer on memory layer vs context layer explains the split, and agent memory vs context covers the short version.

Does dreaming fix stale memory?#

It fixes notes that are wrong against the agent's own transcripts. Anthropic lists open problems too: dreaming costs compute, a wrong injected note can spread to every session, and wikis can outgrow their sources.

Is Anthropic saying session memory is enough?#

No. The post scopes itself to memory from experience and says "we still have a lot to learn about designing Claude's memory systems." It does not claim to cover team knowledge.

What does a shared context layer add to agent memory?#

A context layer is a service the whole team shares. It reads the code, tickets, threads and docs where decisions were recorded, settles conflicts between them, and gives every person and agent the same answer with sources attached. Session memory keeps what one agent learned on the job; the context layer supplies what the team knew before the job started.

Unblocked is a context engine built for that role. It reasons across code, pull requests, issues, docs, Slack or Teams threads and incidents. Agents reach it through one MCP server in Claude Code, Cursor, Codex, Windsurf, VS Code and JetBrains (GitHub Copilot agent mode included), and people use it in Slack and on the web. Its context_research tool returns a synthesized answer with citations. With Data Shield, answers follow the permissions set in each source system; it is always on for Slack, and admins turn it on for other sources.

In the deprecated-endpoint case, the agent asks first and gets back the ticket, the thread and the customer constraint. Teams make this a standing first step, for example a CLAUDE.md line telling the agent to gather context before changing code.

For more on why the repo alone falls short, see why Claude Code keeps reinventing rejected approaches and what is a context engine.

My setup tells the agent: before you implement anything, go check Unblocked. It has everything — our repos, Notion, Slack, coding standards — and it surfaces things I wouldn't have thought to look for. GitHub Copilot doesn't have any of that organizational context. I'd rate the impact an eight or nine out of ten, and it's only gotten better.

Justin McCraw — Software Engineer, The Information

Before you rely on session memory for team knowledge#

Anthropic's results argue for turning memory on. Let agents keep notes, try dreaming where you can, and keep injected context short.

Then sort what your agents need into two piles. One pile is what an agent can learn by doing the work: test commands, build quirks, which approaches failed in its own runs. Session memory handles that well. The other pile is what the team decided elsewhere: why a default is set, which customer depends on an old path, what an incident review changed. To test the split, take the last agent change a reviewer pushed back on and ask where the missing reason was written down. If the answer is a Slack thread, a Jira ticket or a postmortem, no amount of session memory would have caught it. Give agents a shared way to ask, set up once for every tool, as in one MCP for Claude Code, Codex and Devin, and let each agent's memory do the job Anthropic designed it for.