| name | module-4 |
| description | Teaching instructions for Module 4 (Storage) — use when module_id is module-4 |
Module 4 — Storage
Lesson Title
Memory and Storage in LangGraph Deployments
Goal
Help the student understand the three memory mechanisms in a LangGraph deployment (checkpointer, Store, filesystem), how to read and write the Store from a client, and how deepagents wraps these primitives behind a backend abstraction.
How to run this lesson
- Start with the three memory types: each has a different scope and persistence story. Make sure the student can name them and say what each holds before diving into APIs.
- The checkpointer is automatic — no API to call directly. Mention it but don't dwell.
- The Store is the focus: cross-thread, persistent, namespaced. The SDK's
client.store.put_item / get_item / search_items is how the UI reads/writes student profiles.
- The filesystem is read-only for runtime data (it's baked into the Docker image), useful for static content like skills and AGENTS.md.
- After the SDK surface is solid, introduce deepagents' BackendProtocol. The same
ls/read/download_files interface is implemented by FilesystemBackend, StoreBackend, and StateBackend — swapping backends changes where data lives without changing middleware code.
- Reinforce the tutor as a worked example: register/login writes profile + sessions to the Store; the dynamic prompt reads the profile on every model call; skills are loaded from the filesystem by SkillsMiddleware.
Key concepts to cover
- Three memory types: checkpointer (per-thread, automatic), Store (cross-thread, namespaced, persistent), filesystem (read-only at runtime, image-baked)
- Store namespace — a tuple keying into a per-deployment KV space; in deep_tutor it's
(email_with_dot_to_underscore,)
- SDK Store API —
put_item, get_item, search_items, delete_item, list_namespaces
- The
langgraph_auth_user and the runtime.store injection inside graph nodes — direct access, no HTTP
- deepagents
BackendProtocol — uniform interface (ls, read, write, download_files)
- FilesystemBackend with
virtual_mode=True and root_dir — /skills/ maps to <root>/skills/
- StoreBackend — same interface, data lives in the Store instead of disk
- StateBackend — same interface, data lives in agent state (per-thread)
- SkillsMiddleware and MemoryMiddleware — what
create_deep_agent wires up internally
- Why skills are read on demand (
read_file tool) instead of all loaded upfront — progressive disclosure for token economy
- Why the filesystem is fine for read-only data but problematic for writes — a thread may execute across multiple containers
- Permissions —
FilesystemPermission(operations=["write"], paths=["/skills/**"], mode="deny") keeps the agent from clobbering skill files at runtime
Tone guidance
Concrete and example-driven. The student has already used the SDK in module 2; now we're extending those calls with Store operations. When explaining backends, lead with what changes (where data lives) and what stays the same (the middleware code).
Reference material
Full reference material is in information.md in this directory. Read it before answering factual questions.