Memory Store Architecture in the Agents-That-Remember Workshop: A Technical Deep Dive

The agents-that-remember workshop implements a CMA Memory Store architecture that provides persistent, filesystem-like storage for Managed Agents, enabling cross-session state retention and batch-level memory consolidation through a dreaming service.

The anthropics/cwc-workshops repository demonstrates how to build AI agents with long-term memory using a sophisticated memory store architecture. This system allows Claude Managed Agents (CMA) to persist information across sessions, access shared data stores, and distill accumulated knowledge through automated batch processing. Understanding this architecture is essential for developers building stateful agentic applications that require continuity beyond single conversations.

Core Components of the Memory Store Architecture

The CMA Memory Store serves as a persistent backing layer that operates independently of any single agent session. Unlike ephemeral conversation contexts, these stores maintain state through a resource-based mounting system and CLI-managed lifecycle.

Persistent Store Creation and Lifecycle

A memory store is provisioned through the ant CLI using the beta:memory-stores create subcommand, creating a durable entity that survives session termination. As documented in agents-that-remember/README.md (lines 21-24), these stores support standard filesystem operations—create, read, update, list—and maintain version history across modifications. This persistence model ensures that agent knowledge accumulates over time rather than resetting with each new conversation.

Resource Mounting and Access Control

When initializing a new session, developers attach memory stores through a resource JSON object with type: "memory_store". The system mounts this resource into the session container at creation time, as specified in agents-that-remember/README.md (lines 37-42). The resource configuration accepts two critical parameters:

• prompt – Injected into the system prompt to instruct the agent on store usage (e.g., "track which CwC sessions I have attended")
• access – Controls permissions via read_write or read_only modes

This declarative mounting approach decouples storage lifecycle from session management, allowing multiple agents to access shared knowledge bases simultaneously.

The Three-Layer Memory Pipeline

The architecture implements a sophisticated data flow spanning immediate persistence, active usage, and batch consolidation:

SESSION  →  MEMORY STORE (live FS)  →  DREAMING (batch, produces new store)

Live Session Storage

During active conversations, agents interact with mounted memory stores as if they were local filesystems. The live storage layer provides immediate read/write persistence, ensuring that information captured in one session remains available to subsequent sessions using the same store ID. This transactional approach maintains consistency without requiring external database management.

The Dreaming Service for Memory Consolidation

The dreaming service operates as a batch processing layer that transforms raw accumulated memories into distilled knowledge. According to agents-that-remember/README.md (lines 30-36), a dream consumes an existing memory store along with session transcripts, runs a model over the aggregated data, and outputs a new memory store containing synthesized insights.

This process enables automated knowledge compaction—converting verbose interaction histories into compact, structured memories that improve retrieval efficiency and agent performance over time. The dreaming pipeline creates a refreshed store that summarizes past interactions while discarding redundant or obsolete information (lines 58-62).

Implementing Memory Stores in Practice

The workshop provides concrete CLI patterns for managing the complete memory lifecycle, from initial creation through batch consolidation.

Creating and Attaching Stores

First, provision a persistent store using the Anthropic CLI:

# Create a memory store

MEM=$(ant beta:memory-stores create \
  --name "cwc-memory" \
  --description "My CwC attendance and resources" \
  --format json | jq -r .id)

# Configure the resource attachment

MEM_RESOURCE='{
  "type":"memory_store",
  "memory_store_id":"'"$MEM"'",
  "prompt":"Track which CwC sessions I have attended, resource links I mention, and anything I flag to follow up on.",
  "access":"read_write"
}'

# Create a session with the store mounted

SES=$(ant beta:sessions create \
  --agent "$AGENT" \
  --environment-id "$ENV" \
  --title "Attended — CMA talk (with memory)" \
  --resource "$MEM_RESOURCE" \
  --format json | jq -r .id)

Runtime Interaction and Inspection

Once mounted, the agent automatically reads from and writes to the store during conversation:

# Send a message (agent will read/write the store automatically)

ant beta:sessions:events send \
  --session-id "$SES" \
  --event '{"type":"user.message","content":[{"type":"text","text":"I attended the CMA talk on memory architectures"}]}'

# Inspect store contents

ant beta:memory-stores:memories list --memory-store-id "$MEM"
ant beta:memory-stores:memories retrieve \
  --memory-store-id "$MEM" --memory-id <memory_id>

Batch Consolidation with Dreaming

Execute the dreaming service to compress accumulated memories into a refined store:

# Create a dream to distill knowledge

DREAM=$(ant beta:dreams create \
  --model claude-opus-4-7 \
  --input "{\"type\":\"memory_store\",\"memory_store_id\":\"$MEM\"}" \
  --input "{\"type\":\"sessions\",\"session_ids\":[\"$HIST1\",\"$HIST2\",\"$HIST3\",\"$SES\"]}" \
  --instructions "I am attending CwC, and I want to remember what I've learned." \
  --format json | jq -r .id)

# Retrieve the consolidated memory store ID

MEM_OUT=$(ant beta:dreams retrieve --dream-id "$DREAM" --format json \
  | jq -r '.outputs[] | select(.type=="memory_store") | .memory_store_id')

Summary

• Persistent Storage: CMA Memory Stores exist independently of sessions, created via ant beta:memory-stores create and supporting full CRUD operations across the beta:memory-stores API namespace.
• Declarative Mounting: Stores attach to sessions through resource JSON objects with configurable prompt steering and access controls (read_write or read_only).
• Cross-Session State: The architecture enables true long-term memory, allowing agents to reference information from previous conversations stored in the filesystem-like backing.
• Batch Consolidation: The dreaming service processes existing stores and session histories to generate distilled, optimized memory stores, implementing a compression layer for long-term agent knowledge.
• Implementation Resources: Critical files include agents-that-remember/README.md for architectural guidance and agents-that-remember/scripts/bootstrap.sh for automated environment setup.

Frequently Asked Questions

How does the memory store architecture differ from standard conversation context?

Standard conversation context is ephemeral and scoped to a single session, whereas the CMA Memory Store architecture provides persistent, filesystem-like storage that survives session termination. As implemented in anthropics/cwc-workshops, these stores are mounted as resources at session creation and maintain versioned state accessible across multiple agent instances, enabling genuine long-term memory rather than limited context windows.

What is the purpose of the dreaming service in the memory architecture?

The dreaming service functions as a batch processing layer that consolidates accumulated memories into optimized knowledge stores. It consumes existing memory stores plus session transcripts, runs a model over the aggregated data, and outputs a new, refined memory store containing distilled insights. This process compresses verbose interaction histories into structured, high-value memories while filtering redundant information, effectively creating a "sleep and consolidation" pattern for agent memory management.

Can multiple agents access the same memory store simultaneously?

Yes. Because memory stores are created independently of sessions through the ant beta:memory-stores CLI and mounted via resource references, multiple agents can mount the same store ID with appropriate access modes. The architecture supports both read_write and read_only access levels, allowing shared knowledge bases where some agents contribute updates while others consume information without modification rights.

What controls whether an agent can modify a memory store?

The access attribute in the resource JSON object governs store permissions. When mounting a store via ant beta:sessions create, developers specify either "access":"read_write" to allow the agent to create, update, and delete memories, or "access":"read_only" to restrict the agent to retrieval operations only. This declarative permission model provides granular security control over shared persistent storage.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}