Do you still need Backthread if you have CLAUDE.md, Cursor rules and Copilot Memory?

Yes, if the question is about people rather than about the agent. CLAUDE.md, Cursor rules and Copilot Memory exist so the agent starts each session knowing the build command and the house style. Backthread exists so a team shipping with agents keeps holding the reasoning behind its own codebase: it captures why each merged change was made, shows per area how much of the system the team understands, and teaches it back inside the agent.

The rest of this page is the detail: what each of the three context mechanisms actually stores, where it lives, how long it lasts, and the two things none of them attempt. It ends with the cases where a well-kept CLAUDE.md is the right answer and nothing more is needed.

What do CLAUDE.md, Cursor rules and Copilot Memory actually store?

All three are inputs to a model. They are read at the start of a session, or when a matching file is opened, and they shape what the agent does next. That is their whole job, and each does it well. The differences are in scope and lifetime.

CLAUDE.md and Claude Code auto memory

Claude Code has two mechanisms, and Anthropic's own documentation keeps them apart. CLAUDE.md files are instructions you write, at four scopes: a managed-policy file for the whole organisation, ~/.claude/CLAUDE.md for one user across projects, ./CLAUDE.md for the project (shared "via source control"), and a gitignored CLAUDE.local.md for one person in one project. The guidance is to keep a file "under 200 lines" and to fill it with "build commands, conventions, project layout, 'always do X' rules."

Auto memory is the notes Claude writes for itself: your corrections, your preferences, "decisions that Claude can't derive from the code or git history." It lives at ~/.claude/projects/<project>/memory/, and the documentation is direct about its reach: "Auto memory is machine-local. All worktrees and subdirectories within the same git repository share one auto memory directory. Files are not shared across machines or cloud environments." So the one place Claude Code records a decision on its own is the one place a teammate cannot read.

Cursor rules and Cursor Memories

Cursor's rules come in four kinds: Project Rules in .cursor/rules ("version-controlled and scoped to your codebase"), User Rules ("global to your Cursor environment"), Team Rules managed from the dashboard on Team and Enterprise plans, and a plain AGENTS.md. They merge in the order Team, then Project, then User. The rules page says why they exist in one sentence: "Large language models don't retain memory between completions. Rules provide persistent, reusable context at the prompt level."

Memories are the auto-generated counterpart, "stored per project on an individual level," per Cursor's 1.2 changelog, which also declared the feature GA. As of this writing the current docs site no longer carries a Memories page (the old URL redirects to the docs root, and the rules page does not mention them), so treat Memories as a personal convenience that may move, not as a team record.

Copilot Memory

GitHub's is the most interesting of the three because it is the only one that is shared by default and the only one with a lifetime. Copilot Memory stores "coding conventions, architectural decisions, build commands, and project-specific rules" as repository-level facts, "available to all users with access to Copilot Memory for that repository," plus per-user preferences nobody else sees. Facts carry citations to the code, and Copilot "checks those citations against the current branch to confirm the information is still accurate." And then the line that matters for this page: "Any stored fact or preference that goes unused is automatically deleted after 28 days." The March 4, 2026 changelog adds that memories are "strictly scoped to a single repository" and that on Business and Enterprise plans an administrator must enable the policy first. The feature is in public preview.

That deletion rule is not a flaw. It is a sensible design for a cache of facts the agent should not act on once they are stale. It is just a cache.

Where does each one stop?

The buyer's questions, side by side. Backthread's column is the product as it is today; the other columns are from the vendors' own documentation, linked under Sources.

Two rows carry the argument. Nothing in the first three columns is read by a person as a matter of course; a CLAUDE.md is something you write, not something you learn from. And nothing in the first three columns knows the difference between an agent that has been told "the ingest pipeline splits on heap pressure" and an engineer who could explain why. The context file makes the agent competent. It does not make anyone on the team competent, and it does not tell you whether they are.

Why "the agent knows" is not the same as "the team knows"

There is a tempting argument that goes: the agent has all the context, engineers ask the agent, therefore the team has the context. It holds for low-level questions. What does this function return, where is this configured. The agent answers those on demand and there is no reason to memorise them.

