Cursor Memory Bank: what actually loads

If you have tried to make a coding agent remember your project between sessions, you have met this pattern. A folder of markdown files in the repository, and an instruction telling the agent to read them first. It has a name, it has a canonical implementation for Cursor, and it has a mechanical question underneath it that the English videos about it do not open.

This is the written half of a video, Cursor Memory Bank: What Actually Loads, and the sections below follow its eight chapters in order, so anyone arriving from the end card can pick up where they stopped. Every claim here was re-checked against its source on 8 September 2026 rather than taken from the film.

TL;DR

• Fifty five rule files, and one of them is guaranteed to reach a session. Fifty three carry alwaysApply: false, one is a one byte stub with no frontmatter at all, and exactly one carries alwaysApply: true.
• That one file is about writing. It declares eleven canonical entries and closes with a mandate to check the path before any create or edit. It never tells the agent to read anything.
• The readme answers the same question the other way, and the pair is the whole mechanism: a section on progressive rule loading names main.mdc as a core rule always loaded first, and main.mdc's own frontmatter says alwaysApply: false.
• The author said all of this first, in public, unprompted. His readme calls the project a personal hobby project. His release notes name the determinism paradox and answer it in three words: guiding rather than forcing.
• When the read does not happen, nothing errors. In the forum thread with the most posts on this pattern, three people say it inside eight days, including the person who started the thread, and the characteristic reply doubts the person rather than the mechanism.
• Cursor is the whole test of whether the editors made this unnecessary, and the answer is stranger than either version of that argument.
• Disclosure is the next section rather than the footer, and our row is the only one this article demands anything of.

There are no performance numbers in this article, ours or anyone's. A number is the output of a recipe, this page is not showing a recipe, and a number without one is not something you can check.

Disclosure, and it goes first

Before anything else: we build Mnemoverse, a memory layer for AI agents that connects over MCP. So a vendor in this category is writing about a free community pattern that competes with it. Our row goes first, and it is the only row in this article that anything is demanded of.

Here is where we lose. Our own published answer to "the agent ignores memory" is the pattern this article is about. Our documentation tells you to paste a standing instruction into CLAUDE.md, .cursor/rules/mnemoverse.mdc, AGENTS.md or .github/copilot-instructions.md, and on that same page it says: "Connecting Mnemoverse gives your agent the memory tools. It does not guarantee the agent uses them." The rule file our own Cursor plugin ships carries alwaysApply: false, which is the same frontmatter setting as Memory Bank's entry rule. Whatever this article establishes about a prose rule reaching a session applies to ours in the same words.

Three more, all checkable without taking our word for any of it. Our API reference says consolidation, the forgetting we advertise, is off on the hosted service, that the endpoint answers 503 instead, and that it "has never once completed on the hosted service". No MCP tool of ours corrects or removes a memory: deletion was withdrawn to an administrative REST operation in August, the corrective write shipped on the REST API only, and our own page says "No MCP tool in this package exposes it yet." And the description on the front page of our public repository still advertises memory that "learns and forgets" with "recall fades by recency", a claim our own changelog withdrew: nothing time-decays, nothing is auto-deleted. It is still there while you read this.

A file in your repository needs no account, no key and no network, and it is already installed. We need an account, a key and a network.

1. Who wrote the first memory bank, and what was in it

It starts with one person and one file. On 17 December 2024 at 21:13 UTC, Nick Baumann committed a 168 line file to his own repository, nickbaumann98/cline_docs, in a folder called custom instructions library. Three weeks later, on 9 January 2025, it entered the Cline product repository in a commit titled, simply, Add docs.

Three things about that origin are worth getting right, because the field mostly gets them wrong.

The folder was not called memory-bank and it held five files, not six. The original says to create a cline_docs folder and maintain productContext.md, activeContext.md, systemPatterns.md, techContext.md and progress.md in it. There was no required project brief. The six file memory-bank/ version everybody installs today arrives later, in a rewrite.

