Anthropic's 4-Layer Agent Memory Design: Session Records, Notes, Wiki & Dreaming

Four-Layer Memory

Anthropic's November 6 research explains what Claude can leave behind after a task for the next session to use. The design uses four layers:

Session Records : Raw history of every step—what was queried, what tools returned. Later you can check whether a query hit test or production by reviewing the original record.

Notes : Extracted findings worth reusing, e.g., "Sync interface address is read from deployment config via User Center SDK." Next time you can skip several files.

Wiki : Links clues from multiple sessions into interconnected pages. One session found the nightly task, another found which config the SDK reads; linking them lets the next session follow the chain.

Startup Context : Only the few lines the agent sees at startup, e.g., "Query nightly sync, first read migration notes." Details are loaded on demand.

In the nightly sync example, the reusable asset is the path from task code to config. The concrete address with date and environment can be stored for later comparison. When asked "What is the current sync address?", retracing that path saves re-discovering dependencies.

Here "memory" means context stored outside the session for later reading, without changing model weights. When building your own agent, you can organize these layers as files: raw records, notes, Wiki pages, and a startup index. Dreaming handles review and reorganization; how files are read and how organized memory is passed to the next session differs between Claude Code and Managed Agents.

Dreaming Correction

Suppose on Tuesday Claude verified the new interface in test and noted "Sync task migration complete." On Wednesday a new session checks production config and finds the nightly task still points to the old interface. Both queries were correct; the bug was the Tuesday note missing "test environment."

Dreaming reviews both sessions: Tuesday's tool result shows new interface success in test; Wednesday's production config shows old address. The note becomes two sentences:

Tuesday: test environment passed new interface. Wednesday: production config still points to old interface.

Lance Martin describes Dreaming as an offline computation: review experience, correct errors, take notes, reorganize memory. Old records only verify what happened then; whether production switched after Wednesday requires a fresh query.

Writing notes during the task distracts attention. Dreaming moves review and reorganization outside the task, allowing cross-session comparison. This extra computation may not immediately enter the ongoing session.

Notes can be corrected because the original queries are still retrievable. Claude Code clears local sessions on a schedule; auto-memory files survive that cleanup. Months later, if only "migration complete" remains, you won't know what was queried. Date, environment, and config location help the next query; to verify the exact past result you must keep the corresponding evidence.

Wiki Connects Clues

After correcting notes, the relationships among task, SDK, and config must be linked. The interface address lives in deployment config; the nightly task calls it via User Center SDK. Searching the old address may find the config but not reveal which task uses it. Scattered across three places, a Wiki page can capture the relationship in one place.

A migration page might contain:

Nightly sync task calls User Center SDK; SDK reads sync address from deployment config. When verifying production switch, check the config actually loaded by the cron task.

Task name, SDK, and config each link back to original records. Next time starting from "sync task error" you can reach the interface end. If you only need where an env var lives, direct code search may be faster.

The more frequently a call chain is queried, the more worth it to pre-organize.

Anthropic evaluated on Stainless's ~350k internal documents with 25 questions. Wiki built from 128 sessions. Wiki alone satisfied 48% of scoring items; search alone 53%; combined 61%, using ~20k fewer tokens per question than search alone.

The 48% grew incrementally: as build sessions increased from 2 to 128, Wiki-only satisfaction rose from 13% to 48%. The 128 build sessions are a separate cost.

On legal documents, Wiki helped notably on questions requiring cross-document synthesis; on single-document tasks it showed no advantage. In our example, whether to create a page depends on whether the task-SDK-config relationships will be reused.

With multiple agents writing, page division matters. In a contract experiment, multiple agents writing to the same table overwrote each other and summaries missed clauses—final brief covered only 41 of 57 facts. Switching to one page per contract, one agent per page, preserving original clause text retained all 57 facts. Page division and clause preservation changed together; the experiment cannot separate their individual contributions.

Contracts need verbatim clauses; interface migrations need environment, config location, and dependency relations. How granular a page should be depends on what questions it must answer next time. For the sync task, caller and callee each keep their investigated records; the migration page links to them so progress on both sides can be verified later.

How New Sessions Read

After writing the migration page, the next session must know where to look. An index entry "sync migration" may not trigger on "nightly sync error again." The index should use names users actually ask: "Nightly sync, User Center SDK, interface migration: see sync-migration.md." Wednesday's address goes in the page, loaded on demand.

Providing the index at startup lets Claude know a clue exists before deciding what to search. But the index consumes context every time, and its errors can repeat. Keeping details in topic pages and reading them when needed avoids loading entire old records.

