CHAPTERS
- 0:19 – 1:20
Why agents need persistent memory across sessions
Kevin frames the core limitation of today’s managed-agent workflows: sessions are isolated, so agents can’t carry knowledge forward. He previews the solution—Memory Stores—and an improvement loop called Dreaming, plus how everything shows up in CLI and Console.
- •Baseline problem: sessions are isolated and don’t transfer context
- •Goal: let agents read/write knowledge across multiple sessions
- •Overview of Memory Stores (persistence) and Dreaming (improvement over time)
- •CLI + Console walkthrough planned
- 1:20 – 1:50
Core concepts: sessions, Memory Stores, and Dreaming jobs
The workshop adds two primitives to the agent/environment/session model: a Memory Store and a Dream. Kevin explains Memory Stores as a persistent, filesystem-like resource, and Dreaming as an asynchronous process that distills and cleans memory using prior session transcripts.
- •Memory Store attaches to sessions and persists across sessions
- •Filesystem-like interface enables powerful agent tooling (read/write/search)
- •Dreaming runs asynchronously over a memory store + session transcripts
- •Dreaming tasks include fact-checking, consolidation, deduplication, and organization
- 1:50 – 3:22
Workshop setup: repo bootstrap and seeded sessions
Kevin points attendees to the workshop repository and describes what the bootstrap script sets up. The environment includes a seed agent, environment, and prior sessions (e.g., keynotes/workshops) to use in later demos.
- •Download workshop repo and run bootstrap
- •Bootstrap creates an agent, an environment, and sample prior sessions
- •Seed data includes conference notes/sessions to reference later
- •Attendees can follow along via CLI and Console
- 3:22 – 5:16
Baseline demo (no memory): tell the agent something in Session A
Using the CLI, Kevin creates a session without any memory store attached and sends a message containing notes about a talk (keywords and a link). In Console, the agent responds politely but does not persist anything for future sessions.
- •Create a new session (no memory attached) via CLI
- •Send talk notes (keywords like multi-agent orchestration, outcomes, memory)
- •Console shows the session and message event flow
- •Agent acknowledges information but doesn’t store it for later reuse
- 5:16 – 6:20
Baseline demo (no memory): Session B fails to recall prior info
Kevin creates a second session and asks for details he previously provided. The agent can’t access the earlier session’s content, illustrating the isolation problem and motivating persistent memory.
- •Create a second session as a ‘retest’
- •Ask for information that was provided in the earlier session
- •Agent indicates it doesn’t have access to prior-session details
- •Recap: no information transfer between sessions by default
- 6:20 – 7:20
Introducing Memory Stores: persistent, mountable, filesystem-based memory
Kevin explains Memory Stores as a file system-like persistent store that can be attached to sessions. He highlights design flexibility (per user/workspace/org) and why a filesystem interface is powerful for agents (bash, grep, file reading/writing).
- •Memory Stores provide persistence across sessions
- •Developers choose boundaries: per user, workspace, or org
- •Mounted as a filesystem inside the session container
- •Agents can use tools like bash/grep to explore and retrieve info
- 7:20 – 8:20
Creating a Memory Store and exploring it in Console
Kevin creates a Memory Store via CLI and then shows where it appears in Console. He demonstrates the file viewer (initially empty) and notes that users can manually add or edit memories as files.
- •Create a memory store with name/description via CLI
- •Console location: Managed Agents → Memory Stores
- •File-system viewer shows current contents
- •Manual memory creation/editing supported through the UI
- 8:20 – 9:51
Mounting memory on sessions: prompts and access controls
Kevin shows how to attach a memory store to a session request, including an optional steering prompt and an access setting. He explains read/write vs read-only modes to control whether a session can update memory.
- •Pass memory_store_id when creating a session to mount memory
- •Optional prompt to steer what the agent should remember
- •Access control: read/write by default; can be set to read-only
- •Creates a new session that now has persistent memory attached
- 9:51 – 11:51
Memory in action: saving notes and recalling them in a new session
Repeating the earlier test, the agent now writes the provided notes into the memory store (e.g., a sessions.md file). In a subsequent session, the agent searches memory (using grep) and successfully answers questions based on previously stored content.
- •Agent checks memory, then writes new info when store is empty
- •Stored content appears as files (e.g., sessions.md) in the memory store
- •Second session with same memory store can retrieve prior notes
- •Agent uses search tools (grep) to find relevant keywords (e.g., CMA)
- 11:51 – 13:57
Managing memory stores: listing files, versioning, and editing memories
Kevin covers operational features: listing memory files via CLI, file versioning on every change, and inspecting/editing memory in the Console UI. He emphasizes that developers and humans can correct or enrich stored content directly.
- •CLI can list memory files within a store
- •Memory files are versioned; endpoints support version operations
- •Console shows directory structure created by the agent
- •Humans can edit incorrect content or add new memories manually
- 13:57 – 15:36
Dreaming: preventing memory bloat with async multi-agent refinement
Kevin introduces Dreaming as a background batch process to keep memory useful over time. It reviews transcripts and memory, fact-checks, enriches, and deduplicates content, producing a cleaner output memory store for future sessions.
- •Problem: agents may dump too much info; memory grows and becomes messy
- •Dreaming runs asynchronously (minutes to hours depending on input size)
- •Inputs: a memory store + a set of session transcripts (IDs)
- •Outputs: organized, deduplicated, enriched memory for improved retrieval
- 15:36 – 19:57
Running a Dream job: parameters, observability, and non-destructive outputs
Kevin walks through creating a Dream job (model choice, session list, optional instructions) and monitoring it in Console/API. He shows that Dreaming creates its own session for transparency and writes changes to a cloned output memory store rather than mutating the input.
- •Choose model (e.g., Opus vs Sonnet) based on quality/cost
- •Provide input memory store + list of session IDs; optional custom instructions
- •Console shows status, token usage, and an inspectable Dream session
- •Non-destructive: input store is cloned; Dream writes to an output store
- 19:57 – 22:33
Reviewing Dreaming results: diffs, index files, and enriched event notes
After completion, Kevin highlights the Console diff view that shows what Dreaming changed or added. Dreaming creates an index for efficient navigation, adds new structured files (e.g., event logistics), and enriches prior notes with metadata, structure, and extra details.
- •Console diff shows newly created/modified memory files
- •Index file helps agents quickly locate relevant memories
- •Dreaming adds structured summaries (schedules, names, logistics)
- •Reformats existing notes with slugs/metadata and more detail
- 22:33 – 28:41
Using the Dream output memory store in new sessions + wrap-up Q&A
Kevin demonstrates attaching the Dream-produced output memory store to a new session and shows improved answers thanks to richer, organized memory. He closes by summarizing the three-layer model (sessions → memory → dreaming) and addresses token/cost considerations like caching and future discounts.
- •Retrieve output memory store ID from the Dream resource
- •Attach Dream output store to new sessions for better recall and completeness
- •Composable layers: sessions (ephemeral) + memory (persistent) + dreaming (maintenance)
- •Token usage: exhaustive by design; high cache hit rates; model choice and scheduling can reduce cost
