Why does Cursor forget my architectural decisions?

Cursor forgets your architectural decisions because Project Rules describe behavior rather than rationale, Memories are short summaries derived from chat, and ADRs in /docs only show up in the prompt when retrieval surfaces them. The model defaults to industry-standard architectures whenever decision context is missing. The fix is to expose decisions as queryable memory Cursor reads before proposing architecture.

Cursor indexes your repo and retrieves relevant chunks per turn. Architectural decisions slip through that pipeline for three reasons.

1. The why is harder to retrieve than the what. Codebase indexing surfaces code well and prose less reliably. An ADR in /docs/adr/0017-single-postgres.md only enters the prompt when retrieval scores it relevant to the current query, and "I am adding a new service" rarely scores a decision doc highly.

2. Project Rules carry the rule, not the reason. A rule that says "use a single Postgres" is enforceable. A rule that explains "we chose a single Postgres because two-phase commits across services were unacceptable for our consistency model" does not fit in .mdc frontmatter, so the rationale gets lost, and the model fights the rule whenever the surface task seems to call for a second DB.

3. Memories are summaries, not decision records. Cursor's Memories auto-generate short rules from chat. They are not a decision log. The reasoning that informed an architectural choice, the trade-offs considered, the constraints that mattered, do not survive as structured Memory.

The result: Cursor follows decisions when they happen to be in context and overrides them when they are not.

Every forgotten decision costs you a re-argument and sometimes a re-implementation, and the cost compounds across a service's lifetime:

• Settled debates reopen. "We chose Postgres over Mongo because of JSONB queries and transactional integrity" becomes invisible, and Cursor suggests Mongo again three months later.
• Constraints get violated. "We do not call internal services from edge functions because of cold start budget" gets ignored in a generated edge handler.
• New services drift from the standard. Cursor reaches for the most common pattern on the web for new services, not the one your platform team standardized on.

The fix is not "make every ADR also a .mdc rule." That floods the rules folder with prose nobody maintains. The fix is to expose decisions as queryable memory with their rationale intact.

Cursor has shipped real features here. None of them fully close the gap.

*Project Rules (`.cursor/rules/.mdc)** can encode the rule from an ADR, with frontmatter and globs to control when it fires. They are good for the enforceable conclusion. They are weak at the rationale, since alwaysApply` rules share prompt budget and longer rule prose gets trimmed.

Memories capture short, auto-generated guidance from chat. They are good for "we use Zod for runtime validation" and bad for "we chose Zod over Yup in 2024 for the static-type inference, and we revisit this decision quarterly."

Native MCP support lets Cursor connect to external memory through .cursor/mcp.json or the Settings UI. This is the cleanest path for architectural decisions, because MCP can expose the full ADR with rationale on demand instead of compressing it into a rule.

You can read Cursor's own MCP setup guide in the official Cursor docs.

For small repos, Rules and indexing handle it. For systems with a real architecture, decisions slip.

The deeper issue is that architectural decisions are reasoning artifacts, not rules. They need to be retrievable in full, with their why, their alternatives, and their date, the moment Cursor proposes something that would violate them. They also need to apply across every AI editor the team uses, since one teammate on Claude Code can otherwise re-introduce the pattern you spent a sprint removing.

That is what a cross-tool memory layer fixes: one decision record, retrievable on demand, shared across every AI editor on the team.

MemoryLake is a cross-model memory layer that sits between you and every AI you use. Instead of trusting that ADRs in /docs will be retrieved when they matter, you store decisions in a MemoryLake Project, and Cursor pulls the relevant one per turn through MCP.

• Decisions as queryable memory. Each ADR lives as a structured Memory with rule, rationale, alternatives, and date. Cursor retrieves the full record, not a compressed line.
• Git-style version control over decisions. When an ADR gets superseded, MemoryLake's version control tracks the supersession, so old decisions cannot quietly resurface.
• Portable to every other AI coding tool. The same decision memory works in Claude Code, Cline, Windsurf, and any MCP-aware editor. A teammate on a different tool cannot re-introduce a deprecated pattern by mistake.

MemoryLake scored 94.03% on the LoCoMo long-context benchmark, the top published result as of 2026, with millisecond retrieval and AES-256 end-to-end encryption.

1. Create a project and load your decisions. Sign in to MemoryLake, open Project Management, click Create Project, and name it after the system (for example, "Cursor - payments-platform architecture"). Drop your ADRs and design docs into the Document Drive. Capture the headline conclusions and rationales as structured entries in the Memories tab so each decision is retrievable by topic, with the why intact.
2. Generate an MCP Server endpoint. Open the MCP Servers tab inside your project, click Add MCP Server, name it "Cursor integration", and click Generate. MemoryLake returns an API key ID, secret, and endpoint URL. Copy the secret immediately, since it is shown only once.
3. Connect Cursor. Cursor has had native MCP support since 2025, which makes this the cleanest path. Add a MemoryLake server entry to .cursor/mcp.json at the repo root (or wire it through Cursor Settings > Features > MCP), paste the endpoint URL and Bearer token, and reload Cursor. Cursor can now query the decision record before proposing architecture or wiring a new service.