Memory and Dreaming: How Agents Start Learning Across Sessions

Three key takeaways

1. Anthropic modeled agent memory as a file system because Claude is already strong at navigating files. The win is removing the abstraction, not adding one.
2. Dreaming is a separate process that reviews past sessions and rewrites the shared memory store. It runs out of band, so it adds no latency to live agents.
3. Real customer numbers show what this unlocks. Rakuten reported a 97 percent drop in first-pass errors. Harvey reported a 6x increase in completion rate on a legal benchmark with dreaming on.

Ravi, who leads the API knowledge team within platform at Anthropic, opened his Code with Claude London 2026 talk with a line that flagged how fast this space is moving. Anthropic released Cloud Code and the agent SDK in 2025. His exact phrase: "that blows my mind that that was in 2025. It honestly feels like a lifetime ago."

The thing he came to announce is the next step in that compression. Memory and dreaming. Two features that close the loop on how agents learn across tasks, sessions, and teammates. Memory, available now for cloud managed agents. Dreaming, in research preview.

This piece walks through what they shipped, why the design choices land the way they do, and the customer numbers that suggest this is not a small change.

The problem memory solves

The setup is straightforward. Imagine an agent running task one, then task two, then task three. Without memory, performance on each task tends to be similar. Every agent starts from the same blank slate. With memory, performance should rise from task to task. The agent carries forward what worked, what failed, and what it learned about the environment.

Once that single-agent loop closes, the next move is multi-agent. The same memory store gets shared across agents, across environments. A swarm of agents contributing to and maintaining a shared understanding of the organization they operate in. Ravi called that "the dream." It is also the operating reality already taking shape inside enterprise deployments.

Anthropic launched memory for Cloud Managed Agents recently, and the early customer signals are striking. Rakuten saw a 97 percent decrease in first-pass errors in production agents. Wisedocs reduced common issues across sessions in their document verification pipeline using cross-session memory. The pattern Ravi described, repeatedly, is that customers stop building memory infrastructure and start building product.

Why a file system, and not something more elaborate

The interesting design choice in the memory primitive is what it is not. It is not a vector database. It is not a graph. It is not a structured semantic layer with embeddings and similarity search.

It is a file system.

The reasoning Ravi walked through is worth quoting. Models are now strong at navigating virtual environments and file systems. Claude is already capable with bash and standard tools for reading, updating, and organizing files. Opus 4.7, which Anthropic launched the 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 exact phrasing: "the key principle is getting out of cloud's way and letting it use the capabilities it already has that are very strong. Or as we like to say, let it cook."

That is the same principle behind skills, which Anthropic also positioned as a deliberately basic format. Highly flexible. No clever abstractions. The model knows how to operate with files because the model has seen a lot of files. Adding indirection rarely improves on that.

This is a contrarian point worth dwelling on. The instinct in this space is to build elaborate retrieval systems with structured queries, semantic search, and tight bindings. 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 vast 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. None of that was something Anthropic had to teach. It was already in the model.

When you build a custom abstraction layer, you ask the model to learn your abstraction. That is wasted capability. The model arrives knowing files. Use files.

The pieces of the memory architecture

Three components stack together to make this work in production.

The first is the storage layer. How data is managed and how changes are tracked. Anthropic implemented version control, which produces an audit trail of memory changes over time. Developers can diff between versions. There is attribution to see which agent wrote which part of which file. For enterprise deployments, this matters. You need to be able to answer the question of why memory looks the way it does.

The second is the structure of memory. The format that lets Claude get the most out of what is stored. Files are the answer. Hierarchies of folders. Plain text. The model writes its own notes in a format it knows how to read.

The third is the cloud-driven processing for updating memory. This is the agent itself writing memory as it works. Taking notes while doing something. Reading those notes on the next task.

The architecture also supports multi-agent operation in practical ways. 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 across agents, Anthropic chose optimistic concurrency control. Agents do not lock files. They write, and the system reconciles. If two agents try to update the same memory at the same time, the system catches the conflict at commit rather than blocking at the read. This is the same model used in distributed version control. It scales better than pessimistic locking when most writes are non-conflicting, which is the usual case.

There is also a standalone API. Memory does not require you to be inside the managed agents environment to use it. Developers can run their systems in different environments and still drive memory through standard create-read-update-delete operations, plus enterprise operations like exports and redactions. For organizations that need to redact specific content from agent memory for compliance reasons, the API supports that directly.

