How a memory bank works
There is no official memory bank in Cursor. The name covers a family of community setups that share one idea: since the agent forgets between chats, have it keep its own notes in files it can reread.
- A folder of markdown files holds the project's context, often split by purpose: what the project is, what is in progress, what has been decided.
- A Project Rule tells the agent to read those files before starting work.
- The same rule asks it to update them when something changes, such as a task finishing or a decision landing.
- You commit the folder, so the notes travel with the repo.
What it does well
- Everything is plain text you can read, diff and correct.
- It costs nothing and needs no service, account or network call.
- For a long solo project, a current "where are we" file saves real time at the start of each chat.
- Reviewers see memory changes in pull requests, which keeps bad notes from hiding.
Where it strains
- It records only what the agent writes. If the model skips the update step, or summarises a long debugging session in one line, the detail is gone.
- It grows. Files read on every task cost context on every task, so a bank that keeps everything gets expensive and then gets trimmed.
- It drifts. A note about a design the team later reversed reads exactly as confidently as a current one.
- It is per repo and per writer. Two people's agents updating the same files produce merge conflicts, and nothing from a teammate's Codex or Claude Code sessions lands there at all.
Memory bank compared with Glen
| Memory bank | Glen | |
|---|---|---|
| Capture | The agent writes notes when the rule reminds it | Cursor hooks record each session |
| Recall | Files loaded each task | On demand, when the agent runs glen search |
| Reach | One repo, through git | Your organization, across agents, filtered per user |
| Old decisions | Stay until someone edits them | Glen aims to follow the one that stuck; glen forget removes the rest from recall |
| Where it lives | Markdown in your repo | Glen's hosted service |
| Cost | Free | Free to 15,000 memories and 3 people |
The two can coexist. A short memory bank file describing current work is a reasonable thing to keep loaded, while Glen holds the long tail of history that would bloat it. Be aware that Glen is hosted only, and its recall in Cursor depends on the agent choosing to search.
Memory banks over MCP
Some setups swap the markdown folder for an MCP memory server. The reference one, @modelcontextprotocol/server-memory, stores a knowledge graph of entities, relations and observations in a local JSONL file set by MEMORY_FILE_PATH. It shares the bank's main limits: one machine, and only what the model decides to save. Glen also runs a remote MCP server any MCP client can search, and the wider design space is covered on AI agent memory.
Frequently asked questions
What is a Cursor memory bank?
A community pattern, not a built-in feature: markdown files that a rule tells the agent to read before work and update afterwards, usually committed to the repo.
Does the Cursor memory bank still work after Memories was removed?
Yes. It never depended on Memories; it runs on Project Rules and ordinary files, both of which Cursor still supports.
Is a memory bank better than Glen?
For one person on one project who wants everything local and in git, a memory bank may be enough. Glen fits when several people or agents need to recall each other's sessions without anyone writing notes.
Can I use an MCP server as Cursor memory?
An MCP memory server can fill that role. The reference one keeps a local knowledge graph on one machine, while Glen's remote MCP server at https://mcp.tryglen.com/mcp lets any MCP client search a team's memory.