The voice was second person. Every description of this pattern quotes its first person opening, the one where the agent introduces itself and explains that its memory resets. The origin file does not say that. It speaks to the agent rather than as it:

You are Cline, an expert software engineer who maintains perfect documentation due to periodic memory resets. This unique constraint is your strength - it drives you to keep clear, up-to-date project context at all times.

The first person arrives in the same rewrite that turned five files into six, so the version people cite and the version people install both come from the rewrite rather than from the original. Either way, that framing is why it spread. It does not read like configuration. It reads like an explanation of why the configuration is necessary.

And the original carried machinery that has since been dropped, including an update trigger expressed as a dollar amount:

When you get to around ~$1.50 in tokens, tell Cline "your memory is about to be wiped, update cline_docs so that you can pick up right where you left off".

That sentence is not on the live page today. It is the clearest thing in this whole corpus about how fast hand written guidance ages, and it will matter again in the section about staleness.

2. What you get when you install the big one

The canonical implementation for Cursor is vanzan01/cursor-memory-bank. Its star counter read 3,058 on 8 September 2026. That is a count of stars, not of users, and the difference matters later.

Two paragraphs into that readme, its author tells you what it is: a personal hobby project he develops for his own use, with no issues tracker and no active collection of feedback. He wrote that himself, before any of this was a criticism, and section 4 quotes him in full. Everything below is a reading of a design whose own author has already described its limit.

What you get is not a pile of prompts. It is a design.

Six slash commands form a closed loop. .cursor/commands/ holds exactly six markdown files: van.md, plan.md, creative.md, build.md, reflect.md and archive.md. Typing /van inserts that file's text as a prompt, and that is the entire trigger. Four complexity levels genuinely change the path, the smallest skipping planning and design entirely and the largest running every stage. The build command carries a real gate, in one line of plain instruction: - Do NOT proceed to next phase until all tests pass.

It does not shove all of that into your context at once, and saying otherwise is the easiest way to be wrong about it in public. The repository's first line describes it as "A token-optimized, hierarchical task management system", it ships a dedicated rule for progressive loading at .cursor/rules/isolation_rules/Core/hierarchical-rule-loading.mdc whose frontmatter reads description: Hierarchical rule loading system for optimized token usage, and fifty three of its fifty five rule files are conditionally attached rather than always applied. If you have heard a memory product contrast itself against this pattern on the grounds that the pattern loads everything every session, that comparison loses to anyone who opens the repository.

Clearing is documented, and the gap is narrower than the obvious complaint. The /archive command is documented in the readme under "/archive - Task Archiving" and its own file says - Clear completed task details from \memory-bank/tasks.md` (keep structure)and- Reset `memory-bank/activeContext.md` for next task`. What the repository does not document is a size limit or a token budget. That absence was checked across the whole git tree at the pinned commit, readme, release notes, optimization notes, all fifty five rule files and all six command files, with a control: the word token occurs on 96 lines in that tree and a nonsense control string occurs on none, so the negative result is real and not a broken search.

The maintenance record is better than a hobby project has any right to be. This system originally ran on the version of Cursor custom modes that the vendor withdrew: the changelog entry for 2.1, dated Nov 21, 2025, says "Custom modes have been removed, with the ability to export as custom commands." Issue #42 in the repository reported it the same day. The commit moving the whole mechanism onto slash commands is dated 3 December 2025, it came from an outside contributor rather than from the maintainer, it was merged as pull request #44, and release 0.8-beta published on 5 December 2025. Twelve days from the vendor's announcement to a released system on a new foundation, on a project whose readme says it collects no feedback.

That is worth holding in mind before the next section, which is a criticism of the design and not of the work.

3. Is the rule guaranteed to be applied?

Here is the question the whole pattern rests on. When you open a new session, is the agent guaranteed to read those files?

Start with the vendor rather than with us. From Cursor's rules documentation:

