Claude

Agents that remember

Every time you close a session, your agent loses everything it learned. In this workshop, you'll wire persistent memory onto a Claude agent and then use Dreaming to batch-consolidate past transcripts into structured recall. By the end of the 45 minutes, you'll have an agent that remembers across sessions and you'll know how to set this up for your own agents.

May 23, 2026·28m·Watch on YouTube ↗

📖 CHAPTERS

1. 1

   Why agents need memory: sessions are isolated by default

   Kevin frames the core limitation of today’s managed agents: each session is isolated, so information doesn’t persist across runs. He previews the solution stack—memory stores for persistence and “Dreaming” to refine memory over time—plus demos via CLI and Console.

2. 2

   Core primitives recap: agent, environment, session, plus memory store and dream

   The talk situates memory within Claude Managed Agents primitives. Kevin defines a memory store as a persistent, filesystem-like resource attached to sessions, and a dream as a background process that distills, checks, and organizes memories from prior transcripts.

3. 3

   Repo setup and baseline data: bootstrapping agent, environment, prior sessions

   Kevin switches to the workshop repository and explains the bootstrap script that seeds the environment. It creates an agent, an environment, and sample prior sessions (e.g., keynote/workshop notes) to support the upcoming tests.

4. 4

   Base case demo: writing info in one session without memory

   He creates a session via CLI and sends it new information (notes/keywords and a URL). In Console, the agent responds politely but does not persist anything beyond the session.

5. 5

   Base case retest: a new session can’t recall prior details

   Kevin creates a second session and asks about the previously shared information. As expected, the agent cannot access that past context and can only offer generic help.

6. 6

   Memory stores concept: persistent filesystem mounted into sessions

   Kevin introduces memory stores as the solution for cross-session continuity. He emphasizes the power of mounting memory as a filesystem—enabling natural agent behaviors like searching with grep and exploring directories.

7. 7

   Creating a memory store and exploring it in Console

   He creates a memory store via CLI and shows where it appears in Console under Managed Agents → Memory Stores. The Console provides a filesystem viewer and supports manually adding or editing memory files.

8. 8

   Mounting memory on a session: prompts and access controls

   Kevin demonstrates attaching a memory store to a session request. He highlights configuration options: a steering prompt to guide what to store and an access mode (read/write by default, optionally read-only).

9. 9

   Memory-enabled write & recall: agent saves notes and later retrieves them

   Repeating the earlier test, the agent now checks the memory store, then writes the new information into it (e.g., a sessions.md file). In a later session mounted to the same store, the agent uses search (grep) to find and answer based on saved notes.

10. 10

    Inspecting and managing memory files: listing, versioning, and edits

    Kevin shows that memory store contents can be listed and inspected via CLI, and that files are versioned as changes occur. In Console, users can view directory structures, edit files directly, and add new memories as needed.

11. 11

    Why Dreaming: preventing unbounded, stale, or duplicated memory growth

    As agents write more, memory stores can become noisy, redundant, and outdated. Dreaming is introduced as an asynchronous multi-agent batch process to fact-check, enrich, and reorganize memory into a cleaner output store.

12. 12

    Creating and monitoring a Dream job: inputs, models, and observability

    Kevin launches a Dream job specifying a model (Opus 4.7 or Sonnet 4.6), an input memory store, and a set of session transcripts. He shows Console monitoring: status, token counts, and deep observability by inspecting the Dream’s underlying session and sub-agent activity.

13. 13

    Dream outputs: non-destructive cloning, diffs, indexes, and enriched files

    Dreaming completes by cloning the input store into an output store and writing improvements there—leaving the original untouched. Console displays a diff: new index files, improved structure/metadata, and additional details (e.g., logistics/schedules) that make retrieval more efficient.

14. 14

    Using the dreamed memory store in new sessions + operational considerations

    Kevin retrieves the output memory store ID and mounts it in a new session to demonstrate higher-quality recall and richer summaries. He closes with the “three-layer” mental model (sessions → memory stores → dreaming), plus Q&A on token usage, caching, and cost controls (model choice, prompts, scheduling).