Anthropic Taught Agents to 'Dream': Rethinking Long-Term Memory for AI

On November 6, 2026, Anthropic published a technical article titled The components of agent memory. It tackles a question that is becoming increasingly important in agent development: how do you give an AI agent long-term memory that is actually valuable?

When people hear “agent memory,” the first thing that comes to mind is usually saving conversation history to a database, then using embeddings and vector search to pull relevant pieces back into the context when needed.

That is the basic approach many agent memory frameworks take today.

But as agents take on more and more complex tasks, this simple mechanism starts to show its limits.

For example:

• What should an agent remember? Is every tool call and every conversation really worth keeping forever?
• If an agent once reached a wrong conclusion, will that mistake keep affecting it in the future?
• Once an agent has accumulated millions of tokens of history, how does it quickly find the knowledge that actually matters?
• If an experience seemed unimportant at first but later turns out to be critical, does the agent get a chance to recognize it again?

Anthropic argues that agent memory needs more complete lifecycle management.

To that end, they propose a layered memory architecture and introduce a fascinating mechanism: Dreaming.

Put simply, outside of task execution, the agent uses extra compute to review past experiences, correct mistakes, distill lessons, and organize scattered information into knowledge it can reuse later.

1. Why Do Agents Need to “Dream”?

The article opens with a quote from the Danish philosopher Søren Kierkegaard:

Life can only be understood backward, but it must be lived forward.

Anthropic argues that this applies to agent memory as well.

While an agent is executing a task, it can only judge what is worth remembering based on the information it has at that moment.

That judgment is not always right.

For example, a coding agent troubleshooting a database performance problem might try a dozen different approaches.

It might record the SQL that finally solved the problem, while overlooking a database compatibility issue exposed by one of the failed experiments.

Only when it runs into a similar problem later does it realize that detail was important.

Humans run into the same thing.

We experience a huge number of events every day, but only some of them become long-term memories.

Neuroscience research suggests that the brain replays some experiences during sleep and quiet rest, gradually integrating them into more stable long-term knowledge.

Anthropic wants agents to have a similar mechanism.

During normal work, an agent continuously produces session transcripts, tool call results, and important observations.

When it doesn’t need to work on a user task, a separate memory maintenance process can revisit these records.

This process is called Dreaming.

To be clear, Dreaming is not a concept Anthropic invented. Letta and UC Berkeley had already explored a similar idea called sleep-time compute.

The value of Anthropic’s article lies in placing Dreaming within a complete agent memory architecture and analyzing, through a series of experiments, how well different memory mechanisms actually work.

2. Anthropic’s Four-Layer Memory Architecture

Anthropic divides agent memory into four layers.

The four layers are:

These four layers are a logical division; they don’t require deploying four separate storage systems.

1. Transcripts: Raw Memory

Transcripts record the agent’s raw execution history, including user conversations, tool calls, and task results.

For example, a coding agent might produce a record like this:

The user asks to optimize a SQL query.

The agent queries the database execution plan.
The agent finds that some queries miss the index.
The agent tries rewriting the SQL.
The first change fails.
The second change triggers a database compatibility issue.
The third change succeeds.

These records are usually huge and unsuitable for loading into the context wholesale.

But they preserve what the agent actually went through.

That provides a basis for verifying memories later.

2. Memory Notes: Important Lessons

Memory Notes are information the agent distills from its raw experience.

For example:

Database query optimization lessons

- The current project uses a MySQL-compatible database.
- Some aggregate queries need to watch out for ONLY_FULL_GROUP_BY.
- Queries over monthly sharded tables should limit the scan range as much as possible.
- Re-verify the execution plan after modifying SQL.

Compared with raw logs, these are more concise and easier for future agents to reuse.

But there’s a key question here:

How does the agent know what’s worth saving?

Anthropic argues that saving a memory is essentially a prediction about future needs.

When an agent writes a rule into long-term memory, it is effectively predicting that some future session will need that rule again.

But the agent can’t know in advance what will happen.

That is exactly where Dreaming comes in.

3. Memory Representations: Organizing Knowledge

As Memory Notes pile up, a simple file list or vector search may no longer be enough for complex tasks.

For example, the agent might need to answer:

“Why did the project end up choosing ShardingSphere instead of manual sharding at the application layer?”

The answer may be scattered across multiple sessions covering architecture design, performance testing, technology selection, and troubleshooting.

If it retrieves only one or two memories, the agent may not be able to reconstruct the full decision process.

