Agent Dreaming for AI: How Agents Learn from Experience Without Retraining
What if an AI agent could learn while nobody was talking to it?
A conventional LLM application receives a prompt, performs inference, returns an answer, and stops. Even a tool-using agent can lose the lessons of its work when the session ends. Retrieval-augmented generation (RAG) can search an external knowledge base, but search alone does not resolve contradictory notes, learn from repeated mistakes, or decide which experiences deserve persistent attention.
This is no longer just a metaphor. OpenAI described a much more scalable dreaming-based ChatGPT memory system in June 2026; Anthropic announced dreaming in Claude Managed Agents in May 2026 and published detailed research on the components of agent memory on November 6, 2026. Earlier work by Letta and UC Berkeley investigated sleep-time compute, the architectural foundation for moving some reasoning from user-facing requests to idle periods.
Why ordinary agent memory is not enough
Consider a coding agent working on a repository across forty sessions. On Monday it learns that integration tests require a specific database fixture. On Tuesday it documents a workaround that later proves incorrect. On Wednesday the repository changes the fixture path. On Friday it attempts the same failed workaround again because its top-level memory still contains Monday’s assumption.
The failure is not necessarily a lack of context-window capacity. The information may already exist in transcripts and files. The issue is that memory has become stale, inconsistent, or poorly organized.
A basic write-and-retrieve loop looks like this:
User task -> Agent -> Transcript -> Memory extraction -> Vector store
Next task -> Similarity search -> Retrieved memory -> AgentThis is useful, but it does not inherently validate whether retrieved notes remain true. Semantic similarity is not factual verification. More stored text can increase retrieval ambiguity, context cost, and the risk of trusting old assumptions.
Dreaming adds a second loop:
ACTIVE / ONLINE LOOP
User task -> Agent + tools -> Response / action -> Event log
^ |
| v
Retrieved trusted memory Evidence and notes
^ |
| v
Published memory <--- Review / validate candidate
^
|
OFFLINE / DREAMING LOOP
Sessions + old memory -> Reflect -> Reconcile
-> Deduplicate -> Re-indexThe key distinction is that online execution captures experiences, while offline consolidation organizes their future value.
Where the idea originated: Sleep-time compute
Letta’s April 2025 research framed sleep-time compute as a complement to test-time compute. Test-time compute lets a model reason more before answering the current request; sleep-time compute lets a stateful system reason between requests and save the outcome for later. A primary agent can be optimized for interactive latency, while a separate sleep-time agent may use a slower or stronger model to revise persistent context.
The shift changes when computation is paid for. A user no longer needs to wait for all possible analysis to happen inside the active response. The offline process can process material in advance, although it still consumes tokens, storage, and infrastructure resources.
This is meaningful only if the improved context survives between sessions. An LLM invoked without persistent storage cannot benefit from yesterday’s reflection merely because a background job ran yesterday.
OpenAI’s Dreaming: From saved memories to synthesized memory
OpenAI’s June 4, 2026 article describes a progression. In April 2024, ChatGPT introduced saved memories, which relied heavily on explicit reminders or detectable save cues. In April 2025, OpenAI introduced an early form of dreaming that could derive useful memory from previous chats instead of relying entirely on explicit save requests. In June 2026, OpenAI announced a more capable, compute-efficient architecture built around dreaming, called Dreaming V3 in its evaluation comparison.
OpenAI identifies three critical evaluation dimensions. Continuity asks whether relevant information carries forward to later conversations. Preference adherence asks whether an assistant consistently acts on known preferences and constraints. Temporal freshness asks whether memories change as the world changes: ‘I am visiting Singapore next month’ should not persist indefinitely as a current trip.
The temporal dimension is especially important. A single event can transition from planned to ongoing to completed. A durable memory system needs temporal interpretation, not just an append-only database of statements. Otherwise, what was true yesterday can become a confident but incorrect assumption tomorrow.
OpenAI reports that improved efficiency reduced the compute required for the Free-user dreaming experience by approximately 5x, helping make wider deployment feasible. That is a statement about OpenAI’s reported system improvement, not a general benchmark for arbitrary dreaming architectures.
Anthropic’s agent-memory hierarchy
Anthropic’s November 6, 2026 engineering research provides a more explicit architectural account. It separates agent memory into four useful layers:
Transcripts are the evidence layer. They preserve what happened: user instructions, tool outputs, decisions, failures, and results. They can be searched later, but a transcript is not automatically a verified account of the external world.
Memory notes are observations the agent records during work. They may include project constraints, validated strategies, unresolved problems, and user preferences. They are cheap to reuse but can be mistaken or out-of-date.
Memory representations organize knowledge above individual notes. Examples include linked wiki pages or navigational indexes connecting related facts. A representation helps the agent locate relevant knowledge instead of searching an enormous undifferentiated archive.
Injected context is the small, highest-priority collection of facts or navigation hints loaded into a future session. It must remain compact because it consumes prompt tokens and can influence every task.
Dreaming works across these layers, checking notes against transcripts, producing representations, repairing broken links, and promoting or demoting information according to its anticipated future utility. This is a hierarchy of access and organization, not a claim that all memory must be placed directly in the prompt.
Anthropic notes that Claude Code’s auto-memory design loads only the first 200 lines or 25 KB of MEMORY.md as an index-like injected layer. The rest remains available for on-demand access. This is a concrete example of the principle that the most valuable memory is not necessarily the largest memory.
How dreaming works, step by step
Stage A: Capture the experience
During normal execution, the agent logs session events with timestamps, tool responses, outcomes, and references to evidence. It may also make immediate notes about salient facts. Capture should distinguish user assertions, tool observations, hypotheses, decisions, and confirmed outcomes. If all five are stored as equivalent truths, later consolidation becomes unsafe.
Stage B: Trigger consolidation
A job may run on a schedule, after a threshold of new sessions, when memory changes significantly, or when contradictions are detected. Scheduling is an engineering choice; frequent consolidation improves freshness but increases compute and risks churn. Infrequent consolidation saves money but permits stale memory to persist.
Stage C: Reconstruct and compare
The dreaming worker reads a bounded collection of transcripts and the current memory snapshot. It identifies duplicate notes, conflicting statements, expired time-dependent facts, repeated failures, and missing knowledge links. A plausible inference is not enough: higher-impact updates should be tied to source evidence.
Stage D: Generate candidate revisions
The worker proposes actions such as merging redundant observations, correcting outdated statements, adding a new procedure learned from successful tasks, producing a wiki page, or removing a detail from the default context while keeping it searchable.
Stage E: Validate and publish
The candidate memory is evaluated for factual support, recency, privacy, contradictions, and expected utility. A higher-assurance implementation publishes an immutable, versioned candidate only after automated checks or human approval. Failed updates leave the current memory intact. The next user session then sees an appropriate small subset of the improved memory.
The candidate-then-promote pattern is particularly important because dreaming can hallucinate too. A background LLM rewriting persistent memory is not inherently more reliable than a foreground LLM writing a note.
Anthropic’s actual results: What does the evidence show?
Anthropic tested these ideas using long-horizon tasks and a substantial document corpus. The experimental results should not be collapsed into a single broad claim that ‘dreaming increases accuracy by X%’: different experiments isolate different memory components.
Get DhanushKumar’s stories in your inbox
Join Medium for free to get updates from this writer.
In a CL-Bench database task, Claude models answered questions across separate sessions and could retain knowledge in a persistent memory directory. For Opus 5.5, mean reward was 0.655 without memory and 0.838 with memory; for Sonnet 5.5, it was 0.644 versus 0.833. These numbers primarily demonstrate the benefit of effective persistent memory, not an isolated effect of dreaming.
In a Pokémon navigation experiment, a memory note incorrectly said that a PokéCenter lay on the east side of Mt. Moon. Claude repeatedly acted on the error. A dreaming pass cross-checked the note against the transcript, repaired the location belief, and enabled the agent to navigate toward Cerulean City. The corrected-memory run reached it after 1,935 actions; the raw-memory and no-memory comparison runs did not reach it in the reported runs. This illustrates why verification can matter more than merely saving more observations.
In a knowledge-wiki experiment, Anthropic used a corpus of around 350,000 files and 420 million tokens and a 25-question evaluation. Over 128 dreaming sessions, agents progressively constructed linked wiki representations. With a wiki alone, scores increased from 13% to 48% of graded criteria as the wiki developed. When combined with search, performance increased from 54% to 61%, while a search-only comparison scored 53%. Anthropic also reported roughly 20,000 fewer tokens per question using search plus wiki in that experiment. These are specific research conditions, not guarantees for every enterprise RAG system.
The interpretation is subtle: memory quality, retrieval, and structured representations reinforce each other. The best configuration was not ‘replace retrieval with dreaming’; it was combine reliable retrieval with useful synthesized knowledge.
How Anthropic exposes dreaming to developers
Anthropic introduced dreaming in Claude Managed Agents as a research preview on May 19, 2026. Unlike OpenAI’s public-facing ChatGPT explanation, Anthropic’s platform documentation describes a concrete developer workflow. A dream consumes an existing memory store and 1–100 session transcripts, runs asynchronously, and produces a separate output memory store. The input store is not edited. Developers can inspect, use, or discard the generated output.
The documented Python API uses client.beta.dreams.create(...) with memory-store and session inputs. The feature requires research-preview access and the dreaming-specific beta header; do not assume it is enabled on every Anthropic account. It is also documented as not eligible for zero-data-retention or HIPAA workflows, which matters for regulated environments.
The product description also discusses extracting patterns across agents, recurring failures, shared preferences, and evolving workflows. This makes dreaming relevant not only to a personal assistant but also to multi-agent systems in which different workers discover complementary facts.
Dreaming versus RAG, compaction, caching, and fine-tuning
These methods are complementary. RAG can retrieve source material for a dreaming worker to verify against; compaction can keep active sessions within context limits; caching can reduce costs; dreaming can improve memory organization; and fine-tuning may help when a behavior should generalize beyond facts stored in one agent’s external memory.
A production architecture for an agent dreaming system
The following is a reference design, not a claim about OpenAI’s or Anthropic’s internal infrastructure.
An implementation might store event logs in append-only object storage or PostgreSQL, structured notes in a transactional database, and searchable text in a retrieval index. Each note should carry a source identifier, creation time, last-confirmed time, tenant scope, confidence or verification status, expiration policy, and the snapshot version that introduced it. An event-driven or scheduled worker reads new session batches, produces a candidate snapshot, runs checks, and promotes the snapshot atomically.
Memory selection is a constrained optimization problem. A useful heuristic assigns a candidate note a score based on expected future relevance, evidential confidence, freshness, and uniqueness, while penalizing token cost, privacy risk, duplication, and contradiction. The exact weights should be calibrated using downstream task evaluations rather than manually optimized on a handful of demonstrations.
The retrieval layer should favor small trusted indexes plus targeted search. Putting all lessons into a giant system prompt is both expensive and risky: one outdated instruction can mislead every subsequent session. A top-level memory file should primarily contain stable constraints, high-confidence facts, and pointers into more detailed records.
Security and reliability
Memory is an attack surface. User text, retrieved pages, repository files, and tool outputs may contain malicious instructions. These must be treated as untrusted data, not promoted into agent system instructions simply because the dreaming worker has read them. A secure implementation should isolate each tenant’s memory using authorization checks and resource-scoped identities, encrypt data in transit and at rest, redact or restrict sensitive content, preserve deletion requests across derived memories, and block secrets from entering default context.
A dreaming worker should have least-privilege read access to historical material and write access only to a staging area. Production memory promotion should use a separate authorized step. Snapshot IDs, source citations, review decisions, and audit logs should make any memory change explainable and reversible. Idempotent job IDs and optimistic concurrency control help prevent overlapping dream jobs from overwriting each other’s updates.
For scale, partition jobs by tenant, apply batching and backpressure, and isolate interactive serving from offline processing so that consolidation cannot exhaust the real-time model budget. Monitoring should include dream queue depth, duration, token spend, failed jobs, candidate rejection rate, memory freshness, contradiction rate, retrieval latency, and regression rate on a fixed evaluation suite.
A realistic example: An AI coding agent that stops repeating mistakes
Suppose an agent develops a Python service across multiple sessions. Initially, it observes that a migration fails with a database permissions error. It guesses that an application bug is responsible and writes that hypothesis into memory. A later session reveals that the underlying role simply lacks access to the migration table. Without consolidation, both statements may coexist. Retrieval could return the wrong diagnosis because it happens to be phrased similarly to the current problem.
A dreaming worker can compare the sessions, identify the later verified root cause, retain a record of the earlier incorrect assumption, and generate a durable lesson such as: ‘For this environment, check the database role and grants before changing application migration logic.’ It can link this lesson to the exact error, test evidence, and repository scope. It should not generalize the rule into ‘all migration failures are permission errors.’
At the next session, the coding agent retrieves the validated lesson, checks whether the environment is the same, and proceeds with better context. The improvement comes from evidence-backed memory revision, not from changing the model’s weights.
A multi-agent version can share approved lessons between a coding agent, a test agent, and an incident-analysis agent, while keeping personal preferences and privileged observations scoped to the correct user or project. Cross-agent memory sharing without such boundaries is a privacy and security problem.
How to evaluate whether dreaming actually helps
A benchmark should compare at least three conditions: a stateless agent; the same agent with ordinary persistent notes and retrieval; and that agent with dreaming enabled. Keep model, available tools, task distribution, budgets, and evaluation criteria as comparable as possible.
Measure future-task correctness, not just how elegant the synthesized notes look. Add questions that test whether the system remembers a long-term constraint, updates a temporary fact after its expiry, avoids a previously documented failure, retrieves the original evidence for a claim, and declines to trust an injected false instruction.
For production evaluation, track accuracy, contradiction rate, stale-memory rate, unsupported-claim rate, deletion compliance, P95 interactive latency, offline tokens consumed per useful improvement, and memory token footprint. Test adverse scenarios: misleading transcripts, conflicting user instructions, compromised tool outputs, partial job failures, concurrent promotions, and tenant-boundary violations.
One simple economic model is:
Net value of dreaming
= value of reduced future errors and saved interactive work
- offline model cost
- verification and storage cost
- cost of new errors introduced by bad memory updatesA system is not necessarily better because it dreams more frequently. Its consolidation schedule should be justified by measurable improvements in downstream work.
Open research questions
When should dreaming run? Fixed schedules are simple, but change-aware scheduling may be more efficient. A sudden contradiction, newly completed task, or outdated high-traffic note may justify an immediate pass, while a stable archive may not need frequent attention.
What deserves memory? An agent cannot know exactly which details will matter later. It must balance the risk of forgetting something important with the cost of retaining transient noise. Anthropic’s experiments show that stronger models can make more selective salience judgments, while rigid capture rules can sometimes reduce performance.
How do we verify synthesized lessons? Transcript agreement is useful but not always sufficient: a transcript can contain a mistaken observation. Tool-derived evidence, source provenance, temporal validity, and independent outcome checks should therefore matter more than repetition alone.
Can agents safely share dreams? Shared workflow lessons can help collaborative systems, but one agent’s valid project-specific conclusion may be inappropriate for another team, tenant, or environment. Cross-agent knowledge needs scoping, access control, and conflict resolution.
Is dreaming genuine learning? It is legitimate to call it learning at the system level when future behavior improves from retained experience. It should not be confused with continual gradient-based learning of the base model. Much of the current engineering value comes from improving what the model can read, not altering what its parameters encode.
Conclusion: The future is not infinite memory, but better memory
Agent dreaming offers a different path toward more capable long-running agents. Instead of continuously expanding prompts or storing every detail forever, a system can revisit experience, distinguish evidence from speculation, correct itself, and compress the result into usable future context.
OpenAI emphasizes continuity, personalization, temporal relevance, and efficient operation at broad consumer scale. Anthropic provides concrete agent-memory layers, experimental results, and a research-preview developer workflow for reconstructing memory stores. Letta’s sleep-time compute research supplies the broader idea of using idle computation to improve the state of future interactions.
The strongest architectural lesson is that an agent’s memory should be treated as a versioned, evidence-backed, evolving knowledge system, not an ever-growing collection of text files or embeddings. The promise is substantial; so are the requirements for verification, privacy, cost control, observability, and reversible updates.
An agent does not become reliable simply because it remembers. It becomes more reliable when it can also determine what is worth remembering, what has changed, and what it previously got wrong.