If alwaysApply is true, the rule will be applied to every chat session. Otherwise, the description of the rule will be presented to the Cursor Agent to decide if it should be applied.

The behaviour table on the same page puts both halves in the vendor's own words. For alwaysApply: true: "Always included. Globs and description are ignored." For alwaysApply: false with a description: "Agent reads the description and pulls the rule in when relevant." One of those is delivery. The other is a decision made by the thing you are trying to instruct.

So the question becomes arithmetic on the frontmatter, and the arithmetic is short.

There are fifty five rule files, all of them under .cursor/rules/isolation_rules/. Counted from a fresh clone of the pinned commit on 8 September 2026, with a control pass confirming that no .mdc file exists anywhere else in the tree. The unit is files.

• Fifty three carry alwaysApply: false. They attach only when something asks for them.
• One carries no alwaysApply key at all, because it has no frontmatter and no content: .cursor/rules/isolation_rules/visual-maps/van_mode_split/van-qa-checks/file-verification.mdc is one byte long, and that byte is a space. Two other live files in the same repository have similar names, so the full path matters here.
• Exactly one carries alwaysApply: true.

Fifty three plus one plus one is fifty five, with nothing left over. That one file is Core/memory-bank-paths.mdc, one thousand seven hundred and twenty three bytes, and it is the only text in the system guaranteed to reach every session.

It is not the file you would expect. It opens like this:

CRITICAL: All core Memory Bank files reside within the memory-bank/ directory at the project root. Do NOT create or modify these files outside this directory unless explicitly instructed for archiving purposes.

It then declares eleven canonical entries, and the unit is worth naming because the repository's readme counts differently: eleven list entries, made of eight file paths and three directory templates for creative documents, reflections and archives. And it closes with this:

Verification Mandate: Before any create_file or edit_file operation on these core files, verify the path starts with memory-bank/. If attempting to create a new core file (e.g., tasks.md at the start of a project), ensure it is created at memory-bank/tasks.md.

That is a real instruction and the agent really is given it, every time. It is an instruction about writing. A case-insensitive search of that file for read, load, consult, review, open, import and ingest, counted as whole words, returns zero matches. The same search on Core/hierarchical-rule-loading.mdc, sitting in the same directory, returns eight, so the zero is a fact about the file rather than about the search. Counted as substrings instead of whole words the guaranteed file returns one, the letters read inside the word ready, in a sentence about clearing tasks.md, which is not a reading verb either.

Nowhere in the one file guaranteed to arrive is the agent told to read anything.

Everything else is advisory twice over. A human types a slash command, which inserts a prompt, and the model then chooses whether to obey lines that read Load: .cursor/rules/isolation_rules/main.mdc under a heading that reads ### Step 1: Load Core Rules (Always Required). The heading is prose. The word required is prose. There is nothing underneath either.

And the readme answers the same question the other way, which is the whole thing in one pair of files. Under a section headed Progressive Rule Loading:

1. Core Rules - Always loaded first
   • main.mdc - System foundation
   • memory-bank-paths.mdc - File path definitions

Open main.mdc and its own frontmatter says:

description: Optimized main rule for improved token efficiency
globs: main.mdc
alwaysApply: false

The readme promises always. The metadata the editor actually reads says otherwise. The promise is in prose, and prose is the part nothing enforces.

If that sounds like a complaint about one repository, it is not, and the cleanest statement of why belongs to Cursor. On the same rules page, describing team rules that a member cannot switch off, the vendor writes:

Some teams use enforced rules as part of internal compliance workflows. While this is supported, AI guidance should not be your only security control.

That is the strongest form of the mechanism, described by the people who built it, and they still call it guidance.

4. The author said it first. The branch says it again.

Everything above, the author knew, and wrote down himself, in public, before any of it was a criticism. The second paragraph of that readme:

Personal Note: Memory Bank is my personal hobby project that I develop for my own use in coding projects. As this is a personal project, I don't maintain an issues tracker or actively collect feedback.