It fails for the questions a team actually gets hurt by. Why is the retry on the queue consumer and not on the producer? What did we give up when we chose one layout for every snapshot instead of one per version? Those answers were live in a session for twenty minutes and then the session ended. A CLAUDE.md does not record them, because it is a place for rules, not for history; Anthropic's docs tell you to move anything that is not an every-session fact somewhere else. Auto memory might record them, on one laptop. Copilot Memory might keep a fact with a citation for 28 days. Nowhere in that stack is the reasoning captured at the moment the work merges, held as a record of what shipped, and attached to the area of the system it changed. That is the mechanism described in an automatic decision log for code your agents write, and it is a different kind of object from a context file.

There is a second gap, and it is the one an engineering leader feels first. Anthropic's own study of 52 engineers found the AI-assisted group scored 50 percent on a comprehension quiz against 67 percent for those who coded by hand, with the authors' caveat that they measured comprehension shortly after the task. The team's context files did not get worse during that study. The people did. A better CLAUDE.md would have made the agent's output better and left that number where it was, because the file is written for the model.

Backthread's how-it-works view is built around that gap: the recorded reasoning on a map of the system, coverage per area (an estimate from git history first, capped at 50 percent and labelled, then earned by explaining decisions), and the teaching delivered in the agent while the engineer is already working on the code in question. The context file is what the agent starts with. This is what the team ends up holding.

Can't we just put the decisions in CLAUDE.md?

Teams try, and it is worth understanding why it does not last. Three reasons.

• It fights the file's purpose. Every CLAUDE.md line is loaded into every session and costs context; the documentation targets "under 200 lines" and warns that "longer files consume more context and reduce adherence." A decision log grows by the week. Ours passed four thousand entries on one repository. Within a quarter you are choosing between a useful context file and a complete record, and the record loses.
• Somebody has to write it, at the wrong moment. The reasoning is in the agent's head at the end of the session; the CLAUDE.md edit happens later, by a person, if at all. We measured this on our own repository: most agent-written decisions carry no alternative and no trade-off, and the ones that do are recorded because a hook made the same agent write them down while they were still in context. That is the idea behind the free add-reasoning-to-prs hook: catch the why at the moment it exists, in the PR, from the session that produced it.
• It still measures nobody. Suppose you did keep a perfect, curated decision log in a rules file. You would now have the record. You would not know which of your forty engineers had read it, could reproduce it, or would recognise the situation it applies to when it came up again in a different module. The record and the understanding are separate things, and the second one is what you are paying for.

None of this is a reason to stop keeping CLAUDE.md. Keep it, keep it short, and keep the history somewhere that is built to hold it.

When CLAUDE.md alone is enough

Some teams should read this page and not buy anything. When the team is five people who all sit in the same sessions, CLAUDE.md alone is the right tool, and a paid layer on top of it would be paying to formalise something the room already does. More precisely, a well-kept context file plus your existing PR descriptions covers the job when:

• Everyone who merges also designed. If the two people who hold the model of the system are the two people writing the code, there is no one to teach and nothing to measure. The floor is the whole building.
• The reasoning is written down elsewhere and read. A team with living ADRs, PR descriptions that name the alternative rejected, and a review culture that reads them, does not need automatic capture. Most teams believe they are this team. Count last month's merged PRs with a written "why" before deciding.
• Your problem is agent behavior, not team knowledge. If the pain is "the agent keeps using the wrong test runner," that is a CLAUDE.md problem, fully solved by a CLAUDE.md. Backthread does nothing about it.
• You are on one tool and one machine. A solo developer's auto memory is exactly as shared as it needs to be.

The signal that you have grown past the floor is usually one sentence in a leadership meeting: "I'm not sure anyone fully understands that service any more." A context file cannot answer that, because it was never asked. At that size, which in practice tends to be somewhere between ten and a hundred engineers, the price is $25 per seat per month with one repository included and $10 for each additional one, after a 14-day trial with everything on. Source is redacted on the engineer's machine before anything leaves it, and the redaction library is open so the claim can be checked; details on the security page.

Connect one repo and the first coverage picture is inferred from git and PR history the same day, capped and labelled as the estimate it is; the trial runs fourteen days and nothing is charged until it ends.