The limit of writing memory alone

Ravi walked through what happened as Anthropic scaled this pattern into multi-agent, multi-session use cases. 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 patterns of inefficiency repeated. 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.

The diagnosis is interesting. When you let agents write memory as they work, each agent is optimizing for what it just experienced. None of them have the perspective to see the pattern across sessions. The local optimum gets in the way of the global one.

There is a parallel here 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. The team gets smarter at the individual level and stays stuck at the collective level. Agents, when they only write memory and never consolidate it, fall into exactly the same trap.

This is where dreaming enters.

Dreaming, the second loop

Dreaming is a process that runs separately from agent execution. It looks at 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. That means it does not add latency to live agents. It also means 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. It is all controlled 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. The team used the same primitives they were shipping for customers to build the meta-capability that improves those customers' memory.

Customer numbers are striking. Harvey, the legal AI company, saw a 6x increase in completion rates on their legal benchmark with dreaming enabled. That is not a marginal improvement. That is the difference between a workflow that mostly fails and a workflow that mostly works.

What the demo actually showed

Ravi closed with a demo of a site reliability platform. Incoming alerts and pages flow into a system that spins up agents to triage and fix issues. Each agent has access to memory stores.

One store is organization-wide, read-only. It holds SLO policies, runbooks, on-call mappings. Stuff that does not change often but every agent needs.

Other stores are read-write, scoped to the task at hand. Agents writing 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, a 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 needing direct communication.

Then Ravi kicked off a dream. The team SRE memory store. Five sessions from the last seven days. Dreaming spun off sub-agents to analyze the transcripts in parallel. 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 that memory plus dreaming is supposed to produce.

Why this is bigger than it looks

The shape of what Ravi described 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.

Ravi drew an analogy to test time compute, which has become Anthropic's framing for letting models spend tokens to explore a problem before answering. The same principle applies here. Dreaming spends compute up front to curate memory. That investment pays dividends across every downstream agent that reads the result. The cost is paid once. The benefit accrues many times.

There is also a structural point about where this leaves agent design. Up until now, the unit of agent improvement has mostly been the prompt and the model. You write better prompts. You upgrade to a newer model. Both happen on a release cadence controlled by the platform or the developer.

Memory and dreaming add a third unit of improvement that operates on a different cadence. Memory grows continuously as agents work. Dreaming improves it on whatever schedule you set. The system gets better between releases because the memory it draws on gets better between releases. That is a different curve than what we have seen before, and it changes what an agent platform actually is.

What to do with this now

If you are running agents in production, three concrete steps from the talk are worth taking soon.

Audit where your agent's knowledge lives today. Most teams have it scattered across prompts, system messages, vector stores, and ad hoc tools. Memory as a file system gives you a place to consolidate. Start with the org-wide read-only content like runbooks, policies, and shared context. Move it into a memory store with the right scope.

Identify the patterns your agents repeat. Mistakes. Inefficiencies. Coordination failures across sessions. These are the things dreaming exists to catch. The more you can articulate the patterns you want surfaced, the better you can evaluate whether dreaming is helping when you turn it on.

Decide on a dreaming cadence. 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.

The loop closes

Ravi's closing framing was that this year, agents will run for longer and longer time scales. Days. Eventually weeks. Continuously building on and improving their view of the world is what makes that capability possible.

Memory raises the floor for every agent. Dreaming raises it further. The two together make the loop close, which is what self-learning actually means in practice.

The dream, as Ravi put it, is swarms of agents contributing to and maintaining a shared understanding of the organization they work in. The dream is now a research preview. The companies that figure out how to operate inside that loop will compound their agent performance in ways that single-agent shops will struggle to catch.

The right question to be asking is not whether to add memory to your agents. It is which patterns of knowledge in your organization should be in the read-only store, which should be in the read-write store, and how often you want the dream to run.

Marco Kotrotsos, specializing in practical AI implementation for organizations ready to close the gap between AI hype and AI value. With 30 years of IT experience now focused purely on AI deployment, he works hands-on with companies to turn AI potential into measurable business outcomes.

This article is published in Autocomplete, a Medium publication about real-world AI for practitioners and decision-makers.

My free Substack newsletter, also called Autocomplete, can be found here: https://acdigest.substack.com.

Source talk: Memory and dreaming for self learning agents at Code with Claude London 2026. https://youtu.be/IGo225tfF2I

← All articles