Memory and dreaming for self-learning agents
Video by Claude on YouTube · 24 min · uploaded May 2026
Notes and analysis by BrainTube, written from the video. Not affiliated with Claude. Watch on YouTube
In short
An Anthropic product manager explains memory in Claude Managed Agents, which stores agent memory as files the model edits with bash and grep, and launches dreaming, a batch job that reviews recent session transcripts and proposes a cleaned-up memory diff. The design choices are sound, especially read-only versus read-write stores, optimistic concurrency and version history. The talk is a launch, though, so the results are customer-reported and the hard problem, bad learnings spreading through shared memory, gets little attention.
The argument
The talk argues that memory is the next agent primitive after MCP and skills, because long-running and multi-agent systems need to learn from their own work. Anthropic's answer has two parts. In-session memory is a file system the agent reads and writes during a task, with permission scopes, content-hash concurrency control, version history and attribution. Dreaming is an out-of-band process that reads many sessions at once, finds shared patterns and mistakes, and produces a reviewed update to memory. The pitch is that separating memory quality from task completion, and spending extra compute in the background, lets memory grow into a large shared knowledge base without slowing agents down.
Key ideas, with timestamps
- 2:00
Memory as the next primitive
He places memory after MCP (tools and data), harnesses like Claude Code and the Agent SDK, and skills (launched in October). The stated gap is continuous self-learning over long tasks. Agents should learn success criteria, common mistakes, their environment and what other agents found.
- 4:30
From CLAUDE.md to a file system
He traces the history: CLAUDE.md in Claude Code was an early, constrained form where agent and user left notes in one file, and the SDK memory tool was a tightly specified tool call. Managed Agents instead give Claude a hierarchy of files it organizes itself with bash and grep. He claims Opus 4.7, launched the month before, is state of the art at this file-based memory.
- 7:00
Scopes and optimistic concurrency
An agent can mount several memory stores with different permissions, for example a read-only org-wide store of runbooks and a read-write working store. Because hundreds of agents may write to the same store, an update carries a content hash so an agent can check it is not overwriting another agent's change.
- 8:15
Version history and a standalone API
Every memory change is logged with which agent, session and time made it, and agents can read that log later. A separate API lets customers run their own pipelines over memory, such as PII scanning, cleanup or cloning into other systems.
- 9:30
Three layers of a memory system
He splits the design into storage (data plus attribution metadata), structure and content (files, and skills as procedural memory) and process (what triggers updates and from which sources). The memory API covers the first two. The process layer is where single agents fell short: they missed what other sessions learned and could not keep a large store tidy.
- 11:15
Dreaming, defined
Dreaming is a batch job, run on a schedule or when agents finish a task, that reads recent transcripts, finds repeated mistakes such as a failed tool call, and outputs an updated memory state. You can apply it directly or review it first through the API. Harvey reported a six times higher completion rate on one legal benchmark scenario.
- 13:30
Why out of band matters
A single agent only sees its own task, while dreaming sees many agents at once. It also gives memory quality its own objective, separate from finishing the task, and adds no latency to the agent's work. He compares it to test-time compute and to building a search index ahead of query time, so the cost is shared by every agent that reads the store.
- 17:30
The SRE demo
An SRE agent responds to a P1 alert from a dispatch service, investigates CPU and recent deploys, and writes notes. A second agent paged minutes later reads those notes and skips the repeat work. A dreaming run over seven days of sessions then notices that agents fire 60 seconds after upstream CPU spikes, suspects retry logic, merges five duplicate entries, drops a stale one and adds a verification note.
What it gets right
Memory as files is a good default. Files are inspectable, diffable and easy to export. Engineers can read exactly what the agent believes, which is hard with an opaque vector store. It also reuses skills the model already has from coding work.
Scopes match how organizations work. A read-only store for policy and runbooks plus a read-write store for working notes is the right split. Most early agent memory setups gave every agent write access to everything.
Separating write-time from consolidation. Agents in the middle of a task make poor librarians. Moving deduplication, pruning and pattern-finding into a background job is the same idea Letta explored in 2025 under the name sleep-time compute, and it is a sound one. The SRE example, where no single agent could see the 60-second pattern, shows the value clearly.
What it leaves out
Bad memories spread too. Shared memory makes good learnings travel fast, but wrong ones travel just as fast. A mistaken conclusion written by one agent, or text planted through a prompt injection in a ticket or log, becomes trusted context for every later agent. The talk mentions review and PII scanning, but not provenance checks or how to quarantine a suspect entry.
Self-verification is weak verification. The dreaming run marks a memory as accurate because a transcript agreed with it. That is the model checking its own notes. For anything consequential, a human review step or an external check (a passing test, a confirmed metric) should gate the merge.
The numbers are customer-reported. Rakuten's 90% drop in first-pass mistakes and Harvey's six times gain on one scenario come without methods. Treat them as anecdotes until there are published evals.
Scale limits of grep. He describes memory growing into a large knowledge base, but grep over files works best when the store is small enough to navigate. At larger sizes you need search that understands meaning, and the talk does not say how that is handled.
Status may have changed. As of the video's May 2026 upload, memory was in public beta and dreaming was a research preview. Check the current docs before building on either.
How this applies to memory across AI tools
This design is for agents inside one platform learning from their own runs. Most people have a different gap: what they themselves have read and watched is not available to any of their assistants. Those are two separate layers. Agent working memory records what the agent did; a knowledge base records source material you chose to keep.
The second layer works best when it is tool-neutral. BrainTube takes that approach: it saves YouTube videos with their transcripts, articles, PDFs and podcasts into one compiled knowledge base and exposes it as an MCP server, so Claude, ChatGPT, Cursor and other MCP clients can search it. The lessons from this talk still apply to any such store: keep attribution, keep version history and review what gets merged.
For background on the layers, see what an AI memory layer is and persistent memory versus the context window.
Who should watch it
Watch it if you build agents on Anthropic's platform or design shared memory for multi-agent systems; the design requirements from 4:15 to 9:30 are useful even if you use another stack. Jump to 11:15 for the dreaming explanation and 17:30 for the demo, which makes the abstract parts concrete. Skip it if you want memory for your own notes or chats; this is an API for developers running agent fleets, and parts of it are a product launch.
Frequently asked
- What is dreaming in Claude Managed Agents?
- Dreaming is a background batch job that reads recent agent session transcripts, looks for repeated mistakes and useful patterns, and produces an updated version of a memory store. You can apply the update directly or review it first. It was launched as a research preview in May 2026.
- How does Anthropic store agent memory?
- In Claude Managed Agents, memory is a set of files in a hierarchy that the agent organizes and edits with tools like bash and grep. Stores can be read-only or read-write, every change is versioned with which agent made it, and a content hash prevents agents overwriting each other.
- What is the difference between CLAUDE.md and agent memory stores?
- CLAUDE.md is a single notes file that Claude Code loads into context, edited by both the user and the agent. Memory stores in Managed Agents are multi-file, permission-scoped, versioned and shared across many agents, and they can be curated by the dreaming process.
Keep videos like this one searchable
BrainTube saves YouTube videos with their transcripts into one compiled knowledge base that Claude, ChatGPT, Cursor and other MCP clients can search.
Go deeper
More video notes
- AI Agent Memory Architecture: Structured SQL, Semantic Vector Search & Memory Bank · Google Cloud Tech
- Skills vs MCP vs RAG vs Memory: What AI Agents Need to Know · IBM Technology
- Agent Memory EXPLAINED - Complete Architecture · Hugging Face
- Improved AI Memory? 🧠 Full Hermes Tutorial (Mnemosyne & Hindsight) · Wanderloots
Are you the creator and want this page changed or removed? Contact us and we will act within 48 hours.