So Anthropic introduces knowledge representations such as a wiki.

A wiki can organize related information into interlinked pages:

Project knowledge base
├── System architecture
│   ├── Technology selection
│   └── Module dependencies
├── Database
│   ├── Sharding design
│   ├── SQL compatibility
│   └── Performance optimization
└── Incident records
    ├── Query errors
    └── Database timeouts

Wiki pages can be connected through links.

That way, when answering a complex question, the agent can follow the relationships between pieces of knowledge step by step, instead of relying entirely on vector similarity.

4. Injected Context: Automatically Injected Memory

This is the layer closest to today’s agent prompts.

For an agent that works on a Java project over the long term, we might want it to know the following at the start of every session:

# Project basics

- JDK 17
- Spring Boot 3.x
- Uses MyBatis-Plus
- Monthly table sharding
- Schema changes must consider compatibility with historical shards

# More information

- Database design: memory/database.md
- Coding conventions: memory/coding.md
- Known issues: memory/issues.md

Information like this shouldn’t require a search every time.

However, automatically injected memory has obvious problems too.

If there’s too much of it, it eats up a lot of the context window and can reduce how well the model follows important rules.

That’s why Anthropic stresses that this layer must stay lean.

The article also mentions Claude Code’s Auto Memory.

Claude Code doesn’t load every memory file into the context. It automatically reads only the first 200 lines or 25 KB of MEMORY.md, whichever limit is hit first.

The top-level file mainly serves as a knowledge index.

When specific information is actually needed, the corresponding memory file is read.

This is very similar to the Progressive Disclosure pattern common in Agent Skills.

3. Does More Memory Make an Agent Smarter?

Anthropic answers this question with a fun experiment.

They had different versions of Claude play Pokémon Red.

During the game, the agent needs to remember routes, items, characters, battle experience, and its current objective.

The researchers compared the memory of Claude Sonnet 3.7 and Claude Fable 5 after roughly 10,000 actions each.

The results:

Sonnet 3.7 saved a huge amount of detail.

Almost every battle, every item found, and every NPC encountered could end up as its own memory file.

As the game went on, many of those records went stale.

For instance, the character’s current location and money change constantly.

That information can be read directly off the game screen anyway, so storing it long-term only added maintenance overhead.

In one run, Sonnet 3.7 spent 17 consecutive steps creating 6 files and deleting 9, without taking a single action in the game.

Fable 5’s memory, by contrast, was very lean.

It mainly kept three kinds of information:

1. Its current goal and plan of action.
2. Game rules it had already verified.
3. Strategies likely to be reused in the future.

It also used a global.md file to manage core information and a memory index.

In the end, Fable 5 made far better progress in the game with far less memory than Sonnet 3.7.

This experiment reveals something important:

The effectiveness of a memory system can’t be measured simply by how much it records.

An agent should prioritize saving information that is hard to re-acquire and likely to be reused.

Real-time state that can be fetched with a tool at any moment usually doesn’t need to be stored as long-term memory over and over.

Of course, that doesn’t mean less memory is always better.

What really matters is the agent’s ability to judge the value of information.

Anthropic calls this ability salience judgment.

4. Can Agents Keep Accumulating Experience Through Memory?

Next, Anthropic used a database question-answering task from CL-Bench 1.0.

The experiment asks Claude to answer a series of questions using a database.

After each answer, the system tells it the correct answer.

The agent can then update its memory files based on that feedback.

Notably, every question starts a fresh session.

The only thing carried over between sessions is the persistent memory directory.

So this experiment directly shows whether cross-session memory actually improves performance.

Some of the results:

These scores are average rewards on a specific database task and do not represent the models’ general capability.

As you can see, persistent memory brings clear gains for the stronger models.

But different models also use memory differently.

Older models, after getting an answer wrong, tended to record only unverified guesses.

More capable models began to form a complete experiential learning loop:

Answer the question
    ↓
Check the result
    ↓
Analyze why it was wrong
    ↓
Propose and test hypotheses
    ↓
Distill reliable rules
    ↓
Update long-term memory
    ↓
Reuse in future sessions

For example, Opus 5’s memory typically included:

• What a rule is.
• Why the rule can be trusted.
• Answers that have already been verified.
• Traps discovered in the past and things to watch out for.

This effectively lets the agent accumulate verified experience task after task.

However, Anthropic also found a counterintuitive phenomenon.

For stronger models, over-constraining memory behavior can actually hurt results.

The researchers tried telling the agent to “record only failures.”

