Overview
Claude-mem carries selected work across agent sessions by capturing events, compressing them into structured observations, storing them locally, retrieving them progressively, and fitting delivery to a context budget. The series compares failure recovery and local, synced, and server boundaries, then treats memory as bounded evidence—not ground truth.
Learning outcomes
- Claude-mem makes selected prior work searchable context rather than replaying entire transcripts.
- Capture, model-assisted compression, storage, retrieval, and delivery are separate success boundaries.
- A stored observation can be incomplete, stale, mis-scoped, or absent from delivered context.
- Local, synced, and server deployments trade simplicity and locality for distribution, sharing, and control.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
How does Claude-mem carry context between agent sessions?
Claude-mem carries selected work between sessions by turning admitted events into structured observations and summaries that later search and context rendering can deliver. It does not replay every transcript line.
Is a Claude-mem observation the same as the original tool output?
No. A Claude-mem observation is a model-produced, bounded account rather than the original tool output. Selected raw tool I/O can be disclosed when exact evidence is needed.
Why might Claude-mem store a memory but not return it?
Claude-mem can store a memory without returning it when indexing, query scope, recency filters, or the context-delivery budget prevents it from reaching the result. The canonical SQLite row may still exist.
How should you decide between local, synced, and server Claude-mem deployments?
Choose local when one machine and a local corpus suffice, synced when continuity across devices justifies a larger trust perimeter, and server when shared access and service controls justify added infrastructure.