Agent memory in files: what Anthropic's dreaming experiments show

Anthropic’s answer to how an agent should remember is less exotic than the word “dreaming” suggests. Memory is a folder of text files that survives between sessions. The agent writes notes as it works, and a separate offline pass re-reads the original transcripts to correct those notes, reorganise them and decide what gets loaded at the start of the next session. The useful findings for builders are about discipline rather than architecture: tell the model what memory is for and let it judge what matters, check notes against the record, keep the always-loaded layer small, and do not let several agents rewrite the same page.

Those findings come from “The components of agent memory”, an Anthropic engineering post written by Lance Martin and published on 6 November 2026. It reports a set of internal evaluations: a database task from Continual Learning Bench 1.0, runs of Claude playing Pokémon Red, a wiki built over an internal document corpus, and legal tasks from the Harvey LAB benchmark. Every number in it was measured by Anthropic on its own models. The Pokémon results are explicitly single runs, the post gives no run counts or error bars for the others, and it reports no independent reproduction. The headline figure the post offers on memory representations is narrower than it first appears: a wiki plus a search tool reached 61% of graded criteria on 25 questions, against 53% for search alone.

This explainer reconstructs each experiment with its conditions, sets out the platform mechanisms Anthropic now ships for file-based memory, and turns the results into design decisions. It also draws a line that a similar word obscures. Our earlier explainer on Google’s sleep framework covered research that consolidates new information into a model’s parameters. Anthropic’s post explicitly excludes weight changes. Its “dreaming” edits text that a person can open, read and delete.

What Anthropic counts as agent memory

The post defines agent memory as knowledge Claude gains from experience, including interactions with users and assigned tasks, that it keeps between sessions as context it can read later. It then excludes three neighbouring mechanisms: changes to weights, in-context learning within a single conversation, and compaction, where Claude writes summaries that replace its older turns so it can continue in a fresh context window. That exclusion matters for anyone evaluating a vendor claim about “memory”. The term now covers mechanisms with very different failure modes, costs and audit properties.

Inside that definition the post describes a four-layer hierarchy, drawn in its first figure. At the bottom are transcripts, a searchable log of what happened. Above them sit memory notes that Claude writes when something seems worth keeping. Above those are memory representations, such as a linked wiki. At the top is injected context, a small set of notes the harness loads into every new session. Dreaming sits beside the stack and can read the transcripts and write to every layer above them.

The framing borrows from neuroscience, and the post describes how the hippocampus replays recent experience during sleep and quiet rest. The engineering idea it credits is more recent: sleep-time compute, proposed by researchers at Letta and UC Berkeley in a paper submitted to arXiv on 17 April 2025. That paper had models reason about a context before a query arrived, and reported that this cut the test-time compute needed for the same accuracy by about five times on its stateful maths benchmarks. Anthropic applies the same division of labour to memory: capture now, organise later.

The table below is our taxonomy of the hierarchy, built from the post and from Anthropic’s product documentation. It is meant as a design checklist: each layer has a different writer, load rule and characteristic failure.

Layer	Who writes it, and when	How it reaches a session	Typical failure	Control that addresses it
Transcripts	The harness, continuously	Searched or read on demand; input to dreaming	Deleted by retention rules before anyone consolidates them	Retention policy aligned with the dreaming schedule
Memory notes	The agent, in-session, on its own judgement of salience	Read with file tools when the agent looks	Wrong from the start, or stale as the environment changes	Offline check against transcripts; staleness notes
Representations (wiki)	Mostly dreaming passes, over many sessions	Navigated by links and an index	Grows without abstracting; concurrent writers lose facts	Scope instructions; one writer per page; second-pass gap repair
Injected context	Dreaming or the agent, promoted from below	Loaded into every session automatically	Consumes tokens; an error is carried into every session; long files reduce adherence	Hard size limit; index lines that point down the hierarchy

How this differs from consolidation into weights

The two “sleep” lines of research answer different questions, and builders will meet both. Google Research’s 27 October 2026 post describes a cycle in which the model’s sleep phase moves short-term information into expanded long-term parametric memory, integrating low-rank experts into more stable memory blocks, with distillation and a “dreaming” stage that fine-tunes on synthetic samples. The outcome is a changed model. Anthropic’s dreaming produces a changed folder. Letta, an independent company, documents a third variant in its Letta Code memory guide: background subagents that “review recent conversations, consolidate useful lessons” and update a git-backed memory filesystem, run after a set number of agent steps or at compaction.

