A "Memory Bank" is the most popular workaround for the fact that AI coding agents forget. The idea, popularised by Cline: keep a folder of structured Markdown files — a project brief, the active context, decisions, progress — and have the agent read them at the start of every session to reconstruct where it was. It's simple, it's in your repo, and it works well enough that people have ported it into Cursor, Claude Code, Windsurf, Gemini CLI, and GitHub Copilot. But the pattern has a ceiling, and it's worth understanding before your Memory Bank becomes a maintenance chore.
What a Memory Bank actually is
It's a convention, not a feature: a set of Markdown files the agent treats as its long-term memory. Cline's canonical version is a memory-bank/ folder (projectbrief.md, productContext.md, activeContext.md, systemPatterns.md, techContext.md, progress.md); other tools use CLAUDE.md, GEMINI.md, .cursor/rules, or .github/copilot-instructions.md. The agent reads them to rebuild context, and — in the disciplined version of the pattern — updates them as it works.
Why it works
A Memory Bank gives a stateless agent continuity within one repo. The decisions and conventions that would otherwise be re-explained every session live in files the agent reads first. For a single project on a single machine, that's a real improvement — and because the files are human-readable and version-controlled, your team can read them too.
The five ways a file-based Memory Bank breaks
- It reloads in full every session. The agent reads the whole bank whether or not it's relevant, so your context window — and token bill — grows with the bank instead of with the task.
- It drifts. The files are only as current as the last time the agent (or you) remembered to update them; stale notes quietly mislead the next session.
- It's per-repo and per-machine. Clone elsewhere, open a second project, or switch computers, and the accumulated understanding doesn't come with you.
- It has no recall by meaning. The agent reads all of it or none of it — it can't fetch the one decision that answers the current question and skip the rest.
- It doesn't cross tools. A Memory Bank in Cline is invisible to Cursor or Claude Code; every tool maintains its own silo.
Memory Bank vs a memory layer
A memory layer solves the same problem from the other end. Instead of files the agent reads in full, it's a store outside the model with two operations — remember a fact, recall by meaning — that returns only the handful of memories relevant to right now. It lives in the cloud, so it's the same memory across every tool and machine, isolated per project, with no folder to hand-maintain. That's not a knock on RAG, which is a different job: memory persists your decisions and preferences, while retrieval grounds answers in documents.
Do both: files for notes, memory for recall
The best setup isn't either/or. Keep a lean Memory Bank for static conventions and working notes a human wants to read; add a memory layer for the durable, evolving, cross-session recall the files handle badly. The files stay small and current; the memory does the remembering. Over MCP, remember and recall become tools your agent calls on its own — and the same store is reachable over a REST API for anything that isn't MCP-native.
Memory Bank by tool
The pattern looks different in each tool — different files, different limits, different setup. Pick yours: Cline, Cursor, Claude Code, Windsurf, Gemini CLI, GitHub Copilot. Each guide shows how that tool's Memory Bank works today and how to add real memory on top.
Stop hand-feeding your agent a folder of Markdown. Start free and give it memory that recalls the right fact on its own — shared across every tool you use.