Cursor Rules vs Persistent Memory

Last month I spent most of an afternoon in Cursor untangling a generic type constraint in a shared...

Last month I spent most of an afternoon in Cursor untangling a generic type constraint in a shared utilities package. I got it right, wrote a short note about why it had to be that way, and closed the laptop. Two days later I opened the same repo, asked Cursor to extend that utility, and it cheerfully proposed the exact constraint I had ruled out. My .cursor/rules file was right there. It just doesn't hold that kind of information.

That afternoon is the whole "cursor rules vs persistent memory" question in one scene. Rules and memory get lumped together because both are "context you give the agent," but they answer different questions, and mixing them up is why so many rules files end up as 400-line dumping grounds.

What Cursor Rules Actually Are

Cursor rules are plain instruction files you write by hand: a project-level .cursorrules file, or the newer .cursor/rules/*.mdc files that can be scoped to paths. Cursor reads them into the prompt so the agent behaves the way you want. Typical contents:

• Which language and framework conventions to follow
• How to name things, format code, structure tests
• What to avoid ("never edit the generated client," "don't add dependencies without asking")
• A short description of the project so the agent isn't guessing

Rules are static and deliberate. You write them once, they apply to every conversation, and they change only when you edit the file. That's their strength. It's also the reason they can't remember your Tuesday afternoon: a rules file describes how the project should be worked on, not what happened while working on it.

Why Rules Can't Remember Decisions

Everything Cursor knows in a session lives in the model's context window: the rules, the files you've opened, the chat so far. When the session ends, that context is gone. The rules survive because they're a file on disk that gets loaded again. The decision about the type constraint doesn't survive, because it was only ever in the conversation.

You can try to promote decisions into the rules file. Plenty of people do. It works for a few weeks, then two things happen. The file grows past what anyone will maintain, and half of it goes stale as the code moves on. I wrote about that failure mode for CLAUDE.md in Why Your CLAUDE.md Goes Stale, and Cursor rules rot the same way, for the same reason: a hand-maintained file can't keep up with the rate at which a real project makes decisions.

Think of rules as the house style guide of a newsroom. Every writer reads it. It says nothing about the story you were reporting yesterday.

What Persistent Memory Adds

Persistent memory stores decisions, preferences and project facts outside the context window, in a place the agent can search later. Instead of you copying "we dropped the caching layer" into a file, the agent saves it as a memory during the session and recalls it the next time the topic comes up, in Cursor or in whatever tool you switch to.

The kinds of things that belong in memory rather than in rules:

• Design decisions and the reason behind them
• Bugs you've already chased and how they were fixed
• Constraints that surfaced mid-task ("the vendor API rejects batches over 50")
• Things you said once in a chat and don't want to say again

Rules stay short and stable. Memory grows with the project. That division is the point: each one does the job it's good at.

How ContextForge Fits In

ContextForge is the memory layer I built after too many afternoons like the one above. It runs as an MCP server, so the same memory is reachable from Cursor, Claude Code, Claude Desktop, Windsurf and ChatGPT. You add it once per tool:

claude mcp add contextforge -e CONTEXTFORGE_API_KEY=<your-key> -- npx -y contextforge-mcp

In practice it looks like this. You finish the type-constraint work in Cursor and the agent saves the decision to the Project linked to your repo, with the reasoning attached. Two days later you ask Cursor to extend the utility. Before it proposes anything, it searches memory, finds the note, and doesn't repeat the mistake. If you open the same repo in Claude Code on Friday, it finds the same note, because the memory belongs to the project, not to the tool.

Inside a Project, memories are grouped into Spaces (folders by topic), Tasks track open issues, and the Git integration pulls commit messages and pull requests in as well. The piece that keeps it honest is freshness checks: when the code a memory describes has changed since it was saved, ContextForge flags it, and you or the agent can confirm it, correct it, or forget it. That is the difference between memory and a rules file that quietly lies to you six weeks later.

If you're setting up MCP memory for the first time, the walkthrough in MCP Memory Server: How to Give Claude & Cursor Persistent Memory covers the basics. And if you bounce between Cursor and Claude Code all day, How to Share Context Between Claude Code and Cursor goes deeper on that specific workflow.

Where It Falls Short

I'd rather you hear this from me than find out on day three.

• There's a setup step. An API key and an MCP entry in each tool. One-time, but not zero.
• Memory only holds what gets saved. ContextForge doesn't know what matters. If the agent never saves the decision, it isn't there. Your rules file is the right place to tell the agent when to save, which is the one job rules and memory share.
• It doesn't replace reading the code. Memory says what you decided. The file says what the code does today. The agent still needs both.
• It's early. Small team, active development, rough edges. We ship the core first and polish second.

Routines (scheduled cloud agents) and Skills (reusable prompt templates) sit on top of this, but they're a topic for another day. Get the basic loop working first.

A Practical Next Step

Open your rules file and read it with one question in mind: which lines are how to work and which are what we decided? Keep the first kind. Move the second kind into memory, or delete them if they're already stale. Then do one real task in Cursor with a memory server connected and check what got saved. If the next session already knows what you decided in the last one, you'll feel the difference immediately.