Why Cursor Forgets Context From Earlier in the Project
Cursor forgets the reasoning behind a three-week-old decision because nothing in the product is designed to carry it forward. Every chat and every Agent run starts from the same inputs. There's your current prompt, whatever files the agent opens or searches for, and anything written into rules files that load automatically. Cursor's own docs are direct about why, stating plainly that "Large language models don't retain memory between completions." That isn't a limitation specific to Cursor. It's a fact about the underlying models, and Cursor's context system is built around it rather than against it.
What reads as forgetting is the absence of a step nobody added. The codebase index knows where code lives, not why it was written that way. A conversation stays coherent while it's open, then closes and takes its context with it. And nothing in Cursor is watching the Slack thread or the support ticket where the real reasoning happened, because that conversation never lived anywhere a coding agent could search it.
The index and the rules file
Two things persist by default, and neither one is memory of past conversations.
The first is the codebase index. Cursor's context and search documentation describes Instant Grep, a search engine Cursor built specifically to outrun ripgrep on large repositories, running automatically whenever the Agent references a symbol, with an Explore subagent for broader questions. It's fast, and it runs without configuration. It is also, by design, a search tool over the code that exists right now. It has no concept of a decision made and later reversed, or a tradeoff that was discussed and never written down.
The second is rules. Cursor's rules documentation states the design intent plainly, explaining that rules "provide persistent, reusable context at the prompt level" because the model itself can't. Project rules live in .cursor/rules as .mdc files, version-controlled with the repo; a simpler AGENTS.md in the project root works too, without the frontmatter overhead; and user rules apply globally across every project for one person's own preferences. Rules are real persistence. They're also entirely manual. A rule only exists if someone wrote it, and it only stays accurate if someone updates it when the reasoning changes.
Neither mechanism reaches outside the repo. Cursor does support connecting to MCP servers for exactly this kind of gap, configured project-wide or globally in an mcp.json file, but Cursor's own docs describe MCP as a way to connect external tools and data sources generally. There's no built-in memory server bundled in, so if the "why" behind a decision lives in a support ticket rather than in a rules file, Cursor has no path to it unless a team wires one up.
The decision Wesley didn't write down
Six weeks ago, in a Cursor session that's long since closed, Wesley Tran made the call that the transaction ledger at Bluecrane Systems would be append-only rather than updated in place. Every correction would get written as a new row referencing the one it corrects; nothing would ever be edited or deleted. Wesley builds ledger infrastructure for Bluecrane's mid-market payment-processor customers, and the decision came out of a call with one of them, Meridian Processing, whose team had been burned by a competitor's system silently overwriting a disputed charge and losing the audit trail a regulator later asked for. He mentioned the reasoning in that day's Cursor chat, shipped the migration, and moved on to the next ticket.
Last week, a different engineer on Bluecrane's team opened a fresh Cursor session to speed up a slow query against the ledger table, and asked the Agent to look at it.
Engineer, in Cursor's Agent mode: This ledger query is doing a full scan because we've got years of correction rows stacked on top of the originals. Can you refactor this to update the original row in place instead of appending corrections?
Agent: That would simplify the query significantly and should improve performance. I don't see any comments or tests that depend on the append-only pattern, so updating in place looks safe from what I can find in the code.
The Agent searched the right table, found no comment explaining the pattern, and reasoned correctly from what it could see. What it couldn't see was the customer call that made append-only a compliance requirement rather than a style preference, because that call happened in a video tool and a Slack recap, not in the repo Cursor indexes. If the engineer had shipped that "obvious" cleanup, Bluecrane would have quietly rebuilt the exact failure mode the ledger design exists to prevent, for the exact customer who'd already been burned by it once.
The DIY layer, and what it's good for
Once a team hits this a few times, the standard responses show up in roughly this order:
- Write it into
.cursor/rulesorAGENTS.md. A line like "ledger rows are append-only, never updated in place, see the Meridian Processing call notes from six weeks back" costs nothing to add and Cursor loads it automatically into every session from then on. - Keep a running decisions doc. Cheaper than rules for narrative context, though it lives outside Cursor's automatic context and someone has to remember to open it.
- Bolt on a memory MCP server. Tools like CORE build a persistent knowledge graph of decisions, preferences, and goals, and connect into Cursor, Claude Code, and Codex through a plugin, closing the "new chat, blank slate" problem for architectural context specifically.
All three genuinely work for what they're built for, which is architecture and code-shaped decisions that engineers already know are worth writing down. Rules and memory MCPs both depend on an engineer recognizing, in the moment, that a decision matters enough to type it somewhere the agent will see it later. That trigger fires reliably for "why is this code weird." It fires far less reliably for "a customer asked for this and here's exactly what they said," because that fact usually lives in a support conversation an engineer never opens, tagged to a person a coding agent has no way to identify.
The part no rule or memory MCP reaches
That's the gap that doesn't close with better rules discipline, because it isn't a documentation problem. It's a routing problem. The reasoning behind a change request lives in whichever tool the customer used to make it, tagged to a name and an account, and nobody transcribes that into .cursor/rules as a matter of course. A memory MCP built for architecture will happily remember "the ledger is append-only." It has no reason to also know that the requirement traces back to Meridian Processing specifically, or that the append-only design exists because Meridian had already been burned once by the alternative.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in Notion
CursorThis is the narrower thing Modem is built for. It reads Slack, Discord, support tools, and sales calls, clusters what it finds into topics with the original requester and their exact quote attached, and exposes that as an MCP server any MCP client can query, Cursor included. Through Modem's Cursor integration, the Modem agent pulls the relevant bug reports and customer quotes straight into a Cursor Cloud Agent's task brief, so the agent doing the work starts from the actual request instead of reconstructing it from a code comment that was never written. It targets your connected repos and reports back with the PR link when the task finishes. Modem doesn't compete with a rules file or a memory MCP; it covers the slice neither one reaches, which is why a change was asked for and who's waiting on it. If you want the different kinds of "agent memory" spelled out before you pick a tool, our explainer on the different kinds of memory lays out where each type ends. If Modem's approach specifically isn't the fit, the six best tools to give Cursor customer context covers the alternatives.
The one habit that catches most of this
Before reaching for a new tool, start smaller. The next time a Cursor session makes a decision that traces back to something a customer said, write one line into .cursor/rules naming the customer and linking the thread, right then, in the same session. That single habit catches a real share of what memory MCPs and customer-context tools exist to automate, and it costs nothing to try first. It just doesn't scale past the point where remembering to do it becomes the bottleneck, which is usually sooner than teams expect.
