An AI coding agent that repeats the same mistakes keeps bringing back a bug, a pattern or a dependency you already rejected, because it has no memory of earlier sessions. The fix you agreed on in Monday's chat is gone by Tuesday. So the agent goes back to the most common answer from its training data, which is often the exact thing you told it not to do. The problem gets worse when you switch tools, because Claude Code, Cursor and Codex each start with their own blank slate and none of them knows what the others learned.
At Open Agentic Brain & Memory (OpenAB), we kept running into this in our own work. We would spend twenty minutes tracking down a race condition, explain the cause, ship the fix, and then watch a fresh session suggest the same broken code a week later. The model wasn't getting worse. It just didn't know what we knew. This article covers why that happens, what it costs you in time and tokens, and how a shared, self-hosted memory layer stops it.
Why coding agents keep reintroducing fixed bugs
Large language models don't learn from your sessions. Each conversation starts with only the system prompt, whatever files the tool decides to read, and what you type. When the chat ends, everything you worked out together goes with it. A few specific failure patterns come out of that:
The default answer wins. Say you decided to drop Redis and use SQLite for a small internal service. A new session that sees a caching problem will often suggest Redis again, because that's the statistically common answer. Your decision was never written anywhere the agent reads.
Fixes have no history. A bug fix is a diff plus a reason. The diff stays in your codebase, but the reason ("this retry loop must not run inside the transaction") lived only in the chat. Without the reason, a later refactor can undo the fix and look completely sensible while doing it.
Preferences get re-argued. You always use pnpm, never npm. You want named exports. You don't want new dependencies without asking. Every new session has to be told again, and if you forget once, you end up cleaning up a lockfile.
Tools don't share what they learn. If you plan in Claude Code and edit in Cursor, the second tool has no idea what the first one settled. Instruction files like CLAUDE.md or AGENTS.md help, but you have to maintain them by hand, they're per tool, and they go stale.
None of this means the agent is careless. It's working without information, and the information it's missing is exactly what keeps your project from going in circles.
The hidden token cost of re-explaining your project
The usual workaround is to paste context back in: a notes file, a long README section, a summary of last week's decisions. That works for a while, but it's expensive. Every pasted paragraph uses tokens on every session, in every tool, whether it matters to the current task or not.
That cost adds up. Loading a full history into context doesn't scale. In our measurements, loading everything from a 10,000-memory store directly would take 1,131,367 tokens, far more than any practical context window. OpenAB loads context for that same store in 1,325 tokens by distilling and ranking what matters before injecting it. Even at a much smaller scale, the habit of pasting notes into every chat is what makes you hit Claude, Cursor or Codex usage limits earlier than you need to.
Quality matters as much as size. On the LoCoMo long-conversation benchmark, OpenAB keeps 97% of the score you get from feeding the model the full conversation while reading only 18% of the tokens. You get almost all of the recall for less than a fifth of the reading. Fewer tokens per session means longer working sessions before you hit a limit, and less noise competing with the code the agent actually needs to look at.
How shared memory stops the loop
OpenAB is a free, open-source (Apache-2.0), self-hosted memory layer shared across Claude Code, Cursor, Codex, Antigravity and Kilo Code (beta). The idea is simple: tell one tool and every tool knows. If you decide something in Claude Code on Monday, Cursor already knows it on Tuesday.
Capture: decisions, fixes and preferences become memories
While you work, OpenAB captures the things that would otherwise disappear when the chat ends: decisions ("use SQLite, not Redis, for the job queue"), fixes ("the flaky test was caused by a shared temp directory; each test now gets its own"), and preferences ("always pnpm"). Each memory is tagged by project, and the project is found by walking up from the current folder to the nearest .git directory. You don't configure projects by hand. Opening a repo is enough.
Distill, rank and inject: a bounded briefing at start-up
When a session starts, a start-up hook injects a briefing of at most 2,000 tokens. It takes 84 ms at p50, so you won't notice it. The briefing isn't a dump of everything. It's distilled and ranked, with the current repository's history first. That's how the agent learns, before writing a line, that the retry loop must stay outside the transaction and that Redis was already ruled out.
Recall on demand over MCP
Some context only matters mid-task. For that, tools can query memory directly through MCP tools: brain_recall to search, brain_remember to store something explicitly, brain_context to ask "what should I know before starting this task", and load-my-brain to pull in the briefing. Recall over 10,000 memories takes 28 ms at p50. Search is hybrid, combining keyword matching with semantic meaning, so a query about "the queue bug" can find a memory that never used the word "queue."
Project-aware without being walled off
Repeated mistakes often cross project lines. The auth pitfall you fixed in one service tends to show up in the next. OpenAB keeps memory project-aware but not isolated. Opening a folder gives you that repo's history first, and a map of up to 20 projects lives in the global CLAUDE.md, AGENTS.md and GEMINI.md files so every tool knows what else you work on. Recall can search a single project or all of them.
A concrete example: the bug that stopped coming back
Here's the kind of loop OpenAB is built to break:
On Monday, in Claude Code, you find that a webhook handler double-processes events because it acknowledges the message before the database write commits. You move the acknowledgement after the commit and explain why. OpenAB captures that as a fix memory tagged to the repo.
On Wednesday, on a different laptop, you open the same repo in Cursor and ask it to "clean up the webhook handler." Without memory, a tidy refactor could easily put the acknowledgement back at the top. With OpenAB, the start-up briefing already includes the fix and its reason, and the agent leaves the ordering alone.
On Friday, in Codex, you start a new service with a similar webhook. Codex asks brain_context what to know before building a webhook handler, and the earlier fix comes back from the other project.
You explained the bug once, and three tools across two machines got it right afterwards.
Cross-machine sync without a vendor server
The second laptop in that example matters. Many developers work on a desktop and a laptop, or a personal and a work machine. At start-up, OpenAB merges in what your other machines learned, so the briefing is the same everywhere.
Sync doesn't go through us. There's no account and no OpenAB server. Memory lives in a local SQLite database on each machine. For sync, it's encrypted with age, the key is kept only in your OS Keychain, and the encrypted blob is stored as a Release asset in your own private GitHub repository. If that repo or your GitHub token ever leaked, nothing readable would be exposed. That's why we position OpenAB as the privacy-first, owner-held alternative to hosted memory APIs. Your project history, which often includes architecture decisions and security fixes, never sits on someone else's infrastructure.
Staying in control of what the agent remembers
A memory layer that quietly remembers the wrong thing would just create a new way to repeat mistakes. So OpenAB is transparent by design:
A local control panel lets you read, edit, pin or delete every memory. If a decision changes (say you bring Redis back for a high-throughput service), you update the memory instead of fighting an outdated one.
Pinning keeps critical rules, like "never run migrations automatically," at the top of every briefing.
Outcome scores track which memories actually helped, so useful context ranks higher over time.
You can start from past AI work by bringing in existing history, or start fresh with an empty memory.
The brain eval command scores recall against your own history, so you can measure whether memory is finding the right things in your projects instead of trusting a benchmark.
Practical habits that make memory work harder
Memory works best when what it captures is clear. A few habits help:
State the reason along with the fix. "Moved ack after commit because early ack caused double-processing" is far more useful later than "fixed webhook."
Say decisions out loud. If you rule something out, tell the agent plainly: "We are not using Redis here; SQLite is enough." Explicit decisions make strong memories.
Pin the rules that hurt to break. Reserve pins for the few constraints whose violation costs real time.
Review now and then. A quick pass through the control panel every few weeks keeps outdated decisions from steering new work.
Stop paying twice for the same lesson
An AI coding agent that repeats the same mistakes isn't a model problem you have to put up with. It's a missing-memory problem, and you can fix it. When decisions, fixes and preferences outlast the chat, follow you across tools and machines, and arrive as a briefing under 2,000 tokens instead of a pile of pasted notes, the agent stops undoing your work and you stop spending tokens re-teaching it.
OpenAB is free, Apache-2.0 licensed and built by Rohith, Chandan and Sushmita. To see how it fits into your setup and to read our guides on AI memory layers, context engineering, long context vs RAG vs memory, agent hooks and self-hosted memory privacy, visit the Open Agentic Brain & Memory project site. The source is on GitHub at rohithhn/Open-Agentic-Brain-and-Memory.
Top comments (0)