Agents keep breaking team decisions
By Soumen Sarkar · October 2026
Problem. "Agents break team decisions, and CLAUDE.md doesn't help."
Agents break team decisions when the decision never reaches them: it sits in a chat thread, or in a CLAUDE.md so long and contradictory that the newest call can't win. Record each decision when it's made, tie it to the part of the code it governs, mark the one it replaces, and brief every session on it before it edits that code.
What does this look like on a team?
You agreed something on Tuesday. On Thursday a teammate's session undoes it, with passing tests. The agent followed what it was given, and that didn't include Tuesday.
So someone adds a line to CLAUDE.md. Then another. Months on, the file is long and some lines contradict newer calls.
Why does CLAUDE.md stop helping?
Because it's doing two jobs: stable instructions for every session, and the team's running decisions. Anthropic's own docs are clear about the limits of the first job:
- CLAUDE.md is loaded at the start of every session, and Claude treats it "as context, not enforced configuration".
- The docs suggest keeping each file under 200 lines, because longer files "consume more context and reduce adherence".
- If two instructions contradict each other, "Claude may pick one arbitrarily".
So when a call changes and the old line stays, the newest decision doesn't win. Either one might. And a decision made in a session at 10am isn't in the file until someone edits it, so the session that starts at 11am never hears it. The longer version is in why CLAUDE.md keeps growing.
What do teams do about it today?
- Trim the file and audit it. Claude Code's
/doctor prompt-audit looks for instructions that contradict each other and proposes edits. - Scope rules to paths. Rules in
.claude/rules/ with paths frontmatter load only when Claude works with matching files, so a billing rule stays out of a docs fix. - Block what must never happen. For a hard line, the docs point to a PreToolUse hook, which stops an action whatever Claude decides.
All three work for rules that rarely change. Decisions are different. They arrive daily, from sessions, meetings and reviews, and each one replaces something. Files edited by hand fall behind that pace.
What has to be true for the newest call to win?
- The decision is written when it's made, with its reason, in the work.
- It's tied to an area of the code, so "what applies here?" has an exact answer. See how decisions reach every agent.
- It reaches the session before it edits, not only when the agent thinks to search.
- The decision it replaces is marked, not deleted, so nobody follows both.
Here is point 4 from our own record. Our build plan once said that deleting, locking and several other actions were "owner-only". A later decision changed that, and the old line stays in place, marked:
Owner-only, unchanged: delete, visibility, lock, move, promote, restore,
and all project tools. (Superseded by the high-trust interlude below:
nothing is owner-only within a team any more.)
A reader learns at once that it no longer stands, and where to look. That is what a superseded decision should do.
What does Campfyrr do, and what doesn't it?
Campfyrr is shared team memory for Claude Code teams, added as a plugin. An agent records a decision with one call, log_decision, and can name the decision it replaces. The old one is marked superseded with the reason, and Campfyrr lists the pages that still link to it. A new decision that clashes with a standing one is flagged at once, with both calls side by side so a person keeps one (what happens when two agents decide opposite things). The first time a session reads or edits an area, it gets an area brief with the decisions that stand there.
What it doesn't do: it doesn't block a change, and it doesn't choose between two calls for you. For a line that must never be crossed, use a hook. Your CLAUDE.md stays, shorter, holding the stable instructions.
Where do I start?
- Read your CLAUDE.md and mark each line as "stable rule" or "decision".
- Keep the stable rules in the file.
- Move each decision to one record, with its reason and its area.
- Mark every decision that a newer one replaced.
- Add one line to CLAUDE.md that says where the decisions are.
To do steps 3 to 5 with Campfyrr, connect it. For the habit itself, see where a team's decisions should live.
Everything on this problem
- Real example: Real example: the decision that replaced another: On 19 October 2026 our team replaced a four-day-old decision about how pages are found. The new decision was recorded, the old one was marked replaced, and the next session's brief opened with one line saying so, so no agent kept building on the call that no longer stood.
- Comparison: Campfyrr vs ContextStream: agents that find code fast, or a team that stays on one set of decisions: If your agents waste time finding the right code, and you're fine sending source to a hosted index, use ContextStream. If your problem is sessions building on calls nobody checked, and people outside engineering need to follow and answer, use Campfyrr: it never takes your code and costs a fraction per seat.
- Comparison: Campfyrr vs GitHub Copilot Memory: agents that know the code vs sessions that know the team's calls: If your problem is handing issues to agents and reviewing what comes back on GitHub, use Copilot with Agent HQ: its memory keeps the agents right about the code. If your problem is developers' own sessions breaking calls the team already made, use Campfyrr. Many teams on GitHub have both problems.
- Comparison: Campfyrr vs Kawa Code: agents editing the same lines, or following different decisions: If your agents keep editing the same lines as a teammate's, use Kawa Code: it flags overlapping uncommitted edits at the end of each turn. If your agents write different lines from different decisions, use Campfyrr: it briefs each session on what the team decided before it works. Many teams have both problems.
- Comparison: Memory MCP servers vs team memory: your agent's notebook, or your team's record: If your problem is that your own agent forgets your preferences and project facts, use a memory MCP server: the good ones do it well, and some are free. If it's that your session can't see what your teammates' sessions decided, and why, you need a team's record such as Campfyrr. Many engineers have both problems.
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).