Property	Anthropic dreaming (files)	Google sleep framework (weights)	Letta Code dreaming (files)
What persists	Text notes and wiki pages in a memory directory or store	Updated parameters in expanded memory blocks	Files in a git-backed memory filesystem
Can a person read the result?	Yes, as plain files; Managed Agents keeps versions	Not directly; behaviour must be tested	Yes, as files under version control
Undoing a bad consolidation	Discard the output store or restore a version	Requires a model checkpoint rollback	Revert the repository
When it runs	As a job over 1 to 100 past sessions, or on a schedule the builder sets	Periodic offline phase in a research setting	After a set number of steps or at compaction
Status (as checked 12 November 2026)	Research preview in Managed Agents; cookbook for a self-built version	Research, described in a paper and blog	Documented feature in Letta Code

The practical consequence is about governance more than capability. A wrong fact in a file can be found with a text search and removed by deleting a line. A wrong fact distilled into weights has to be detected through behaviour. That makes file memory easier to audit and easier to poison, a trade-off that returns below.

Tell the model what memory is for, not how to use it

The post’s first claim is that writing memory is a prediction. Recording a rule bets that the pattern will matter again; recording a verified fact bets that a future session will want to rely on it without rechecking. The CL-Bench experiment measures how well different Claude models make that bet.

Continual Learning Bench 1.0, whose release page is dated 4 May 2026, is described in the post as a benchmark for an agent’s ability to use memory on long-horizon tasks. The task Anthropic used asks a series of questions answered by looking up information in a database. After each answer Claude is told the correct solution and may write to memory. Anthropic ran it on Claude Managed Agents with each question in a fresh session; the only thing that carried over was a memory directory. The figure plots running mean reward over 30 questions. The post does not state how many runs each bar represents or report variance.

Model	Stateless baseline (mean reward)	With memory directory	Gain (our arithmetic)
Claude Opus 5.5	0.655	0.838	+0.183
Claude Sonnet 5.5	0.644	0.833	+0.189
Claude Opus 5	0.564	0.828	+0.264
Claude Opus 4.7	0.383	0.700	+0.317
Claude Sonnet 5	0.306	0.610	+0.304
Claude Sonnet 4.6	0.330	0.364	+0.034

Source: Anthropic, Figure 3 of the 6 November post. CL-Bench 1.0 database task, run on Claude Managed Agents by Anthropic.

The scores matter less than the post’s description of what each model wrote. Sonnet 4.6 produced scattered files of untested guesses. Opus 4.7 consolidated notes into one reference document and began marking which facts it had checked. Sonnet 5 marked answers as confirmed once the grader had checked them and wrote corrections when it was wrong. Opus 5, in Anthropic’s account, was the first to “close the loop”: most entries carried a rule, how it knew the rule was true, earlier answers and warnings about traps. Opus 5.5 and Sonnet 5.5 did the same and reached roughly Opus 5’s score with memory, from higher baselines.

Fixed rules removed much of the gain

The steering experiment is the most directly usable result in the post. On CL-Bench, Anthropic simply told Claude that a memory folder was available. It then tested specific rules about what to write, one rule per test. With the rule “record only failures”, the change in memory gain was −0.234 for Opus 5, −0.150 for Opus 4.7 and −0.020 for Sonnet 4.6. Measured against the gains in the table, that leaves Opus 5 with roughly a tenth of its original benefit, assuming the same baseline; that last step is our arithmetic, not a figure the post states. The post’s conclusion is that for stronger models, freedom to judge salience beat rules set in advance, and that such rules could weaken performance.

Older models told a different story. Sonnet 4.6 often failed to read its memory directory and did not test its theories. Prompting it to read memory before answering and then to test its theories raised its score from 0.364 to 0.641. Sonnet 5 needed no such prompt: Anthropic says it read memory before answering 9 out of 10 times unprompted, against less than half the time for Sonnet 4.6. The post describes its default for frontier models as simple guidance to write notes when a person asks or when something is clearly worth remembering, with the judgement left to Claude.

