A copy of the rules in every tool is not decision memory. .cursor/rules, CLAUDE.md, AGENTS.md, and pasted system prompts are per-tool, per-repo copies — duplicated, unversioned, and disconnected from the decision that created them. They feel like memory, but they drift into silent conflict, and nobody can say which copy is current or which one wins.
Why teams reach for rule files
When a coding agent does something off-convention, the instinct is right: tell it the rules. So you add a .cursor/rules file. You write a CLAUDE.md. You drop an AGENTS.md in the repo. You paste a system prompt into a chat. Each of these genuinely helps that one agent, in that one tool, for a while.
The trouble starts when you have more than one of anything — more than one repo, more than one tool, more than one developer.
The four failures of scattered rule files
1. Duplication. The same rule now lives in five places. Update it in one and the other four are wrong. There is no single source of truth, so there is no reliable answer to “what’s our rule about this?”
2. No versioning or ownership. A CLAUDE.md edited four months ago by someone who has since left the team looks exactly as authoritative as one written yesterday. There’s no owner, no review, and no record of why the rule exists — so no way to tell whether it still applies.
3. Silent conflict. Repo A’s .cursor/rules says one thing; repo C’s says the opposite. Both are checked in. Both are “true.” The agent follows whichever one it’s pointed at, and the contradiction surfaces only when two pieces of work collide.
4. Disconnected from the decision. A rule is the consequence of a decision. “Never store machine artifacts in Excel” exists because someone decided to standardize on JSON, for reasons. The rule file records the constraint but not the decision, the rationale, or the rejected alternatives — so when circumstances change, no one can evaluate whether to revise it.
Rule files vs. an approved decision layer
| Rule files (.cursor/rules, CLAUDE.md) | Approved decision layer | |
|---|---|---|
| Source of truth | One copy per tool & repo | One canonical registry |
| Versioning & ownership | None | Owned, reviewed, dated |
| Conflicts | Silent, discovered late | Detected across objects |
| Link to the decision | Rule text only | Rule linked to its decision + rationale |
| What the agent gets | Everything, always | Only what applies to the task |
| Governance | Anyone edits | Propose → human review → approve |
What an “approved decision layer” means instead
An approved decision layer is not another rule file in the cloud. It’s one canonical, governed registry that:
- imports, classifies, versions, and scopes rules and decisions;
- links each rule to the decision behind it, with rationale and rejected alternatives;
- detects conflicts across objects instead of letting them sit;
- renders only the in-scope subset to the right agent for a given task;
- keeps every imported or generated rule a candidate until a human reviews it.
That last point is the discipline that keeps the memory trustworthy. Agents can retrieve permitted memory and propose changes, but they never approve organizational memory on their own. A human decides what becomes trusted.
Do you have to throw away your rule files?
No. Think of .cursor/rules and CLAUDE.md as inputs — evidence of decisions your team has made. The move is to import them into one governed registry, reconcile the conflicts, link them back to the decisions they came from, and then let the registry render the applicable subset back to each tool. You keep working in Cursor, Copilot, and Claude Code; you stop maintaining five drifting copies of the truth.
If you’re new to the idea, start with what Decision Memory is, or see it applied in the coding-agent alignment use case.
One team. One workflow. One memory loop.
Test Decision Memory with a single agent workflow in 2–4 weeks.