Nobody made him write that. Then, in the shipped release notes, comes the concession a critic would otherwise have to work to extract:

While Memory Bank provides robust structure through visual maps and process flows, it's important to acknowledge an inherent limitation: the non-deterministic nature of AI agents.

He names it himself in the same section:

This creates what I call the "determinism paradox" – we need structure for reliability, but rigidity undermines the adaptability that makes AI valuable.

And then he says what the design does about it, in three words that describe this pattern better than anything written about it since:

• Guiding rather than forcing: Using visual maps that shape behavior without rigid constraints

That is the shipped version. There is also a branch, and it needs care, because it is easy to describe wrongly.

What the branch is. claude/pensive-hamilton-vGehn, one commit, dated 26 May 2026. Three files added, none deleted, none modified. Compared against main on 8 September 2026 it is one commit ahead and zero behind, so it has not been merged. No pull request was ever opened for it, checked both by listing every pull request the repository has ever had and by asking GitHub which pull requests are associated with that commit, which returns none. Meanwhile main has not moved since 7 January 2026.

Who wrote it, both halves. The commit is authored and committed by an agent account, not by the person who wrote the repository. The branch itself was created in the repository by the maintainer's own account, which the repository activity log records as the single event on that branch and, as of today, the most recent event in the repository at all. So the branch is not the author's own concession, and it is also not something he had nothing to do with. Both halves belong in the same sentence, and neither of them is a gotcha.

What the branch says. It adds a document that calls itself "This file is the always-on contract for any agent working in this repository." It announces that the design has been replaced:

The legacy .cursor/rules/isolation_rules/ tree has been retired.

and lists where the behaviour went, including:

.cursor/hooks/ (enforcement, formerly prose "🚨 CRITICAL" rules)

and states the consequence:

Skipping a required mode is a hard error and is blocked by the pre-tool-use hook.

What is actually on the branch. All fifty five rule files, byte for byte identical to main. No hooks directory, no subagents directory, no skills directory, no legacy directory. The string hook occurs four times in that document, counted by hand, and matches zero paths anywhere in the repository's tree, on that branch or on any of the other three branches. A live request for the hook file it names returns 404, against a control request for a file the branch really does add, which returns 200 with a real body.

And the commit that added the document says so itself, which is the part that makes this fair rather than pointed:

Lays the groundwork for the v0.8 → v1.0 rebuild. No behavior change yet; the legacy isolation_rules/ tree still drives the system.

Inside one commit, the tree of rules has both been retired, in the document's past tense, and still drives the system, in the commit message. Nobody is being caught out here. The document is a plan, it says it is a plan, and the plan has not run.

The lesson is the film's and it is the reason this branch is worth a paragraph at all. A document announcing that enforcement had moved out of prose and into code is itself prose, describing code that has not been written yet. A sentence saying a rule is enforced is still a sentence, and it stays one however seriously it is meant.

5. What it looks like when the files are not read

So what happens when the read does not occur?

Nothing errors. The agent does good work, from the wrong context, and nobody is told.

The clearest public record of that is a Cursor forum thread from 21 March 2025, which on 8 September 2026 carried 25 posts, 11 participants and 13,827 views. To be exact about what "the main thread" means: it is the thread with the most posts and the most participants among the forum topics named for Memory Bank. It is not the earliest and it is not the most viewed, and two other threads asking the same question predate it.

One scoping note first, because it changes what the thread proves rather than weakening it. That thread teaches a single file port of Cline's memory bank into Cursor, not the fifty five file repository above, and the rule it tells you to create is declared alwaysApply: true in its own first post. So the people below are not describing the big repository. They are describing a rule that was declared always applied.

Inside eight days, three separate people report the same thing, including the person who started the thread.

The thread's author, on the second day:

for my project, sonnet 3.7 ignores the rules sometimes. I don’t know why. maybe, the context window might be limited..?? or just the intelligence is not enough..?

