{"slug": "what-is-worth-remembering-a-working-definition-of-useful-memory-for-coding", "title": "What Is Worth Remembering? A Working Definition of Useful Memory for Coding Agents", "summary": "A developer working on the brain-site project proposed a working definition of useful memory for coding agents: store only decisions and their reasons, user preferences, project facts that live outside the code, and known failures, and drop anything the agent can already derive from the repo. The definition draws on the ETH Zurich paper \"Evaluating AGENTS.md\" (Gloaguen et al., arXiv 2602.11988), which found repository context files generally did not improve task success and raised inference cost by over 20% on average, though they helped when they specified non-standard practices. The author also cites Claude Code documentation noting that every request resends the full conversation, so extra context is paid for on each turn.", "body_md": "**AI agent memory should store what a coding agent can't work out from your repo and would get wrong if nobody told it: decisions and their reasons, preferences, project facts that live outside the code, and known failures.** Everything else is either already available to the agent or is noise. Good memory is small on purpose. The test for each item is simple: would a future session go wrong without it?\n\nThink about your last long session with Claude Code or Cursor. Most of it was file reads, test output, wrong turns and small edits. The useful part might fit in three lines. You dropped Redis for SQLite because Redis only served the old job queue. You always use pnpm. Migrations have to run before seeding in CI.\n\nKeeping the rest has a cost. The Claude Code docs say every request sends the whole conversation, so whatever sits in context gets paid for again on each turn. Researchers at ETH Zurich measured a version of this in \"Evaluating AGENTS.md\" (Gloaguen et al., arXiv 2602.11988). Repository context files did not generally improve task success, and they raised inference cost by over 20% on average.\n\nThat study tested context files, not memory systems, but the lesson carries over. Extra context isn't free, and it doesn't help by default. We wrote more about where those tokens go in our guide to [cutting AI coding agent token costs](https://rohithhn.github.io/brain-site/blog/reduce-ai-coding-token-costs.html).\n\nWhen people ask what AI agent memory should store, we give them four categories. Each one passes the same test: the agent can't get it from the code alone.\n\nThe code shows what you chose. It rarely shows why, or what you ruled out. \"Sessions live in SQLite; Redis only served the old job queue\" stops an agent from helpfully bringing Redis back next month. Keep the reason with the decision, because the reason is what lets an agent judge whether it still applies.\n\nThese are the things you've corrected more than once. Use pnpm. Don't add a new dependency for something small. Keep commit messages short. The Claude Code docs list \"anything you've had to correct twice already\" among the things worth writing down, and that's a fair rule for any tool. A preference between two reasonable options can't be read from the code, so somebody has to say it.\n\nSome facts live outside the repo, or are technically in it but take a while to dig out. How deploys really work. Which environment variable the integration tests need. Which folder looks dead but isn't. The docs' examples are similar: a decision made in a meeting, a deploy process that lives in one person's head.\n\nThis is the most undervalued kind of memory. A fix records something a clean codebase hides: this approach was tried and it broke. \"When a cache layer is removed, also remove its health checks and env vars\" costs one line to keep and can save an afternoon of debugging. The ETH study's positive finding points the same way: context files helped when they specified non-standard practices, the things an agent wouldn't otherwise guess.\n\nLeave out anything the code, the git log or a quick search can already tell the agent. That covers file layouts, dependency lists, architecture summaries, function signatures and what changed in last week's commit. The ETH paper found repository overviews unhelpful, even though they're a popular thing to write. Claude Code's built-in auto memory takes the same line: it skips what can be derived from the codebase, such as architecture and file paths.\n\nThe Claude Code docs offer a two-question filter we like. Could it find this by reading the code? Would it actually go and look? If both answers are yes, leave it out.\n\nAlso leave out anything temporary. Today's half-finished debugging theory isn't knowledge yet, and it ages badly.\n\nStale memory can be worse than none. The ETH paper found agents follow context file instructions well, so an outdated note is likely to be obeyed. And if two instructions contradict each other, the Claude Code docs warn that Claude \"may pick one arbitrarily.\"\n\nPassing the test earns a memory a place in the store. It doesn't earn a place in every session. So there's a second decision: does this load every time, or wait until it's needed?\n\nA briefing is what the agent reads before it starts. It should hold what applies to nearly any task in this project: active decisions, firm preferences, the failures people keep repeating. The space is tight. The Claude Code docs recommend under 200 lines per CLAUDE.md file, because longer files consume more context and reduce adherence. Auto memory works the same way, loading only the first 200 lines or 25KB of its index at session start.\n\nEverything else belongs in search. The reason the auth migration took three attempts doesn't need to be in your head while you're fixing a CSS bug. It needs to be findable when you touch auth.\n\nA quick way to sort them: if forgetting it would cause damage before anyone thought to ask, brief it. If you'd know to ask, make it searchable. Our [context engineering guide](https://rohithhn.github.io/brain-site/blog/context-engineering-ai-agents.html) goes further into this trade-off.\n\nAt Open Agentic Brain & Memory (OpenAB), we treat capture and selection as two separate jobs. Capture is generous, briefing is strict, and a nightly rewrite keeps the two connected.\n\n**Capture every session.** Sessions from Claude Code, Codex, Cursor, Antigravity and Kilo Code (beta) flow into one local SQLite store, tagged by project.\n\n**Cap the briefing at 2,000 tokens.** A start-up hook injects it in 84 ms (p50). Older context stays searchable through MCP, with recall over 10,000 memories at 28 ms (p50).\n\n**Rewrite nightly.** The brain dream command distills what was captured into a wiki. Memories are ranked by use and by whether you marked them helpful, so what misleads sinks. Lessons drafted from solved problems wait for your approval before they're used.\n\nThe cap is where the savings come from. In our own benchmark, loading context for a 10,000-memory store took 1,325 tokens, against 1,131,367 for dumping every memory. On LoCoMo, a public long-term memory benchmark, we scored 86.6 against 89.3 for reading the whole conversation: 97% of the score on 18% of the tokens. LoCoMo tests conversations rather than coding sessions, and these are our own published results, so we explain how to read them in our [benchmark guide](https://rohithhn.github.io/brain-site/blog/ai-memory-benchmarks-longmemeval-locomo.html).\n\nFewer tokens per session means you reach your Claude, Cursor or Codex limits later. And because the memory is shared, you don't pay to explain the same project to each tool, which matters if you [use several AI coding agents](https://rohithhn.github.io/brain-site/blog/use-multiple-ai-coding-agents.html).\n\nYou can check all of this yourself. A local control panel lets you read, edit, pin or delete every memory. There's no account and no server of ours. The [OpenAB project page](https://rohithhn.github.io/brain-site/index.html) covers install, sync and the full benchmark numbers.\n\n[Install Open Agentic Brain & Memory (OpenAB)](https://rohithhn.github.io/brain-site/index.html)\n\nIt can capture everything, but it shouldn't read everything. Raw history is useful as a source to distill and search. Loading it all costs tokens on every turn and buries the few lines that matter.\n\nA briefing loads automatically at session start, so it has to be short and apply to most tasks. Search runs on demand when the agent needs something specific, so it can cover your whole history. Use the briefing for what the agent must know before it acts, and search for the rest.\n\nAsk questions from your own project history and score the answers, with memory on and off, while tracking tokens used. Generic benchmarks are a starting point, but your own history is the better test. In OpenAB, brain eval does this by quizzing the memory with 20 questions drawn from your history.\n\nYou write a rules file by hand, and each tool has its own, such as CLAUDE.md or AGENTS.md. Agent memory is captured from your work and can be recalled when needed. Keep firm, always-on instructions in the rules file and let memory carry the growing record of decisions and fixes.\n\nKeep the reason with each decision, so an agent or a person can tell when it no longer applies. Review on a schedule, and delete or rewrite anything outdated instead of adding a correction next to it. In OpenAB, the nightly rewrite and helpful or unhelpful marks push misleading memories down, and you can edit or delete any of them yourself.", "url": "https://wpnews.pro/news/what-is-worth-remembering-a-working-definition-of-useful-memory-for-coding", "canonical_source": "https://dev.to/open-agentic-brain-and-memory/what-is-worth-remembering-a-working-definition-of-useful-memory-for-coding-agents-5fea", "published_at": "2026-11-06 20:41:57+00:00", "updated_at": "2026-11-06 20:54:57.354172+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "large-language-models", "ai-research"], "entities": ["Claude Code", "Cursor", "ETH Zurich", "Gloaguen", "arXiv", "brain-site"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/what-is-worth-remembering-a-working-definition-of-useful-memory-for-coding", "markdown": "https://wpnews.pro/news/what-is-worth-remembering-a-working-definition-of-useful-memory-for-coding.md", "text": "https://wpnews.pro/news/what-is-worth-remembering-a-working-definition-of-useful-memory-for-coding.txt", "jsonld": "https://wpnews.pro/news/what-is-worth-remembering-a-working-definition-of-useful-memory-for-coding.jsonld"}}