A "Memory Bank" is how Cursor works around the fact that it forgets: .cursor/rules (and a ported memory-bank/ folder), read back each session to reconstruct context. It's a good pattern — but a file you maintain by hand and reload in full isn't the same as memory that recalls the right fact on its own. This guide covers how the Memory Bank works in Cursor, where it breaks, and how to add a real memory layer on top. New to the idea? Start with the complete guide to persistent memory for AI.
How the Memory Bank works in Cursor today
Cursor doesn't ship a Memory Bank, so people build one: a memory-bank/ folder ported from Cline, or a stack of .cursor/rules/*.mdc files that pin conventions and context. It nudges Cursor toward your project — but rules are static knowledge. They capture what you knew when you wrote them, not what you and Cursor work out together afterwards.
Where the file-based Memory Bank breaks
- Rules are hand-maintained: the decision you reached in yesterday's chat never lands in .cursor/rules unless you stop and write it down.
- Always-on rules are loaded into every prompt whether or not they're relevant, spending tokens and diluting the ones that matter.
- The files are per-project and per-machine — your other repo, and your laptop at home, start from nothing.
- There's no recall by meaning: a rule either matches by glob or it's always on; Cursor can't fetch "the reason we dropped that ORM" the moment it comes up.
The upgrade: a memory layer that recalls by meaning
Before: you keep editing .cursor/rules to nudge Cursor toward conventions, and it still reaches for the library you dropped in March. After: you tell it to remember the decision once, and every future session recalls it — and its reason — by meaning, on any machine. That's the difference between a static Memory Bank and a real memory layer for AI — a store outside the model that keeps facts and decisions, then surfaces only the relevant ones by meaning.
How to add persistent memory to Cursor
- In Cursor, open Settings → MCP and add the Kit for AI server with your API key.
- remember and recall appear as tools Cursor calls itself — it saves durable facts as you work and recalls them next session.
- Scope a namespace per repo so unrelated projects never cross-contaminate suggestions.
- Keep .cursor/rules lean for truly static rules; let the memory layer carry everything that changes as you work.
You don't have to choose — do both
Keep the Memory Bank for what it's good at: short working notes and static conventions a human reads too. Add persistent memory for the durable, evolving, cross-session recall the files handle badly. The files stay small; the memory does the remembering. It's also worth knowing that memory and RAG are different jobs — memory persists your decisions, retrieval grounds answers in documents.
FAQ
Does Cursor have a built-in Memory Bank?
Cursor uses .cursor/rules (and a ported memory-bank/ folder) — static files that steer it and give it project context. That's a Memory Bank in the file sense, but it isn't durable, semantic memory: it's maintained by hand, loaded in full each session, and scoped to one repo and machine. A memory layer adds recall by meaning, isolated per project, that follows you across tools.
How do I give Cursor persistent memory?
Add the Kit for AI MCP server to Cursor with an API key — remember and recall become tools it calls on its own — or use the REST API and SDK where MCP isn't available. It takes a couple of minutes, and the same memory is shared with every other tool you connect.
Related guides
Go deeper: persistent memory for Cursor · give Cursor shared memory across tools — or read the pillar on the AI Memory Bank pattern and the guide to persistent memory for AI.
Add real memory to Cursor in minutes — Start free, drop in the MCP server with your API key, and remember/recall become tools it calls on its own.