The next, a day later, trusting the construction less and asking directly:

But what are you doing when Cursor continuously ignore rule's reading?

The third, five days after that, reporting both the failure and the self-suspicion in one message:

As for the Memory Bank, except that it records my project at initialization, it doesn't seem to be called by the cursor at all in subsequent interactions. I really think the Plan/Act mode + memory bank process is a waste of money and time. Is it because I'm using it the wrong way?

Look at the shape of that. He doubts himself, not the mechanism. That is characteristic rather than isolated: the same person writes, later the same day, "But this might also be because I let the cursor follow the plan step by step without specifying that it should only complete one step... I'll try to constrain it to only complete one step in the plan." Against three messages doubting the user, the thread carries one doubting the construction. When a mechanism fails silently, the person using it assumes the fault is theirs.

The remedy the thread offers is the setting that was already on:

You can change the "Rule Type" to "Always". Then don't need manual operate mention it.

And the ending is quiet rather than dramatic. Eight days after opening the thread, its author writes:

Recently, I don't use any rules including this memory bank rule. I tried some, but i turned out that the default cursor agent mode just works well without any instructions or rules.

Nothing broke. Somebody stopped.

The same failure has a cleaner write-up on the protocol version of this idea. A user of the MCP fork ran a connected server for weeks and the bank stayed empty. His entire issue body is "Everything looks good, except I can't see any files created at the location for memory bank to use after weeks use of Claude code." The next day he worked it out himself: "I got it, I thought it's an automatic tool, but it's not..."

The maintainer's answer has two halves, and most people would quote the first:

One cannot enforce an MCP tool to be called by an LLM if not through a "wrapper" (like Cline for instance). Even with an AI "wrapper" there is no guarantee that an LLM will follow instructions. LLMs are non deterministic.

He does not stop there, and cutting him off where he stops sounding pessimistic would be exactly the selective edit this article should be accused of. In the same comment:

Did you add the custom instructions mentioned in the docs to claude code? LLMs tend to follow them and always consult the memory bank when planning work. Also writing to it after work is done.

That is the pattern's own maintainer saying that it usually works and cannot be guaranteed. From the vendor's side, an account carrying Cursor's staff, admin and moderator flags put the same thing in one sentence, in a Cursor forum thread from May 2026:

I agree that relying on the model to trigger retrieval is brittle in practice.

The second failure mode is staleness, and it is not our observation. It comes from the same account in the same thread as the sentence above, so this is one vendor-side voice quoted twice rather than two voices agreeing, and it should be counted once. In that thread, dated 6 May 2026 and carrying 47 posts, the forum's own admin, an account in the CursorStaff group, ranks how context setups break. First place:

Commands and paths change. This is the most common case.

Second place:

AGENTS.md gets outdated. This is second place. Users update code and forget the docs. The drift utility I mentioned earlier exists for exactly this reason, it's the most boring and most common failure mode.

Fairness needs his rule of thumb in the same breath, because it cuts against any blanket attack on files:

If I had to pick one rule of thumb, anything that duplicates info already in code or config will go stale over time. Anything that just points to that info tends to stay correct.

Two scoping limits on that quotation. He names AGENTS.md and editor memories; the string memory-bank does not appear in his message, so this is about context files in general and not about that repository by name. And his fifth item is the one this article is about, described as a tax rather than a break: "Agents don't load the right context. This is more of a constant background tax than a sudden break."

One absence, with its surfaces named. No English language video appears to examine the guarantee question. On 8 September 2026 I ran five YouTube searches, cursor memory bank, cursor memory bank not working, does cursor actually read memory bank, cursor rules alwaysapply ignored and cursor memory bank alwaysapply, and pulled the automatic caption track for five English videos those searches returned. None of the five asks whether the rule is guaranteed to arrive; the closest describes alwaysApply true and false as a file matching mechanism without asking whether the rule reaches the session at all. That is a statement about search result pages and caption tracks. It is not a statement about the field: comments under those videos were not read, an anonymous fetch of YouTube ignored the upload date sort, non-English videos were not swept in full, and other video platforms were not swept.

