Cursor Rules vs Memory: What to Add Instead

Every Cursor team has a rules story. Someone writes .cursor/rules, the code gets more consistent, and for a while it feels like Cursor knows the project. It knows the conventions. It does not know what you decided yesterday, and no amount of rules writing will change that.

The confusion is worth naming precisely, because these are two different artifacts with two different jobs. Rules are instructions you write for the future. Memory is a record of what happened. Cursor has partial support for the second inside the editor, and no path for it to cross into the other tools you use. That cross-tool layer is what MemoryRouter adds.

What rules files do well

Encoding conventions so every generation follows them: framework choices, file layout, naming, error handling.
Scoping behavior per project or globally, since .cursor/rules files live in the repository and inherit version control.
Carrying checklists: "tests before commits," "we use pnpm," "never edit generated files."

All of it is intentional, hand-written, and current. That is the point. A rules file is a policy document.

What rules files cannot do

Rules describe behavior. They have no idea what happened in your last ten chats, and nobody keeps them updated with it. Try writing "we rejected the event bus because ordering guarantees broke under the retry load" into a rules file and the problem shows itself: that sentence is history. It matters exactly once, when someone is about to suggest an event bus. A rules file that accumulates every such sentence becomes a junk drawer that every request pays tokens to read.

The specific losses:

The decision and its reasoning, from yesterday's Agent session.
The implementation plan you discussed and never wrote into any doc.
The constraint you discovered, like which staging credentials cannot write to a bucket.
Where the task stands right now.

Cursor's built-in tools soften this inside Cursor: memories notes and @Past Chats. Both are useful, and both are scoped to the editor. A @Past Chats reference cannot help Claude Code on the same repository, and it cannot reach the ChatGPT session where you plan the next sprint.

Where the two get confused in practice

Three scenes play out in most teams that run both layers badly.

The rules file becomes a diary. Someone adds "decided against the event bus on March 3 because retry ordering broke" and nothing ever removes it. Every request now pays for yesterday's news.

Decisions live in chat only. The team ships the queue design, and the reasoning stays in one developer's Cursor session. That is fine until that developer takes a week off.

The chat is treated as documentation. "We discussed it in Cursor, it should know." It does not travel, and the next session starts from zero.

Rules and memory fix different scenes. Rules cannot fix the second or third, and a diary-style rules file does not fix the first.

The setup is one entry

Cursor speaks MCP, including remote servers with OAuth. Connect the memory server with a single addition to ~/.cursor/mcp.json for global scope, or .cursor/mcp.json inside a project. Enable it under Settings, sign in through the browser, and choose the vault the connection uses. No API key goes into the config, so there is nothing in the repo for anyone to copy.

You get memory tools in Cursor's MCP list: semantic search, explicit store, status, and time-window search for questions like "what did we settle last month." Connections start read-only, write scope is requested when needed, and access is revocable from your dashboard. The Cursor documentation covers the exact configuration, and the full walkthrough includes the two-chat test.

One behavior to internalize: Cursor decides when to call memory tools, the same way it decides when to search your codebase. When a fresh chat misses something you know is stored, "check memory for how we handle auth" is a normal prompt. That habit is what makes recall feel automatic.

The split that works

| .cursor/rules | Memory vault | | --- | --- | | How code should be written | What was decided and why | | Conventions and commands | Rejected approaches and failure details | | Review checklists | Constraints discovered mid-task | | Static, hand-edited | Captured as you work, retrieved on demand |

Write the first column deliberately, and keep it short. Let the second column accumulate without maintenance, and stop treating the rules file as the place where project knowledge goes to live.

Keep Cursor's own memories too

Nothing here argues against Cursor's built-in memories notes or @Past Chats. Use them. They are fast, they live inside the editor you already have open, and for a Cursor-only workflow they cover part of the ground. The vault exists for the part they cannot cover: reaching Claude Code, Codex, and ChatGPT with the same context, and outliving the tools themselves. That is what MemoryRouter's cross-AI memory is for. The two layers stack without conflict.

Boundaries to know: the connection does not import your old chats, it does not scope itself by repository (use separate vaults when you need hard separation between clients), and it does not touch Cursor's codebase index. The index keeps doing its job. This layer runs beside it.

Try it on the next decision

The test is one session long. Settle something real in Cursor, tell it to save the decision to MemoryRouter, then open Claude Code or a ChatGPT conversation on the same vault and ask why the project chose that path. When the reasoning comes back in a tool you never typed it into, rules and memory have separated cleanly in your head.

Create your MemoryRouter account and add the memory server before the next sprint starts.