That default is visible in shipped tools. The memory tool automatically adds a short protocol to the system prompt that tells Claude to view its memory directory before doing anything else, record progress as it works, and assume its context could be reset at any moment. The documentation’s suggested narrowing is a topic boundary (“Only write down information relevant to <topic>”), not a recording rule. Claude Code’s auto memory defines four note types (user, feedback, project and reference) and says Claude skips anything it can derive from the codebase, such as architecture or file paths. Those are statements of purpose and scope. Neither tells the model which events count.

Salience is about what the environment will not tell you

The Pokémon comparison makes the same point with a vivid contrast. Anthropic compared one run each of Claude Sonnet 3.7 and Claude Fable 5, about 10,000 steps into the game, each given a memory folder it could read and write. Sonnet 3.7 wrote 413 files across 225 folders, about 977,930 characters according to the figure, and had earned one badge. Fable 5 wrote nine files in two folders plus a top-level global.md, about 43,406 characters, and had earned four. Around step 10,000, the post says, Sonnet 3.7 began its fourth folder of “master” memory files and over 17 steps created six files, deleted nine and took no action in the game.

Anthropic’s explanation is the useful part. Much of what Sonnet 3.7 stored, such as money or map position, can be read off the screen every turn. Strategies, plans and tested rules exist only if the agent works them out, and vanish unless written down. Fable 5’s global.md acted as a dashboard with the current goal, a plan for gyms and its own rules for using memory. Opus 5.5, the post adds, kept a similarly small folder, rewrote it as it played and beat the game. These are single runs, so they illustrate behaviour rather than establish a rate. The principle transfers well: memory should hold what the environment will not re-supply.

Dreaming: checking notes against the transcript

A note written in the moment can be wrong from the start or drift out of date, and a later session will trust it. Dreaming addresses this by re-reading the original transcripts, which act as ground truth, and testing the notes against them.

The post’s demonstration comes from Mt. Moon, a cave in Pokémon Red with its entrance on the west and its exit on the east, and a one-way ledge near the entrance that drops the player back onto the route they came from. Claude used the Pokémon Center as a landmark and wrote, incorrectly, that it was on the east side. Leaving it, Claude announced “Mt Moon is behind me”, updated its notes to “Mt Moon DONE”, walked off the ledge and concluded it had “overshot far west”. Anthropic then ran dreaming over the memory folder holding the wrong note. Claude checked the note against the session transcript, caught the error and rewrote it.

Three runs followed, according to the post’s Figure 8, tracked over 3,000 cumulative actions. With the corrected note, Claude went back into the cave and reached Cerulean City at action 1,935. With the uncorrected note it dropped back onto the earlier route three times, wrote “I’m going to stop rather than keep looping”, was told by the harness’s automatic reply to continue, and retreated to Pewter City without reaching Cerulean. The run with no memory also never reached Cerulean. That is one trajectory per condition. It shows the mechanism working once in a setting where one wrong landmark had large consequences.

What the Dreams API actually does

Anthropic ships this as a product feature. The Managed Agents Dreams documentation describes a dream as an asynchronous job that takes an existing memory store and 1 to 100 past sessions, then writes a new, reorganised store: duplicates merged, stale or contradicted entries replaced with the latest value, new insights surfaced. The input store is never modified, so the output can be reviewed and either attached to future sessions or deleted. Dreams typically take minutes to a few hours, depending on the number of transcripts, and are billed at standard token rates for the chosen model.

Three details from the documentation shape how teams should use it. First, the optional instructions field steers synthesis, such as a focus area or content to preserve; the documentation warns that line-level directives like “change sentence X to Y” generally produce no change, and that targeted edits belong in the Memory Stores API. Second, the underlying pipeline runs as a session whose events can be streamed and whose transcript is archived, so the dream itself is auditable. Third, as of 12 November 2026 the feature is a research preview on listed models, from Claude Sonnet 4.6 and Opus 4.7 up to Claude Fable 5.2, available by request and behind the managed-agents-2026-04-01 and dreaming-2026-04-21 beta headers, and Managed Agents sessions are not eligible for zero data retention or HIPAA.

The dreaming cookbook shows a do-it-yourself version that makes the mechanism concrete. A lead agent on Claude Sonnet 5.5 starts a workflow but never reads transcripts or edits memory itself. One analyzer per transcript, on Claude Haiku 5.5, follows three steps: verify existing claims against the transcript, downgrading confident claims where the transcript shows uncertainty; enrich with exact identifiers, commands, staleness notes and process observations; and organise into small linked files with frontmatter and an _index.md. A single organizer then tidies the store. Where two entries conflict and one is not plainly the later correction, the organizer is told to keep both and mark the conflict.

