Agent Memory: What Outlives the Run
Agent memory is the knowledge that survives a run, not the working state inside one. This explainer separates the two, then maps the write path, the read path, and the database limits that cap recall.
MongoDBExplainer
The post distinguishes agent state, the run-bound working data of a single execution, from agent memory, knowledge that outlives the run and is read across sessions. Context compaction, which decides what to keep when the window fills, is lossy by construction and sets both token cost and reliability; Chroma’s study found models become unreliable well before their advertised 200k-token window, and teams compact at 95% or proactively at 60%. System prompts and skills must be versioned, governed infrastructure, not text files, with prompt registries and the SKILL.md standard for procedural memory, and skills are executable so they require sandboxing. Enterprise data enters memory through pipelines like change data capture, not migrations, with chunking, embedding, and provenance stamps. The database choice caps filtered recall under selective scoping, the consistency window, and temporal modeling, setting the ceiling for later decisions.
This post is part 5 of the ‘Designing an Agentic Platform’ series, focusing on agent memory as production infrastructure. It builds on earlier posts about memory hierarchy, multi-agent memory engineering, memory-augmented agents, and LangGraph long-term memory, now examining memory inside the harness—compaction, versioned prompts and skills, enterprise data pipelines, and database selection.
Context compaction is lossy and sets both token cost and reliability; Chroma’s study found models become unreliable before their advertised 200k-token window, and teams compact at 95% or proactively at 60%.
System prompts and skills must be versioned and governed as infrastructure, with prompt registries and the SKILL.md standard for procedural memory; skills are executable and require sandboxing.
Enterprise data enters agent memory through pipelines like change data capture, not migrations, with chunking, embedding, and provenance stamps, leaving systems of record in place.
State is the run-bound working data of a single execution—the plan, intermediate results, and checkpoint for crash recovery. Memory is knowledge that outlives the run and is read across sessions. Checkpointing persists state; it does not create memory.
Compaction decides what to keep when the context window fills. It is lossy by construction—every step discards information—which makes it the part of the memory system that sets both token cost and reliability.
Through a pipeline rather than a one-time load: change data capture streams updates from the system of record, and each unit is chunked, embedded with a tagged model version, indexed, and stamped with provenance. The systems of record stay where they are.
Summaries are generated from the original by a language model. Check the original before relying on it.
See the idea
Agent memory is the knowledge that survives a run, not the working state inside one. This explainer separates the two, then maps the write path, the read path, and the database limits that cap recall.
Keep reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
One useful email. Unsubscribe anytime.