Memory and Dreaming
Hello, friends.
I want to talk about a talk that I think will look like an inflection point in a few months. Ravi, who leads the API knowledge team at Anthropic, presented at Code with Claude London on memory and dreaming for agents. Twenty-one minutes. Two features. One of them is in production. The other is in research preview.
The reason I want to write about it now is that the customer numbers Ravi shared are not subtle. Rakuten: a 97 percent decrease in first-pass errors in production agents. Harvey: a 6x increase in completion rates on their legal benchmark with dreaming on. Wisedocs: meaningful reductions in cross-session issues in their document verification pipeline.
These are not benchmark wins. These are production deployments at real companies. When the same primitive is pushing those numbers across that kind of industry spread, something has changed in what an agent platform is supposed to do.
Three key takeaways
- Anthropic modeled agent memory as a file system because Claude is already strong at navigating files. The lesson is to stop building abstractions on top of capabilities the model already has.
- Dreaming is a second process that reviews past sessions and rewrites shared memory. It runs out of band, so it adds no latency to live agents.
- The combination closes the learning loop. Memory raises the floor. Dreaming raises it further.
The simple framing of the problem
Ravi opened with a setup that you could explain to a non-technical executive in thirty seconds.
Imagine an agent running task one. Then task two. Then task three. Without memory, performance on each task tends to be similar, because every agent starts from a blank slate. With memory, performance should rise from task to task. The agent carries forward what it learned about the environment, the tools, the patterns of failure that turned out to be important.
Once you make that work for a single agent, the next move is to make it work across agents. Same memory store. Multiple sessions. Eventually a swarm of agents contributing to and maintaining a shared understanding of the organization they operate in.
That is the dream. It is also what Rakuten and Harvey have been building against.
Why a file system
The interesting design choice is what memory is not. It is not a vector database. It is not a knowledge graph. It is not a structured semantic layer with embeddings and similarity search.
It is a file system.
Ravi's reasoning was direct. Models are now strong at navigating virtual environments and file systems. Claude is capable with bash and standard tools for reading, updating, and organizing files. Opus 4.7, which Anthropic launched a month before the talk, is described as state of the art at file-system-based memory, including discerning which context is worth saving for its future self and how to structure it.
So Anthropic modeled memory as a file system. Then they got out of Claude's way.
Ravi's phrase: "let it cook."
This is the contrarian point worth sitting with. The instinct in this space is to build elaborate retrieval systems. Anthropic's bet is that as models improve, the simplest interface wins. A directory. Files. Read, write, list, organize. The model handles the rest.
There is a deeper reason this works. Models trained on huge amounts of source code have spent more time looking at file systems than at any other data store. They understand directory structures intuitively. They understand naming conventions. They understand when to split a file and when to consolidate. When you build a custom abstraction, you ask the model to learn your abstraction. The model arrives knowing files.
Worth noting that this same principle, getting out of the model's way, drove Anthropic's design of skills earlier in 2025. Skills was deliberately basic. No clever encoding. A simple format the model could read and write fluently. That bet paid off, and memory is the next application of the same idea.
The three pieces of the architecture
Three components stack to make this production-ready.
The storage layer handles how data is managed and how changes are tracked. Anthropic implemented version control, with diffs between versions and attribution per agent. For enterprise deployments, you need to answer the question of why memory looks the way it does. Version control answers that.
The structure of memory is the file format itself. Hierarchies of folders. Plain text. The model writes its own notes in a format it already knows how to read.
The processing is the agent itself writing memory as it works. Taking notes while doing something. Reading those notes on the next task.
Multi-agent support layers in cleanly. Read-only and read-write scopes. Organization-wide memory that all agents can read but only specific processes can write. Task-specific memory that agents read and write freely. The combination creates a hierarchy that scales as the agent population grows.
For write conflicts, Anthropic chose optimistic concurrency. Agents do not lock files. They write, and the system reconciles. Same model as distributed version control. It scales better than locking when most writes are non-conflicting, which is the usual case.
There is also a standalone API, so memory is not tied to running inside Anthropic's managed agents environment. Standard CRUD operations, plus enterprise operations like exports and redactions for compliance.
Where writing memory alone breaks
Ravi walked through what happened as Anthropic scaled this into multi-agent, multi-session deployments. The single-agent story worked. Agents took notes, read them back, improved on the next task.
Across sessions and agents, problems appeared.
Agents kept making the same mistakes. They learned independently rather than collectively. The same inefficiencies repeated across sessions. Memory updates were locally optimal but globally suboptimal. Duplication appeared. Fragmentation appeared. Knowledge that should have been consolidated stayed scattered across files written by different agents at different times.
There is a parallel to human teams that should sound familiar. Individual contributors writing notes after their own work produces useful but uncoordinated knowledge. Without someone reviewing across the team and rewriting the shared playbook, every new hire ends up rediscovering the same patterns the team learned six months ago. Agents fall into exactly the same trap when they only write memory and never consolidate it.
This is where dreaming enters.
What dreaming does
Dreaming is a process that runs separately from agent execution. It reads session transcripts, inspects the current state of memory, and proposes optimizations. The output is a verified, better-organized snapshot of memories that agents can adopt.
A few design choices make this work.
It is out of band. Dreaming does not run inside the agent loop. It has its own harness, which means no added latency for live agents, and dreaming can spend tokens on careful analysis without competing with whatever task an agent is trying to complete.
It is cross-session and cross-agent. Dreaming looks at transcripts from many sessions and discerns patterns that no single agent in isolation would catch. A single agent only sees what it just did. Dreaming sees the population.
It is decoupled. Dreaming can be kicked off ad hoc, on a nightly schedule, hourly, or triggered by events like the end of a session. All via API.
It is itself an agent system. Ravi noted that dreaming is built on Cloud Managed Agents. The dreaming process spins off sub-agents to analyze transcripts in parallel. Anthropic used the primitives they were shipping for customers to build the meta-capability that improves those customers' memory.
The Harvey number, a 6x increase in completion rates on their legal benchmark with dreaming on, is not a marginal improvement. It is the difference between a workflow that mostly fails and one that mostly works.
The demo
The talk closed with a site reliability platform. Incoming alerts spin up agents to triage and fix issues. Each agent reads from memory stores.
An organization-wide read-only store holds SLO policies, runbooks, on-call mappings. Things that do not change often but every agent needs.
Read-write stores are scoped to the task at hand. Agents write what they learn as they work.
In the example, an agent investigated an alert, found the root cause, put a fix in flight, and noted in shared memory that the fix was incoming. When a similar alert hit later, the downstream agent read the memory, saw the fix was in flight, and acted accordingly. No duplicate work. No conflicting fixes. The agents coordinated through shared memory without direct communication.
Then Ravi kicked off a dream. Five sessions from the last seven days. Dreaming spun off sub-agents to analyze the transcripts. After it finished, the diff showed a pattern that no individual agent had spotted. Alerts triggering 60 seconds after CPU spikes, recurring across sessions. The dreaming process inferred a possible issue with retry behavior and updated memory so future agents could check for that pattern when triaging similar alerts.
The triage log went from a rote sequence of events to a synthesized note that informed the next agent. That is the kind of compounding improvement memory plus dreaming is supposed to produce.
What I am taking into client work
This shifted a few things in how I am advising clients on agent architecture.
Stop building custom retrieval abstractions on top of capabilities the model already has. If the model knows files, use files. If you have a custom layer that is not earning its keep with measurable wins, kill it.
Audit where agent knowledge lives today. Most teams have it scattered across prompts, system messages, vector stores, ad hoc tools. Memory as a file system gives you a place to consolidate. Start with the read-only org-wide content like runbooks, policies, shared context.
Identify the patterns your agents repeat. Mistakes. Inefficiencies. Coordination failures across sessions. These are the patterns dreaming exists to catch. The more you can articulate them, the better you can evaluate dreaming when you turn it on.
Decide a dreaming cadence deliberately. Nightly is a reasonable default. Event-triggered makes sense for fast-moving environments. Ad hoc is fine when you are still learning the workflow. The point is to have a deliberate schedule rather than letting memory drift unattended.
Treat memory as a first-class artifact of your agent deployment. It is going to outlast any single agent generation. The investment compounds.
One more thing on the dreaming side that I think is underappreciated. Because dreaming runs out of band, the cost profile of the whole system changes. You can dream against expensive compute without affecting the latency budget of live agents. That means you can afford to use a stronger model for the dreaming pass than you would ever use in the hot path. The dreaming agent can be slow and careful in a way that a user-facing agent cannot. The slow, careful work then translates into better memory that the fast user-facing agents read from. You get the benefit of deliberation without paying for it on every turn.
This is the same architectural idea behind background indexing in search engines or batch training in machine learning systems. Do the expensive analysis offline. Serve the artifact online. Anthropic just applied it to agent memory, and the customer numbers suggest it works.
Where this leads
The shape of this is a feedback loop. Agents write memory. Dreaming refines memory. The next generation of agents reads better memory. Their sessions feed the next dreaming run. The loop closes.
Memory raises the floor for every agent. Dreaming raises it further. The two together make self-learning real in production, not as a research demo.
The companies that figure out how to operate inside that loop will compound their agent performance in ways that single-agent shops will not be able to match. Not because the models are different. Because the memory they draw on gets better between releases.
Hit reply and tell me whether you are running agent memory today, and if so, where it lives. I am collecting patterns from client work and curious how others have structured this.
Talk soon, Marco