The cookbook’s reported costs, from its authors’ runs at list price, give a sense of scale. Eleven example transcripts totalling 283 KB cost $0.36 and took about two and a half minutes. Fifty long transcripts, about 12 MB of text, cost about $8 and took about ten minutes with the default cost-saving settings, against about $10 and nine minutes without them, across 60 and 30 dreams respectively. The $0.36 figure includes the session’s running time, which the cookbook prices at $0.08 an hour; it does not say whether the $8 figure does.

One design difference between the two routes deserves attention. The Dreams API writes a new store and leaves the input intact, which creates a natural review gate. The cookbook’s nightly script, run from cron at 1 AM, updates the same store in place, and the cookbook states plainly that a nightly run has no review by default; to review first, run by hand into a new store. A team choosing the in-place route is choosing to let a bad night reach the agent the next morning.

Dreaming needs transcripts to exist

The check is only as good as the record. The cookbook says so directly: “Memory is only as good as the transcripts.” That creates an operational dependency that is easy to miss. Claude Code, for example, deletes old session transcripts after its cleanupPeriodDays retention period while keeping memory files. A team that wants periodic consolidation has to keep transcripts at least as long as the interval between passes, and has to reconcile that with whatever its data-retention policy requires. The two requirements pull in opposite directions, and the memory design should state which one wins.

The wiki result, with its conditions

The post’s third use of dreaming is building new representations, specifically a wiki in the sense of Andrej Karpathy’s April 2026 gist: pages written and maintained by the model, each gathering what is known about one subject and linking to related notes. Links turn the memory into a map the agent can traverse rather than a pile it has to search.

Anthropic tested this on internal documents from Stainless, a software company it says it acquired in May: about 350,000 files, roughly 420 million tokens. It wrote 25 evaluation questions and gave Claude a search tool. Over 128 sessions, Opus 5 agents explored the files, wrote or corrected linked pages, merged duplicates and checked claims against sources, coordinating through a shared log so that each session built on earlier ones. The figure’s horizontal axis is labelled in dreaming tokens, from 2 million to 128 million, while the text counts sessions from two to 128. The example wiki grew from 103 pages and 766 links after two sessions to 222 pages and 12,893 links after 128.

Condition (Opus 5 agents, 25 questions)	Share of graded criteria met	How it changed as the wiki grew
Wiki only	13% rising to 48%	Large gain, but never reached search alone
Search tool only	53%	Flat, since nothing was built
Wiki plus search tool	54% rising to 61%	About one point above search alone at the start, eight at the end

Source: Anthropic, Figure 10 of the 6 November post. The denominator is graded criteria across 25 questions; the number of criteria is not stated.

Read with its conditions, the result supports a specific claim. A wiki built over many dreaming sessions, used alongside search, improved criteria met by eight percentage points over search alone on one corpus and one 25-question set. The wiki did not replace search: on its own it peaked at 48%, below the search baseline. The post also says that using search and the wiki saved about 20,000 tokens per question. That saving is per answer; the cost of the 128 build sessions sits on the other side of the ledger and the post does not amortise it. The denominator is criteria, not questions, so “61%” is not “15 of 25 questions answered correctly”.

Where the wiki helped and where it did not

The legal experiments locate the benefit. Harvey LAB is an MIT-licensed legal agent benchmark of tasks with documents and grading rubrics. Anthropic used it alongside a collection of documents about a merger: Claude built wikis from the documents, then answered questions about the merger or wrote LAB briefs, both from the wiki and from direct file search. On 24 questions about the merger, more than half of which needed information from several documents and many of which needed judgement or arithmetic, Claude met 87% of criteria with the wiki against 73% with search alone, on the items the post highlights.

On a LAB task whose 57 criteria could mostly be met by text search in a single document, usually a deal overview memo, the wiki showed no clear gain. On another LAB task the wiki outgrew its sources: ten documents with 115 KB of text produced 68 pages, 255 links and 203 KB, 1.77 times the corpus. The post compares it to the map in Borges’s “On Exactitude in Science”, drawn as large as the empire it described. A wiki that is bigger than its sources has stopped abstracting and become a second corpus to search.

