Key takeaways
Smartpig (@Smartpigai) walks through Anthropic’s engineering post “The components of agent memory.” Many agent-memory projects only store chat logs, embed them, and retrieve with vector search — an approach he says overcomplicates things from the start. The core claim: memory is not about storing more, but about knowing what is worth remembering, when to recall it, and when to forget. The post splits memory into four layers: Transcripts (raw event logs), Memory Notes (experience notes that include a conclusion and why it is trustworthy), Memory Representations (a background wiki that can be navigated), and Injected Context (preload what matters; retrieve the rest; Claude Code Auto Memory loads only the first 200 lines or 25KB of MEMORY.md). The technically interesting piece is Dreaming: idle compute reviews past tasks, distills reusable rules, corrects mistakes against raw transcripts, organizes a wiki, cleans contradictions, and decides what to inject next time. Results cited: CL-Bench database task, Opus 5.5 from 0.655 without memory to 0.838; in Pokémon, Sonnet 3.7 saved 413 files and earned 1 badge, while Fable 5 kept about 10 files and earned 4; on an enterprise corpus of ~350k docs / 420M tokens, search alone scored 53%, wiki+search 61%, saving ~20k tokens per question. His takeaway: the next generation of agent memory is less about RAG and more about memory lifecycle management. A reasonable engineering stack is Event Log + Structured Memory + Knowledge Wiki + Retrieval + Background Consolidation (Dreaming).
