Why Your Agent Needs Memory, and How to Organize It

Read on Medium →

I keep a personal memory store for my coding agent on one machine. Today it holds 181 topic files behind a 134-line index, and almost none of it is knowledge. The agent already knows how middleware works and what a Dockerfile does. Every line I have written down exists for the opposite reason: it is a place where my world does not match the field average. Agent memory is not a copy of what the agent knows. It is the delta, the part left over.

That framing does a lot of work. It explains why context you did not need is not neutral but negative, why the size of your memory depends on how far you stray from the common pattern, and why the part that kills memory systems in production is not forgetting - it is accumulation.

#The whole discipline on a card

1. Four tests for every memory unit: simple and dense · non-conflicting · useful, measurably · classified, so a checked fact and a rumour never look alike.
2. Three requirements for the store: searchable with nothing installed · changeable with a human watching · kept alive with the tools already open.
3. One admission rule: write down only what the model got wrong, or could not have known.

Seven production coding agents landed on the same storage design without talking to each other: plain markdown files, a small one always in context, an archive opened on demand. The full article walks through why - the retrieval results that went the other way from what the field expected, the size envelope where grep wins and where it collapses, what Mem0 and Zep get right about vectors and graphs, and the flat 134-line index that routes my agent without making it guess.

If you cannot grep it, diff it, and delete a line from it, it is not your memory. It is somebody's cache of you.

Read the full article on Medium →

---

Related: agentage.io - one memory for every AI · github.com/vreshch - where the store lives in practice.