6. Did the editors' own memory make this unnecessary?

There is a fair objection to all of this. The editors have their own memory now. Why keep a folder of files? The honest answer is stranger than either version of the argument, and Cursor is the whole story.

Cursor built the in-house answer. It arrived in the changelog entry for 1.0, dated Jun 4, 2025:

With Memories, Cursor can remember facts from conversations and reference them in the future. Memories are stored per project on an individual level, and can be managed from Settings.

That release was a beta, off until you switched it on, and note where you switched it on:

We're rolling out Memories as a beta feature. To get started, enable from Settings → Rules.

Even the vendor's own memory feature arrived inside the rules pane. It went generally available a month later, in the entry for 1.2, dated Jul 3, 2025:

Memories is now GA. Since 1.0, we've improved memory generation quality, added in-editor UI polish, and introduced user approvals for background-generated memories to preserve trust.

Then it left the editor, and the public account of that is a support thread rather than a release note. On 24 November 2025, answering a bug report on Cursor's own forum, a member of Cursor staff wrote: "The Memories feature was removed starting from version 2.1.17, so it no longer appears in your current version (2.1.25)." The next day, in a second thread, the same account wrote that it was "intentionally removed starting from version 2.1.x." Six weeks later the same account narrowed it. On 7 January 2026: "Even though this feature was removed from Cursor, it still works, just without a UI." On 10 January 2026, answering somebody whose agent had reported that the memory tool did not exist: "The Memories feature hasn’t been removed. In version 2.1.x, only the UI to manage it was removed. The feature itself still works."

Four public statements, one staff account, seven weeks apart, and they do not agree about whether the feature exists. Read together, what went away at 2.1.17 is the interface. What happened to the rest is not stated on any Cursor surface I could reach, and I am not going to guess.

The changelog does not settle it either, and the count is the check. I fetched all 251 entries in Cursor's changelog archive on 8 September 2026, every one at HTTP 200, walking the index page by page until the pagination ran out and the next page returned 404. The unit is entries, not mentions. The feature name Memories appears in two of them: 1.0, dated June 4, 2025, and 1.2, dated July 3, 2025. Thirteen more entries use the word memory for RAM, for memory leaks, or for an SDK store, and two use it for the notes a cloud automation keeps between runs. No entry announces a withdrawal, and the string 2.1.17 appears in none of them.

There is a plainer reason the withdrawal never reached a changelog entry, and it is worth stating rather than implying. Cursor used to publish patch level notes inside the minor version entry: the 1.7 entry of September 29, 2025 lists 54 patch versions by number. The 2.1 entry of November 21, 2025 lists none, and neither does any entry after it. 2.1.17 is a patch release in a range where Cursor no longer publishes patch notes at all. And the 2.1 entry does announce a removal in its improvements list, a different one: "Custom modes have been removed, with the ability to export as custom commands." So this is not a house style of saying nothing. It is a change that fell below the level the changelog still describes.

On the documentation, the claim has to be about pages and only about pages. There is no Memories reference page in Cursor's editor documentation today. cursor.com/docs/context/memories redirects to cursor.com/docs/rules, and a control request for cursor.com/docs/context/zzqqxx-nonsense-control returns 404, so the redirect is a decision rather than a catch-all. cursor.com/docs/memories returns 404. The documentation index at cursor.com/llms.txt, 20,174 bytes on 8 September 2026, contains no occurrence of the string memor across the 93 help pages and the docs pages it lists. Those are the surfaces I checked, and that is a statement about pages. It is not a statement about the feature. The vendor's own January reply is the reason to keep the two apart: it says the feature still works. The one surface not covered is application release notes at patch level, because those have not existed since 2.1.