As a result, the performance gain Opus 5 and Opus 4.7 got from memory dropped significantly.

A rule like that can cause the agent to ignore other valuable information.

For stronger models, Anthropic prefers to tell the model what memory is for and let it decide for itself what to save.

But this also depends on the model’s capability.

For example, explicitly telling Sonnet 4.6 to “read memory before answering and verify earlier hypotheses” raised its score from 0.364 to 0.641.

So an agent memory strategy can’t be designed in isolation from the underlying model’s capability.

5. Dreaming: Letting Agents Actively Correct Wrong Memories

At this point, the agent can already improve through past experience.

But there’s still a thorny problem.

What if the agent saves a wrong memory?

A wrong memory is more dangerous than a missing one.

The agent may read it again and again in future tasks and treat it as a verified fact.

Anthropic illustrated this with another Pokémon Red experiment.

In the game, Claude needs to get through Mt. Moon to reach the next city.

But it recorded the PokéCenter’s location wrong, noting a building on the west side of the cave entrance as being on the east side.

This seemingly small mistake had serious consequences.

Claude believed it had already made it through the cave.

It then kept acting on that wrong memory, repeatedly heading in the wrong direction and even ending up back on earlier routes several times.

In the end, it never reached the target city.

The researchers then enabled Dreaming.

Dreaming re-read the raw session logs and compared the history against the current Memory Notes.

After checking, Claude discovered that its earlier record of the PokéCenter’s location was wrong.

So it corrected the corresponding memory file.

The next time the agent read that memory, it could correctly figure out where it was.

In the experiment:

• The agent with no memory failed to reach the target city.
• The agent with the uncorrected memory also failed to reach it.
• The agent whose memory was corrected by Dreaming reached it at cumulative action 1,935.

This experiment shows the real value of Dreaming.

It lets the agent re-examine its own conclusions outside of the task.

And there’s a design choice here worth noting:

Dreaming uses the raw Transcripts as the factual basis for verifying memory.

This means raw logs, although huge, remain very important.

If a Memory Note is in dispute, the system can trace it back through its provenance to the original conversation or tool call record.

Of course, raw logs aren’t always correct either. They may contain a user’s mistaken statements or anomalous tool results.

So a real system also needs to distinguish raw observations, external evidence, inferred conclusions, and verified facts.

6. Why Did Anthropic Also Introduce a Wiki?

Memory Notes solve the problem of saving important information.

Dreaming keeps that information accurate.

But as memory keeps growing, another problem appears:

How does an agent find a complete answer among a large number of independent memories?

Traditional approaches usually rely on keyword search or vector retrieval.

But when a question requires combining multiple historical events, multiple documents, and complex knowledge relationships, search alone may miss important information.

So Anthropic tried having Dreaming build a wiki.

A wiki organizes knowledge into interlinked pages.

For example:

# Database sharding design

## Current approach
Monthly table sharding.

## Background
See: [Database performance issues](./performance.md)

## Technology selection
See: [ShardingSphere evaluation](./shardingsphere.md)

## Known compatibility issues
See: [SQL compatibility issues](./sql-issues.md)

This way, the agent can explore related knowledge step by step from a single entry point.

To test how well this works, Anthropic used internal documents from Stainless, a software company it acquired.

The corpus was roughly:

• 350,000 files.
• 420 million tokens.
• 25 evaluation questions.

They built and maintained the wiki over 128 sequential sessions.

The results:

As the wiki matured, the wiki-plus-search score rose from 54% early on to 61%.

Combining the wiki with search also saved about 20,000 tokens per question on average.

This result is really interesting.

On its own, the wiki actually performed worse than search.

But combined, the two improved performance further.

That’s because the wiki provides structure across pieces of knowledge, while search fills in raw material the wiki doesn’t cover.

Anthropic also tested with legal documents related to a corporate merger.

When questions required combining multiple documents, the wiki-based approach scored 87%, versus 73% for search alone.

But not every task needs a wiki.

If the answer is concentrated in a single document, searching directly is often enough.

Anthropic even ran into cases where the wiki was larger than the source documents.

The source documents were only 115 KB, but the generated wiki reached 203 KB, about 1.77 times the original material.

At that point, the wiki has lost its value as an abstraction of the information.

So a wiki needs to be built and maintained according to the nature of the task.

7. Dreaming Manages Memory and Can Also Optimize How It’s Organized

The article also describes an experiment that’s easy to overlook.