Anthropic’s knowledge-wiki quickstart adds vendor-reported economics for a different setup. On its merger example, its README says, a small model answering from the wiki comes within a point of a larger model searching the raw documents, at about one fifteenth of the price per answer, and the wiki pays for itself after about 240 questions. It also says the recorded build took 23 minutes and cost about $16 at list price. These are separate claims from the research post, on a separate pipeline, and the README does not show their methodology on the page.

The combined guidance is narrower than “build a wiki”. A wiki earns its keep when questions repeat, the corpus changes slowly, and answers need facts joined across documents. It adds little when one document holds the answer and search can find it. It becomes a liability when nothing constrains its scope.

Concurrent writes are where memory quietly loses facts

The most transferable finding in the post concerns coordination rather than intelligence. One LAB task simulates an acquisition with a set of contracts, and the brief is graded on whether it describes the contract terms correctly. Anthropic began with basic wiki instructions that did not say how the wiki would be used. While the wiki was built, several agents wrote to one shared table of contract terms at the same time. The figure shows four agents writing to a single page, provisions.md, with one agent’s save erasing another’s lines.

The brief generated from that wiki included 41 of the 57 graded facts, or 72%. Anthropic found the shared table summarised terms poorly and missed some altogether “because agents had overwritten one another’s work”. It then ran a loop in which Claude reflected on its failures, proposed instruction changes and rebuilt the wiki. The new instructions gave each contract its own page, written by a single agent, quoting terms word for word. The brief from that wiki met all 57 criteria.

That result bundles three changes: one writer per page, verbatim quotation instead of summary, and instructions that named contract terms as the point of the wiki. The post does not isolate them, so it cannot say how much of the 16-fact gap came from overwrites alone. The direction is still clear, and Anthropic’s own quickstart supplies a second data point from the other side. Its README accepts shared pages deliberately and reports the cost: “about 5% of the lines filed to the busiest entity page lose content.” The stated reason is that a shared page brings figures from different documents together, where agents can flag disagreements. The two positions are consistent once the content type is named. Verbatim terms that will be graded line by line need single ownership. Cross-document synthesis may tolerate some loss in exchange for putting conflicting figures side by side.

What the platforms provide against lost writes

Anthropic’s documentation describes several mechanisms, and they behave differently enough that teams should know which one they are relying on.

• Conditional updates through the API. The Memory Stores API accepts a content_sha256 precondition on updates. The write applies only if the stored content still matches the hash the client read; on mismatch the client re-reads and retries. This is optimistic concurrency, and it protects programmatic writers.
• Silent resolution on self-hosted sandboxes. On self-hosted sandboxes, each store is a local copy that a worker syncs at most once per interval, 15 seconds by default. Conflicts resolve in favour of the store: the worker overwrites the local file and logs a warning, and “no error reaches the agent.” An agent’s edit can therefore succeed and disappear without the agent knowing.
• Read-back verification by prompt. The dreaming cookbook relies on instructions rather than locks. Analyzers working in parallel are told to re-read a file right before changing it, to use targeted edits on shared indexes rather than rewriting them, and to read every file back after writing. If another agent’s write won, the analyzer merges both sets of facts and writes again until its content is present.
• Structural rules. Cookbook analyzers must “link rather than merge” and may not rename or move files; reorganisation is reserved for an organizer whose prompt states that “No other agent is writing while you run.” Retired files become one-line MOVED TO [[slug]] stubs instead of disappearing mid-run.
• Shared directories by default. Claude Code’s auto memory lives in one directory per git repository, shared across all worktrees and subdirectories. Parallel sessions in different worktrees of the same repository therefore write the same memory folder. The memory documentation we read does not describe how simultaneous writes from such sessions are reconciled.

A writer-ownership pattern for memory

Combining the post’s result with those mechanisms gives a small set of rules. They are our synthesis, not an Anthropic specification.

Memory artefact	Suggested writer policy	Why
Per-entity pages holding exact terms, figures or commands	One owning agent per page; quote, do not summarise	The contract experiment lost 16 of 57 facts with shared writers
Shared index or table of contents	Append or targeted edit only; never a full rewrite during parallel work	Full rewrites are how one save erases another's lines
Cross-document synthesis pages	Shared writers acceptable if conflicts are marked, with loss measured	The quickstart accepts about 5% line loss to keep disagreements visible
Whole-store reorganisation (merge, rename, prune)	One organizer, run alone, after writers finish	Moves and merges under concurrency make losses hard to detect
Programmatic edits from your own services	Conditional update with a content hash	Turns a silent overwrite into a retry