The part that matters most is where the vendor sent people. In both November replies the route is the same: "You can export your memories and move them into Rules:", by pressing a command palette shortcut, typing Export memories, and getting an .mdc file. The .mdc extension is the format of a Cursor rule file. The second reply spells out the destination: "You can then add the exported content to your Rules (Cursor Settings → Rules, Memories, Commands → User Rules or Project Rules)."

Rules is Cursor's own feature and always has been, so this is not a vendor endorsing anybody's project. It is more interesting than that. Asked where the memory should go now, the editor that had built the in-house answer and taken it out of the editor said: into files of prose in your repository. Which is the shape the community had already settled on.

And what Cursor ships under that name today has the same shape. From the cloud automations documentation:

Memories let the agent read and write persistent notes across runs for the same automation. Use this to build agents that remember and improve over time. Each memory is stored as a named entry (MEMORIES.md by default) that exists outside the agent's working filesystem.

A named markdown file the agent reads and writes between runs. Same shape, one difference the vendor states on the same page: it lives outside the agent's working filesystem, so you edit it from Cursor rather than from your repository. That place is most of what the last two sections are about.

On the other side of the pattern's origin, nothing replaced it. Cline's documentation index at docs.cline.bot/llms.txt, fetched the same day, lists exactly one entry whose text contains the word memory, and it is the community Memory Bank page itself. There is no vendor memory feature page there to compare against.

Two more things Cursor documents that cut in the pattern's favour, and one distinction they make sharp. From the rules help page: "Create an AGENTS.md file in your project root. Write instructions in plain markdown. Cursor picks it up automatically." And on the same page: "CLAUDE.md files are always applied to every conversation, regardless of any alwaysApply frontmatter setting."

Notice what kind of guarantee that second one is. It is a property of the client, which puts the file in the conversation without asking the model. It is not a property of the sentence inside the file. That distinction is the whole subject of this article, and the vendor draws it again in its prompting documentation, where the two lines sit next to each other in a list of what occupies the context window:

• Rules: project and user rules included in the prompt
• Skills: skill descriptions injected into the system context

So the verdict for this section is not that the pattern was replaced. One editor built the alternative, took it to general availability, took the interface for it out, told its users to move the contents into rule files, and now ships a memory that is a named markdown file. The other never shipped one. What changed since 2025 is not the pattern. It is that the vendors converged on the same artifact and the same admission.

7. What a file does that a memory layer does not

We make a memory layer, so this is the section where the comparison runs against our own product. Our limits are in the disclosure at the top, with the pages they come from. Here is the comparison itself, and the files win most of the rows.

	a folder of files in your repository	our hosted memory layer
Visibility	visible, diffable, reviewable in a pull request	a query against a store, reviewed by nobody on your team
Prerequisites	no account, no key, no network, already installed	an account, a key and a network
Writing	always succeeds	passes an importance gate our own changelog says rejects corrections, because a correction looks like a near duplicate of the thing it corrects
Correcting	an agent edits or deletes in place and the old line leaves the diff	no MCP tool of ours corrects or removes; the corrective write is REST only, and our reference says it "records the correction; it does not yet hide the original"
What comes back	the contents arrive whole and identical	a ranked result whose size we do not guarantee: our own package documentation calls top_k "Not a hard cap: association expansion can return more, and the relevance floor can return fewer"
Restoring	git clone	export exists, and our reference says "there is no import endpoint"
Quota and vendor	neither	both

One row goes the other way, and it is narrow. The store is not in the repository and not in the editor. A fact written from one client is readable from another, on a different machine, in a different project, with no shared checkout. That is a real problem and it is not the problem this article is about.

And on the exact question this article is about, we are where everybody else is. Our own instructions tell you to paste a standing instruction into your rules file. Our shipped Cursor rule carries alwaysApply: false, the same setting as this repository's own entry rule. Our documentation page for making an agent use memory says it in one line of its own: "But a tool being available is not the same as the agent calling it."

8. So what actually loads

