Most agents start every conversation from zero. This walkthrough shows how memory stores and dreaming let them carry knowledge across sessions — and keep it clean over time.
On Claude Managed Agents, you usually run one session at a time. A session is a single, ephemeral conversation thread. By default, nothing carries over: what you tell one session is invisible to the next.
Try it. Tell the left session a fact, then ask the right session to recall it.
Two isolated sessions
session · write_test
Empty thread
session · recall_test
Empty thread
The second agent has no access to anything the first one learned. No information transferred between sessions — this is the wall we need to break through.
Just like people, agents need somewhere to store what they learn and read it back later. That shared place is a memory store.
The fix
A memory store the agent can read & write
A memory store is a persistent, file-system-like store. You create as many as you like and decide the boundaries — per user, per workspace, per org. It mounts onto a session's container as a real filesystem.
Mounting it as a filesystem is the clever part: the agent gets powerful, familiar tools. It can ls and bash to explore, grep for keywords, and read or write files — far more useful than a flat blob.
Two knobs when you mount it. A prompt steers what the agent should remember (e.g. "focus on investment notes"). And access defaults to read-write but can be set read-only — the session can read memory but never change it.
# mount a memory store on a new session$ create session --memory-store-idcwc_memory \
--memory-prompt"remember talk takeaways & links" \
--accessread-write# or: read-only
Now repeat the same test — but this time both sessions share one store. Watch the agent check memory first, write to it, then recall from it in a later session.
Shared memory store
session · write (rw)
Empty thread
session · recall (rw)
Empty thread
cwc_memory · file viewer · v0
memory store is empty
The recall session grepped the store, found sessions.md, and answered using knowledge it was never directly told. Memory transferred across sessions.
Memory files are also versioned — every edit creates a new version. You can list files, inspect them in a console viewer, hand-edit them, or add memories manually.
The upkeep
Dreaming keeps memory from rotting
Left alone, agents dump into the store. It grows unbounded, fills with duplicates, and goes stale. Dreaming is an async batch job that fixes this. You give it an input memory store plus a batch of session transcripts; it runs a multi-agent harness over them.
An orchestrator spawns one sub-agent per session. Each sub-agent fact-checks, enriches with dates and identifiers, then the system consolidates duplicates and organizes files. It's exhaustive by design — Claude reads everything so it misses nothing.
$ create dream --modelopus-4.7# or sonnet-4.6 (cheaper)--memory-storecwc_memory \
--sessions[s_01, s_02, s_03, s_04] \
--instructions"backfill dates; keep an index"
Press play to run a dream. The orchestrator kicks off sub-agents, the token counter climbs, then it writes results to a fresh output store.
Dream harness · live
⊹ Orchestrator idle
sub-agent
session 01
sub-agent
session 02
sub-agent
session 03
sub-agent
session 04
tokens processed0
input store (untouched)
sessions.md
output store (new clone)
+ index.md <slugs>
+ event_logistics.md
+ day_two_schedule.md
~ sessions.md (enriched + slug)
Done. Dreaming cloned your input store (non-destructive), added an index.md for fast lookup, backfilled an event schedule and resource links, and re-slugged the original file. Future sessions read this richer output store.
Why so many tokens? Exhaustive by design means high usage — but ~95% of it hits the prompt cache, and discounts (batch-style scheduling), model swaps, and token budgets bring the cost down.
It runs asynchronously for minutes to hours — never live while agents work. Because it's built on the same session primitives, you can click into the dream's own session and watch exactly what it's doing.
The mental model
Three composable layers
Everything stacks. Each layer adds capability without replacing the one below. Tap each to expand.
tap
01Session
One isolated agent run — a single conversation, typically ephemeral.
On its own, a session can't see the past or pass anything forward. It's the atomic unit of work, but it forgets the moment it ends.
tap
02Memory Store
Connects information across sessions — a shared filesystem they read and write.
Decide per use case which sessions mount it, and whether they get read-write or read-only access. Versioned, inspectable, hand-editable.
tap
03Dreaming
Organizes, enriches, and de-stales the store over time so it never blows up.
A second set of agents whose only job is improving memory for future use: dedupe, fact-check, backfill, index. Non-destructive — always writes a fresh output store you can review.
Recap
What you learned
Agents are isolated by defaultMemory stores = shared filesystemMounted with prompt + accessMemory grows messy & staleDreaming = async multi-agent cleanupOne sub-agent per sessionNon-destructive output storeScale stays manageable
The takeaway: as you scale up sessions and the information flowing through them, memory stays at a reasonable, organized, up-to-date level instead of exploding. Memory makes agents remember; dreaming keeps that memory worth reading.
Built as a teaching aid · concepts & terminology from Anthropic's "Agents that remember" workshop