Claude Code's auto-memory works this way. Enabled, a new session reads the first 200 lines or 25 KB of MEMORY.md, whichever limit hits first. Topic files are read on demand. If the migration page entry is at line 210, opening the file shows it, but the new session at startup does not see that line.

In September we traced Claude Code's memory system: file stores it, session reads it, answer uses it—three separate steps. Dreaming completes the first part: how the next session's reading material is organized from past experience.

Managed Agents separate "organize" and "adopt." The Dreams API preview writes results to a new library; the original library is untouched. A run may produce a new library; failure or cancellation may leave partial content. Check completed to know if organization finished.

After completion, the application can inspect changed files before deciding which library the next session mounts. Completion does not automatically switch the memory library for the application. If notes were corrected but Claude still says "already migrated," check: which library is the new session mounted? Which file did the session event actually read? If the corrected note was read, then verify whether it retained the test/production distinction and whether it used tools to re-check current config.

In Claude Code, open the auto-memory directory via /memory, pick an old experience with a topic page, start a new session, ask the usual question, and observe whether it finds the page on its own.

Practical Inspiration

Apply this to your own agent with a small trial on the nightly sync task: save investigated results, give the new session a reading entry point, then observe how it queries with the same question.

1. Keep a Sourced Task Note

Organize files like this, preserving relevant tool inputs and results in raw records:

memory/INDEX.md          # Startup index
memory/sync-migration.md # Sync task investigation notes
records/sync-tue.md      # Tuesday test environment query records
records/sync-wed.md      # Wednesday production environment query records

In sync-migration.md, besides task→SDK→config relationships, record exact code locations, config locations, query timestamps, and environments , with paths to corresponding raw records. Keep Tuesday test pass and Wednesday production old address separate. For "which interface now?" note which config to re-query.

2. Hook the Index into New Session Startup

In this custom setup, the application loads memory/INDEX.md on each session creation and places it in the startup context. Provide the agent two tool types: read notes/raw records by path, and query current config for a given environment. The index might read:

Nightly user data sync, User Center SDK, interface migration: see memory/sync-migration.md .

This INDEX.md is loaded by the application; Claude Code's auto-memory entry remains MEMORY.md as described. Log which file was actually read and which environment was queried to distinguish between not finding the note, not reading it, and reading it but using the wrong condition.

3. Check Three Scenarios to Verify Reading and Querying

Fix the question: "Which interface does the test environment nightly sync use now?" Each trial starts a fresh session; keep model, config, and tools identical; only change whether memory is provided.

No memory : Give only the question and same tools. Observe: can it find the correct task? How many tool calls?

With memory : Add index and task note. Observe: does it follow the note to config? Reduce repeated searches?

After config change : Keep old note, change test config address. Observe: does it re-query config, answer new value, cite source?

First verify answer and source against actual config, then see which repeated lookups were saved in tool calls. If it still returns the old value, trace through file reads and config query logs to locate the cause. Once all three pass, keep this question as a regression test; re-run when updating notes or adjusting reading logic. Whether it consistently saves effort must be observed across more real tasks.

As task notes accumulate, build interlinked Wiki pages by task, SDK, config. For correction, have the organization process read old notes and raw records together, list conflicts, evidence, and proposed changes as a candidate version. Review changes, re-run the test question, then let subsequent sessions read the new version. This gives Dreaming's organization results a clear adoption step.

Yesterday's effort retained, the next session can continue along the investigated path. If someone asks "Can the old interface be deprecated today?", memory reminds the agent there's a nightly sync task to verify. Next you must check where the production task points now and whether recent requests still hit the old interface. The note tells it where to look; whether it can be deprecated depends on today's config and traffic.

References

Anthropic "The components of agent memory" (https://www.anthropic.com/research/components-of-agent-memory)

Lance Martin on X about Dreaming (https://x.com/RLanceMartin/status/2118815962573291545)

Claude Platform "Dreams" (https://platform.claude.com/docs/en/managed-agents/dreams)

Claude Platform "Using agent memory" (https://platform.claude.com/docs/en/managed-agents/memory)

Claude Code "How Claude remembers your project" (https://code.claude.com/docs/en/memory)

Andrej Karpathy's LLM Wiki draft (https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)

Previous article: Anthropic lets Claude "dream" to correct a wrong note

Previous article: Possibly the most systematic AI Agents era Memory survey

Previous article: Quick start: Karpathy's LLM Wiki, what extra layer over traditional KB?

Previous article: Why Claude Code long tasks don't drift: runtime design from compression, memory to continuation

Previous article: From RAG, MCP, Skills to Ontology First: building enterprise agents

Previous article: Output ≠ task completion: the step agents most often miss