Giving AI Coding Agents a Memory That Argues Back A software engineer built knowledge-database, an open-source persistent memory system for AI coding agents that stores dated markdown entries across explorations, solutions, errors and decisions buckets, each citing evidence as path:line ranges. In an experiment where three agents fixed the same money-rounding bug, the two without the knowledge base produced different but correct fixes, while the agent with it reproduced the team's recorded API and call sites, illustrating how memory prevents codebase drift. The project enforces its conventions through 15 stable rule IDs (KB001–KB015) backed by pass/fail test fixtures run from a zero-dependency Python CLI, a pre-commit hook, CI and an end-of-session agent hook. I'm writing a series called "Becoming a Super Engineer": a software engineer since 2013, learning to hold software, data and AI under the same belt, and writing it down as it happens. Chapter 1 https://dev.to/dcoferraz/what-ai-agents-taught-me-about-building-databricks-apps-7ni ended with agents that only stopped repeating mistakes once a check failed on them. This chapter is about the other half of that problem: what agents remember. It's about an open-source project of mine, a knowledge base the agents read before touching anything and write back to when they're done. It taught me a lot about working with agents : Two agents without memory, two different correct APIs. The one with memory gave back the fix we had recorded Without persistent memory, an AI coding agent forgets everything between sessions. Monday it spends 20 minutes figuring out how the auth middleware works. Tuesday, same question, same 20 minutes. Wednesday it debugs a bug you already fixed last week, from scratch. My first pitch for a knowledge base was the obvious one: stop paying tokens to rediscover the same things. A small experiment changed my mind. More on that later. The real problem showed up in an experiment I had an AI agent run: three agents got the same money-rounding bug, in the same codebase. All three fixed it correctly. The two without the knowledge base came back with two different correct fixes. One added round money amount . The other added to decimal , round money value and percent of amount, pct . The agent with the knowledge base rebuilt the fix we had already recorded: same API, same four call sites, same line numbers. All three were right. Only one matched what the team already had. That's the actual problem: drift. Each of these agents was smart enough to solve the problem, and each one solved it a little differently. Over months, that's how a codebase ends up with three ways to round money. Each step moved a rule from "please do this" to "this fails if you don't" The project is called knowledge-database https://github.com/dcoferraz/knowledge-database . The shape is simple. A folder of dated markdown entries, in four buckets: explorations/ : what is true about this system solutions/ : what we did, and how errors/ : what broke, and the trap that catches it next time decisions/ : what we chose, what we rejected, and who decided Every entry cites its evidence as path:Lstart-Lend , so a claim points at real lines of code. And one loop, on every non-trivial task: read first, do the work, write back. Read first, do the work, write back. The check makes sure nobody skips step three I'd been using this idea heavily in another setup before it went public. The public version, and making agents actually follow it, came together in twenty days. The first versions were rules written in the agent instructions. Please read the KB first. Please record what you learned. Recording started as a prompt at the end of every task "want me to record this?" , and turned mandatory pretty quickly. I wanted to review what went into an entry, without approving every single one. Everything in this phase depended on the agent choosing to behave. Then someone reviewed it from the outside and showed me the conventions were drifting. Index tags didn't match the entries. Entries marked verified had prose instead of proof. One decision used a hypothetical code comment as its evidence. That review changed the project. The new rule was simple: enforce or delete. Every hard rule got a stable ID KB001 to KB015 today and a test fixture that passes or fails. A rule without an ID isn't a rule anymore. It moves to a "guidance, not checked" section. A few of my favorites: verified requires a verification block with captured output. Comments like should work get rejected The checks run from a zero-dependency Python CLI, a pre-commit hook, CI, and a hook at the end of every agent session. A field failure showed the rules only loaded for one agent runtime, and only at the start of a session. So now a short rules block about 240 tokens gets injected on every single prompt, and the same rules get planted in six agent instruction files, one per runtime. Install it mid-session and it works on the very next prompt. Someone installed it fresh, on a workspace that wasn't a git repo, and read the docs like a new user. Thirteen findings. The verdict hurt a little: everything mechanically enforced worked. Everything at the edges didn't. The installer died halfway on a non-git folder. The rules told agents to run two scripts no install had ever copied. A staleness rule would start blocking every commit, 90 days after the entries were written, all on the same day. All thirteen got fixed in one release, plus a setup wizard and a real upgrade path. Then, in a second experiment, I had an agent measure the pitch itself. The control was the same task run three times without the knowledge base, recording each answer, the tokens and the time. Then the same task with the knowledge base in place. The agent with the knowledge base cost more than the control. Both causes were my fault. Nothing told the agent what "done" looks like when the answer already exists, so it wrote a new entry anyway. And the documented way to look things up was "read the index", which cost thousands of tokens before reaching the answer. The fixes: kb find "