Keep the always-loaded layer small

Dreaming can also promote notes to the top of the hierarchy, where the harness injects them into every new session. The agent then does not need to search for them, or even know there is something to search for. The post treats this as the layer most in need of restraint. Injected notes use tokens in every session, an incorrect one is carried into every session, and loading a note does not guarantee the model follows it. Much of dreaming’s work here, the post says, is keeping the top layer small by moving detail down and leaving links behind.

Claude Code’s auto memory is the shipped example. It loads only the first 200 lines or 25 KB of MEMORY.md, whichever comes first, at the start of each conversation; topic files load on demand. When Claude writes to MEMORY.md, Claude Code checks the file against those limits and reminds Claude to keep one line per entry, move detail into topic files and merge or drop stale entries. If the file goes over, the write succeeds but Claude Code tells Claude to rewrite the index, because everything past the limit is dropped on the next load. The same documentation warns that longer instruction files “consume more context and reduce adherence.”

The injected layer is also the security boundary. The Managed Agents memory documentation warns that stores attach read-write by default, and that if an agent processes untrusted input, a successful prompt injection “could write malicious content into the store. Later sessions then read that content as trusted memory.” It recommends read_only for reference material and any store the agent does not need to modify. The cookbook adds that a malicious transcript can change what a dreamed store says, and that loading store text into a system prompt lets it steer every session; its analyzers run with no shell or web access and an empty network allowlist. Persistent injection through memory is not hypothetical: our prompt-injection explainer documents a 2024 case in which injected instructions were written into a chatbot’s long-term memory and carried into later chats. Consolidation widens the path, because dreaming reads transcripts that may contain hostile tool output and writes to the layer every later session trusts.

Worked example: a nightly dream for a hypothetical support fleet

To make the decisions concrete, consider a hypothetical team. Every input here is invented for illustration; none of it is a deployment we observed or tested.

The team runs a support agent on Managed Agents that handles around 50 long sessions a day against product documentation that changes monthly. Four instances sometimes run at once. Each session writes notes into one read-write store. After a month, the store has duplicate notes about the same billing edge case, two contradictory notes about a refund window, and a MEMORY.md-style index that has grown past what anyone wants loaded into every session.

A design that follows the evidence above would split memory into two stores. Sessions get a small read-write store for new observations and a larger read-only store of consolidated knowledge. Each night, a dream reads the previous day’s sessions and the read-write store and produces a new consolidated store, which a person or an automated check compares with the current one before sessions switch to it. The dream’s instructions state purpose, not recording rules: “consolidate durable facts about product behaviour and customer-facing policy, with the date and the session that established each”. The organizer pass keeps one page per policy, quotes policy text verbatim, and marks the refund-window disagreement as a conflict rather than picking a winner.

The cost arithmetic uses only the cookbook’s reported figure. Fifty long transcripts totalling about 12 MB cost its authors about $8 per dream at list price with the default settings. If the hypothetical team’s transcripts were similar in size, 30 nightly dreams would cost roughly $240 a month, plus session runtime at $0.08 an hour if the cookbook’s figure leaves it out. That is our arithmetic on a vendor-reported run, and the real number moves with transcript length, model choice and pricing. The comparison the team should make is against the cost of agents rediscovering the same facts, which only its own logs can supply.

Two operational decisions remain. Transcript retention must exceed one day, or the nightly pass has nothing to read. And the team must decide whether a failed or skipped night matters: the cookbook notes that a session still running at 1 AM is skipped, and later nights do not look back for it.

Evidence worksheet: what each result establishes

The table below is our assessment of each experiment in the post. The “who measured” column is the same for every row, which is itself the most important line.

