Your AI agent forgets everything between sessions because nothing in the stack persists by default: the context window empties when the session ends, and the model's weights only change when the vendor ships a new model. "Remember this" gets a polite acknowledgement, then vanishes. The fix is always some form of external memory, and there are exactly three honest ways to add one: files your agent reads, a self-hosted memory store, or a managed memory layer over MCP. Which one is right depends on which problem you actually have.
The forgetting is structural, not a bug
Every session starts from a blank context window. Whatever you explained yesterday, the decisions you made, the conventions you agreed on, the bug you already fixed twice: none of it exists for the agent today unless something outside the model carries it.
This is why the same complaints keep showing up in every community where people use coding agents seriously. You get tired of re-explaining who you are and how your project works. The agent confidently contradicts a decision it helped you make on Tuesday. It suggests npm in a pnpm repo for the third time this week. Longer context windows do not fix this: a million tokens still empty out at the end of the session, and most of what you paste back in is noise by then.
So the real question is not "why does it forget" but "where should the memory live". Three camps, each with a genuine reason to exist.
Fix 1: files the agent reads (CLAUDE.md, AGENTS.md, notes)
The simplest fix is a markdown file in your repo that the agent reads at the start of every session: project conventions, key decisions, things it should never do. Most coding agents support this natively, and you can go further with agent-curated note files that the agent itself appends to.
Honest pros: free, local, versionable in git, zero dependencies, and you can read every byte of what the agent knows. For a single repo on a single machine, this is often enough, and it is the right place to start.
Honest cons: you are the memory system. Files grow stale unless someone curates them, nothing ranks what matters, nothing forgets what stopped being true, and the memory is trapped in one repo. Your agent in Cursor knows nothing about what you told Claude Code, and vice versa.
Fix 2: a self-hosted memory store
The second camp runs a real memory engine on your own infrastructure. Open-source options take different angles: some store facts as vectors with extraction pipelines, some build temporal knowledge graphs where facts carry validity windows, some turn your documents into a queryable graph.
Honest pros: you own the data end to end, you can inspect and tune the engine, and nothing leaves your perimeter. If privacy or compliance is the hard constraint, this camp wins outright.
Honest cons: it is infrastructure. You run it, scale it, tune retrieval quality, and handle upgrades. Memory quality becomes another thing your team maintains, and most stores still serve one application rather than every tool you work in.
Fix 3: a managed memory layer over MCP
The third camp moves memory outside any single tool. Disclosure: I work on Mnemoverse, which sits in this camp, so read this section knowing that.
The idea: a hosted memory service that every MCP client shares. You write a memory in Claude Code, and the same memory is there when you open Cursor, VS Code, or ChatGPT, behind one API key or OAuth login. Nothing to run.
The interesting part is what the memory does between sessions. In Mnemoverse, each write carries an importance score, associations between concepts strengthen as memories are recalled together through a Hebbian rule tuned by a Rescorla-Wagner update, and reporting whether a recalled memory actually helped re-ranks what comes back next time. The goal is memory that improves with use instead of accumulating noise.
Honest cons: the engine is hosted, so you are trusting a vendor with your context, and if your requirement is running everything inside your own perimeter, camp 2 is your answer. There is also no magic about invocation: an agent with memory tools available will not necessarily call them, which brings me to the one tip that applies to every camp.
The tip that matters in all three camps
Whatever memory you add, give the agent a standing instruction to use it. Something as short as "before non-trivial work, check memory; after decisions, corrections, or lessons, save them" in your system prompt or project file changes memory from a tool that exists to a habit that runs. Tool available does not mean tool used. This is the most common reason any memory setup quietly does nothing.
How to choose
Latency-critical and privacy-critical, single repo: start with files, they are genuinely good. Own-your-data with engineering capacity, one main application: self-host a store. Same memory across every AI tool you use, nothing to operate: a managed MCP layer. There is no free lunch, only the corner of the trade-off triangle that fits your work.
If you want to see the cross-tool version in action, Mnemoverse has a free tier (1,000 queries a day, no credit card): write a memory in one tool, recall it in another, and decide for yourself whether the continuity is worth it.
Top comments (1)
A fourth axis cuts across all three camps: correction semantics. Persistence is easy compared with making an old fact stop winning after it becomes false. An extracted memory is a derived claim, not ground truth, so I’d store source, author/principal, workspace scope, recorded time, valid time, and a supersedes/retracts relation rather than mutating text in place.
The evaluation should be longitudinal too. A useful harness could replay the same task after: a decision is corrected, a credential is revoked, the user switches repositories/tenants, and a high-importance but irrelevant memory is added. Measure helpful recall, harmful/stale recall, leakage across scopes, task outcome, and token cost against a no-memory baseline.
That also makes “forgetting” a required feature, not a failure: expiry, revocation, and deletion need to affect retrieval immediately across every MCP client. Cross-tool continuity is valuable precisely when the same cross-tool policy boundary follows the memory.