The title asked what actually loads, so here is the answer without hedging.

One file out of fifty five, and it tells the agent where to write, not what to read. Everything else depends on a human typing a command and a model choosing to follow a sentence. That is the same arrangement in the protocol version of this pattern, in Cline, and in ours.

None of that makes the pattern bad. It makes one expectation wrong, and we have already published the sentence for it:

If you have written a rule down, watched your agent read it back to you, and then watched it do the thing anyway, nothing was ever stopping it.

That applies to us on the same terms, and the same page says so:

If what you need is for something to not happen, no memory layer will do it. Not ours, not anyone's.

And if what you need is the same instructions in front of the model every session, the answer is a folder of files in your repository, not a product. Ours included:

It is free, you can read it, your team can review it in a pull request, and it is already installed. For a lot of people that is the entire answer and there is nothing to buy.

The person who built the largest version of this pattern got there first. He named the paradox himself and wrote guiding rather than forcing into his own release notes, which describes what these files do more honestly than most of what has been written about them since.

So take the distinction he drew. Guiding is what a file does. Forcing is a different mechanism and you have to go and get it. A rule that has to hold belongs somewhere that runs, not somewhere that is read, and the difference is invisible right up until the moment it matters.

A ten-minute check on your own repository

Do this before believing any comparison, including this one.

Clone the memory bank repository you actually installed and count its rule files by frontmatter rather than by reputation: how many carry alwaysApply: true, how many carry false, and how many carry no such key at all. The three numbers should add up to the number of files, and if they do not, your search is wrong before your conclusion is. Then open whichever files come back as always applied and read them for verbs: a file that only tells the agent where to write is not going to make it read. Then ask your agent, in a fresh session and before typing any command, to state the contents of your memory bank back to you. If it cannot, the files are not arriving, which is a delivery problem with a delivery fix. If it can, and it then works from the wrong context anyway, delivery is fine and nothing is enforcing, which is a different problem with a different fix and no amount of stronger wording in the file will touch it.

Related

• CLAUDE.md, AGENTS.md and Cursor rules do not enforce: the prior question, whether an instruction file binds anything at all, in three vendors' own words
• What survives when AI agents restart: the client side, five coding tools on resume, compaction and built-in memory, with the same Cursor history in shorter form
• MCP memory servers for Claude Code and Cursor: the protocol side of the same choice, and the row that actually decides it
• AGENTS.md: what supported actually means: the delivery half, tool by tool, when a file is picked up and when it is quietly skipped

---

Every claim on this page was checked live on 2026-09-08 with full browser headers, with negative results controlled and quotations taken from extracted page text or from raw source files rather than from rendered HTML, because markup breaks a sentence across tags. The repository figures come from a fresh clone of vanzan01/cursor-memory-bank at commit 7d879d8f5079ad77d845fdc92ca03903dbbd3a85, counted with find and grep rather than with a recursive glob, because a recursive glob on Windows silently drops the longest paths in that tree and returns 48 files instead of 55. Word counts in this article are whole-word matches and line counts are lines, not occurrences, and each is named where it is used. Byte sizes are taken from git objects rather than from disk, since a Windows checkout converts line endings and inflates every total. Forum quotations are taken from the Discourse JSON with raw markdown included, and where an author's apostrophe differs between the raw text and the rendered page, the raw form is the one quoted. Cursor's changelog was walked page by page to the end of its pagination, 251 entries, each fetched individually. Where this article states an absence it names the surfaces the sweep covered, and the one surface it could not cover, Cursor's patch level release notes, is named rather than left out. Quotations keep their author's punctuation, including the en dash in the release notes, the arrow in Cursor's changelog and in a commit message, and the emoji in a branch document, which is why those characters appear inside quotation marks in a text that otherwise uses none. Disclosure: we publish a memory layer that competes with the free pattern described here, the disclosure is the second section rather than the footer, and our own limits are named before anybody else's. There are no performance numbers in this article, ours or anyone's.