Experiment	Conditions reported	What it supports	What it does not establish	Who measured
CL-Bench database task	Six Claude models; fresh session per question; memory directory only; running mean over 30 questions	Newer models gain substantially from an unconstrained memory folder	Variance, number of runs, transfer to other CL-Bench tasks	Anthropic
"Record only failures" rule	One rule per test; change in memory gain per model	Prescriptive recording rules can erase most of the benefit for strong models	Whether other rules help; how wording affects the result	Anthropic
Pokémon salience	One run each, Sonnet 3.7 vs Fable 5, about 10,000 steps	Storing what the environment re-supplies wastes effort	A rate or effect size; model change is confounded with memory style	Anthropic
Mt. Moon correction	One trajectory per condition over 3,000 actions	Checking a note against the transcript can catch a consequential error	How often dreaming finds errors, or introduces new ones	Anthropic
Stainless wiki	Opus 5; 350,000 files; 25 questions; up to 128 sessions	Wiki plus search beat search alone by eight points of criteria met at the end	Generality beyond one corpus; build cost amortisation; criteria count	Anthropic
Merger questions and LAB briefs	24 merger questions, more than half multi-document; LAB tasks graded by rubric	Wikis help most when answers join several documents	Results across the full LAB benchmark	Anthropic
Shared contract table	Four agents, one page, 57 graded facts	Concurrent writers to one page lost facts; single ownership with verbatim quotes kept all	Which of three simultaneous changes caused the gain	Anthropic

What remains unknown, and what would change the conclusion

The central uncertainty is statistical. Most experiments in the post are single runs or small question sets, reported without error bars, on Anthropic’s models, with Anthropic choosing the tasks. The Stainless corpus is internal and cannot be checked by anyone else. The direction of several findings is plausible and consistent with how databases and wikis behave for people, but the magnitudes should not be quoted as properties of “memory” in general. An independent replication of the wiki-plus-search comparison on a public corpus, with variance across runs and the build cost reported in the same units as the per-question savings, would do more than any additional vendor example.

The second uncertainty is error introduction. The post shows dreaming fixing a wrong note. It does not report how often a dreaming pass makes a correct note wrong, drops a fact, or hardens an uncertain claim into a confident one. The cookbook’s instruction to downgrade over-confident claims suggests Anthropic considers this a live risk. A measured false-correction rate would change how much review a dreamed store needs before it goes live.

The post raises three open questions itself. When should memory be written: in the moment, which captures salience at the source but distracts from the task, or in the background, which spares the agent’s attention but may not be available straight away? How should memory be kept current, given that checking every note continuously may not be practical and dreaming could instead focus on information likely to change, or run at a cadence tied to how often memories are accessed? And should transcript search be the foundation, with representations such as wikis layered on top only where they earn their maintenance cost? The wiki results lean towards the last view: on the Stainless corpus search alone beat the wiki alone, and on the single-document LAB task the wiki added no clear gain over search. The merger questions, where the wiki won, are the exception that shows where layering pays.

Finally, the experiments concern Claude models running in Anthropic’s harnesses. How much of the “tell it the purpose” result depends on model training is not separable from these data. The steep gradient from Sonnet 4.6 to Sonnet 5 suggests a large part does, which means a team using older or different models may need the more prescriptive prompting that helped Sonnet 4.6.

Proposed tests for your own memory system

These are proposed measurements, not results from a GenAI Brief test.

1. Purpose versus rules. Run your agent on a repeated task with a memory folder under two prompts, one stating only what memory is for and one adding a recording rule. Compare gains over a no-memory baseline across several runs.
2. Lost-write rate. Run your real number of parallel writers against a shared index for a day and count lines that were written and later absent. Compare with single-writer pages.
3. Dreaming error rate. Seed a store with known-wrong and known-right notes, run a consolidation pass over transcripts that contradict only the wrong ones, and count corrections, false corrections and dropped facts.
4. Wiki against search at equal budget. On your own corpus, compare search alone with wiki plus search on questions that need one document and questions that need several, and include build tokens in the cost.

What to do with this

For a team building agents with file-based memory today, the evidence supports a short list. State what memory is for and let a current model decide what to record; add prescriptive reading and testing steps only for older models that skip them. Keep transcripts long enough to check notes against them, and run consolidation as a separate pass, preferably into a new store that can be reviewed before sessions switch. Give each page holding exact facts a single writer, use conditional updates where the platform offers them, and run reorganisation alone. Cap the always-loaded layer hard and treat it as the place an injected instruction would do the most damage.

The wiki is an optimisation to add after search works, aimed at repeated questions that join several documents, with its growth bounded by instructions. The “dreaming” label is borrowed from sleep research, but the work it names is ordinary: re-read the record, fix the notes, and keep the index short. Anthropic’s experiments make the case that this housekeeping, more than a cleverer storage format, is what decides whether an agent’s memory helps or misleads it. For how the surrounding loop loads tools, context and files into each step, see our explainer on what an agent harness is.