In a task involving merger and acquisition contracts, Anthropic had multiple agents build a wiki in parallel.

Initially, several agents were editing the same summary file of contract terms at the same time.

This caused concurrent-write problems.

Content one agent had just saved could be overwritten by another.

In the end, the wiki retained only 41 of 57 key facts.

The researchers then had Claude analyze why it failed and try to improve how the wiki was built.

The improved approach:

Each contract is handled by one agent, which produces its own wiki page.

Key contract terms are kept in their original wording, avoiding information loss from over-summarization.

After the adjustment, all 57 key facts were retained.

This shows that, beyond correcting specific memories, Dreaming can also help improve the strategy for organizing memory.

This experiment is especially worth noting for systems where multiple agents process knowledge in parallel.

Because a Memory Service is ultimately still a storage system with concurrent read/write requirements.

Without proper isolation and conflict control, the LLM’s reasoning ability alone can’t guarantee data consistency.

8. How Should Dreaming Be Implemented in an Agent System?

Most of the content so far comes from Anthropic’s experiments.

Next, let’s discuss how we could borrow this architecture if we were building our own agent platform.

I lean toward decoupling the Agent Runtime from the Memory Service.

This breaks down into three core components.

1. Memory Reader: Reading Memory

The Memory Reader loads the appropriate historical information for the current task.

It should support several modes:

Automatic injection

Load a small amount of high-priority memory when the agent starts.

For example, the current project, development conventions, and constraints the user has explicitly asked to follow.

Semantic retrieval

When the agent encounters a problem related to past tasks, find relevant content through keyword or vector search.

Knowledge navigation

For tasks that require complex reasoning, explore related information step by step through the wiki and knowledge index.

Avoid loading all Memory Notes into the prompt at once.

2. Memory Writer: Writing Memory

The Memory Writer saves important information to long-term storage.

But I don’t recommend saving only the text content.

For example, you could use a data structure like this:

{
  "id": "mem_001",
  "type": "verified_rule",
  "content": "月度分表查询需要限制扫描范围",
  "scope": {
    "tenantId": "tenant_001",
    "projectId": "report-engine"
  },
  "confidence": 0.95,
  "source": {
    "sessionId": "session_123",
    "eventIds": ["event_12", "event_15"]
  },
  "verifiedAt": "2026-11-08T10:00:00Z",
  "status": "active"
}

(The content field reads: “Queries over monthly sharded tables should limit the scan range.”)

The most important fields here are:

• type: distinguishes facts, lessons, rules, preferences, and so on.
• scope: defines where the memory applies.
• confidence: how trustworthy the memory currently is.
• source: records where the memory originally came from.
• verifiedAt: when it was last verified.
• status: controls whether the memory is still valid.

Confidence can be determined jointly by model assessment and external verification; a fact shouldn’t be considered correct just because the model scored it highly.

For multi-tenant agent platforms, you also need to isolate memory across tenants, users, projects, and other dimensions.

3. Dreaming Worker: Maintaining Memory

This is the part of the architecture most worth studying.

The Dreaming Worker can run as an independent job, or perform maintenance by calling the LLM through the existing Agent Runtime.

I think it should support at least the following kinds of tasks.

Deduplication

When multiple sessions have saved similar lessons, merge them to reduce redundancy.

Fact verification

Read the original sources of Memory Notes and re-confirm key facts.

Expiry cleanup

Identify configuration, historical state, or temporary information that is no longer valid.

Lesson distillation

Summarize reusable rules from multiple similar tasks.

Knowledge organization

Organize scattered Memory Notes into a wiki and maintain links between pages.

Promotion and demotion

Frequently used, important memories can be promoted into the automatically injected context.

Information that hasn’t been used for a long time or is no longer important can stay in lower storage layers and be retrieved on demand.

That said, Dreaming doesn’t have to run continuously.

Based on the open questions the article raises, we could consider these triggers:

• The current session ends.
• The agent completes an important task.
• Two memories are found to conflict.
• A memory is accessed frequently.
• A category of knowledge changes significantly.
• The system enters idle time.

For systems with large memory stores, incremental processing can avoid rescanning the entire history every time.

9. How Does Agent Memory Relate to RAG and Skills?

By now, you might be wondering:

If agent memory includes search, wikis, and context injection, does it overlap with existing RAG and Skills?

I think they can be understood as capabilities at different levels.

RAG Solves Knowledge Retrieval

RAG’s core capability is letting the model fetch external knowledge when answering a question.

It focuses more on:

“Which sources does the current question need information from?”

Of course, RAG can also incorporate reranking, knowledge graphs, and sophisticated retrieval strategies.

But by itself, it doesn’t define a mechanism for continuously maintaining an agent’s historical experience.

Memory Solves Experience Accumulation

Memory focuses more on:

“What has the agent learned from past experience, and how can that experience help with future tasks?”

It may store user preferences, verified rules, past decisions, lessons from failures, and so on.

Memory can use RAG techniques for retrieval, but it also has to manage how that information is created, updated, and retired.

Skills Solve Capability Reuse

Skills typically encapsulate how to perform a specific task.

For example:

• How to generate a database migration script.
• How to perform a code review.
• How to generate marketing copy that complies with company guidelines.

Skills are closer to reusable workflows and capability descriptions.

Memory can record lessons learned while executing those Skills.

For example, after calling a database migration Skill many times, the agent may discover a compatibility issue with a particular database version.

That lesson can go into Memory.

Once verified, the system can also consider folding it into the Skill’s execution guidelines.

So the three can absolutely work together.

However, whether to automatically write lessons from Memory back into Skills needs careful design.

For production systems, I’d rather have the agent propose changes first, then put them through automated tests or human review, so wrong lessons don’t contaminate the official execution flow.

10. My Thoughts on the Article

Anthropic’s article made me rethink where agent memory fits.

In the past, discussions of agent memory often focused on storage and retrieval.

For example:

• Redis, PostgreSQL, or a vector database?
• How to design embeddings?
• How to reduce vector search latency?
• How to handle long contexts?

These questions certainly matter.

But Anthropic’s experiments suggest that what determines the value of long-term memory may first and foremost be the agent’s ability to judge and maintain what it remembers.

1. Long-Term Memory Needs to Be Correctable

Traditional memory extraction pipelines often save LLM-generated summaries directly.

But the summaries themselves may contain errors.

Without a verification mechanism, those errors keep accumulating over time.

So I think mature agent memory systems should keep provenance for important memories and support re-verification.

That is also the most direct engineering value of Dreaming.

2. Memory Should Be a Dynamic Knowledge System

User preferences change, and a project’s technical architecture can evolve.

Memories that were correct in the past may not apply in the future.

So Memory can’t just support appending data.

It should also support updating, merging, deprecating, re-verifying, and reorganizing knowledge relationships.

Of course, these maintenance operations also consume model compute.

How to control the cost of Dreaming remains an open research question.

3. Model Capability May Change How Memory Frameworks Are Designed

Anthropic found in its experiments that stronger models can often decide for themselves what’s worth remembering.

Overly detailed memory rules can sometimes limit model performance.

This points to another trend in agent frameworks.

As models get more capable, frameworks may gradually reduce hard-coded control over model behavior.

Frameworks still need to provide clear permissions, boundaries, and storage interfaces, but the actual information distillation, knowledge linking, and memory maintenance can increasingly be left to the model.

Of course, whether this approach works still needs to be evaluated against specific models and business scenarios.

4. Dreaming’s Complexity Needs to Match Its Actual Benefit

Although the article shows many advantages of Dreaming, its cost can’t be ignored.

For example, in the wiki experiment Anthropic used a lot of extra compute, running 128 sequential memory-building sessions.

For ordinary agent applications, maintenance at that scale may not be worth it.

For a simple personal assistant, a small amount of structured memory plus semantic search may be enough.

Dreaming and wikis are more likely to deliver real value for agents that run long-term, repeatedly handle similar tasks, and accumulate large amounts of business knowledge.

So I think real-world adoption should start with simple Memory Notes and gradually introduce verification, consolidation, and knowledge organization.

Final Thoughts

Anthropic closes the article with an interesting point.

An agent can never accurately predict what will happen in the future, so it can never perfectly judge, during each task, which experiences are worth saving.

But it can look back on its experiences afterward.

Through Dreaming, an agent can re-understand what happened, correct mistakes, and organize scattered information into more valuable knowledge.

This may be an important direction for long-running agents.

An agent’s memory shouldn’t ultimately be measured only by how much history it can store, but also by how much reusable, verifiable experience it can distill from that history.

For agent developers, the thing really worth focusing on may no longer be just adding a Memory Tool to a model.

What matters more is building a memory system that can keep evolving.

References

1. Anthropic: The components of agent memory, November 6, 2026.
2. Anthropic: Agent Memory Cookbook
3. Continual Learning Bench (CL-Bench)