Originally published on contextforge.dev.
Two weeks ago Claude Code and I spent an afternoon on the ContextForge landing page. We decided it would be fully static, regenerated in the background, and that the live numbers would stream only in the admin. We measured it, it was faster, and I wrote the reasoning into the pull request. The following Tuesday a fresh session looked at the same page and proposed making it dynamic "so the stats are always fresh." Same model, same repo, opposite decision, delivered with total confidence.
If you've searched for why AI coding agents contradict earlier decisions, you've had a Tuesday like that. Here's the honest answer, and it isn't the one I expected when I started digging.
TL;DR: The agent isn't changing its mind. Either the decision never reached the session you're in, or it arrived stripped of the reason behind it. There are five ways that happens, and each one has a cheap fix. The expensive part is turning the fix into a habit.
It's not memory loss. It's missing input.
A language model doesn't hold opinions between calls. Every answer is computed from what's in front of it right now: your prompt, the files it opened, the conversation so far. If a decision isn't in that input, the agent isn't ignoring it. It's reasoning from the code as it is today, and in the code as it is today, the dynamic version of my landing page looks perfectly sensible.
So the frustrating question, "why does it keep contradicting me?", turns into a more useful one: "why wasn't the decision in its input?" I found five reasons. Here they are in the order I hit them.
1. The decision lives in a chat you closed
The obvious one. You and the agent worked something out in a conversation, the conversation ended, and the next session started from nothing. Claude Code can reopen a past session with --resume, and for the same machine and the same repo that's often enough. I wrote about where that stops in Claude Code session handoff.
Fix: anything you'd be annoyed to explain twice, write down somewhere the next session will read before it starts working.
2. Compaction summarized it away
This one bites inside a single session. When the context window fills up, Claude Code summarizes the conversation and continues from the summary. The summary keeps "we're working on the landing page." It drops "static, because streaming cost 40 ms and nobody needs live stats on a marketing page." Ten minutes later the agent is cheerfully proposing the thing you ruled out, and from inside the session there's no seam to notice. I dug into the mechanics in why your session forgets mid-task.
Fix: keep decisions outside the transcript and put them back after every compaction. Claude Code has a hook for exactly that moment.
3. You switched tools
Cursor in the morning, Claude Code in the afternoon, Copilot for the review. Each one has its own context, its own rules file, its own idea of your project. A decision made in one of them never visits the others. This is why the contradiction so often shows up as "but we agreed on this yesterday," when yesterday was a different tool. More on that in how to share context between Claude Code and Cursor.
Fix: one place every tool reads from, instead of one notes file per tool.
4. Your instructions file says one thing and the code says another
CLAUDE.md, .cursor/rules, copilot-instructions.md. You write them once, carefully, and then the code moves on without them. When the file says "we use library X" and the code has quietly migrated to Y, the agent has to pick a side, and it picks differently on different days. A stale instructions file is worse than none, because the agent trusts it. I've made this mistake enough times to write why your CLAUDE.md goes stale about it.
Fix: treat rules files as living documents. Prune them when a decision changes, and date the decisions you keep there.
5. You saved the what, not the why
This is the sneaky one, and the one I see most. The commit says "remove cache layer." An agent reading that learns there was a cache and now there isn't. It does not learn that the cache added latency for nothing. So the next time it meets a slow endpoint it does what any good engineer would do: it adds a cache. It isn't contradicting you. It's following the only reasoning it can see.
A decision without its reason is just a fact waiting to be overturned.
Fix: one sentence of why, every time. "Removed the cache layer: it added 40 ms and nothing read it twice." That sentence is what stops the re-litigation.
Where to keep a decision so the agent finds it again
| Place | What it keeps well | Where it fails |
|---|---|---|
Rules files (CLAUDE.md, .cursor/rules) |
Standing conventions, how to behave | Drifts, no per-decision reasoning, one file per tool |
| Git commits and PRs | What changed and when | The why is thin, and agents rarely read history unless told to |
| ADRs in the repo | The full reasoning | Someone has to point the agent at them, and nobody updates them |
| Memory over MCP (ContextForge and others) | Decision plus reason plus date, searchable from any tool | Only holds what was saved, and needs a one-time setup |
None of these is wrong. The mistake is expecting a rules file to carry decisions, or a commit log to carry reasons.
What I do now
I built ContextForge because I was losing this argument with my own agents several times a week. The idea is small: when we decide something, the agent saves the decision with the reason, in the project's memory. The next session, in Claude Code, Cursor or Copilot, loads that memory over MCP (Model Context Protocol) and can search it by meaning, so "landing page rendering" finds the static-page decision even if nobody used those words. After a compaction, a hook prints the latest decisions and open tasks back into the context. And when the code behind a memory changes, a freshness check flags it so the agent can confirm, correct or forget it instead of defending something that's no longer true.
Setup is one command:
claude mcp add contextforge -s user \
-e CONTEXTFORGE_API_KEY=your-key \
-- npx -y contextforge-mcp
Now the honest part.
- It only recalls what was saved. The habit of saying "save that, with the why" is the real product. The tool just makes the habit cheap.
- It won't stop an agent from arguing. It gives the agent the reason not to. That's usually enough, and sometimes the agent is right and the old decision deserves a second look.
- A stale decision in memory gets defended faithfully. Freshness checks catch the cases tied to code changes. They don't replace your judgment on the rest.
- It's an early product from a small team. It works for me every day. It still has rough edges, and I'd rather you hear that from me.
FAQ
Would a bigger context window fix this?
No. A bigger window lets one session hold more, and it still ends when the session ends. Most of the five causes above happen between sessions or between tools. I wrote a longer answer in bigger windows won't save you.
Doesn't Claude Code's auto-memory already handle this?
Partly. It's useful for the agent's own notes, and it stays on that machine, inside that tool. The moment you open Cursor or a laptop at home, it's not there.
Should I just put every decision in CLAUDE.md?
It'll work for a while. Then the file grows until the agent stops honoring half of it, and you're back to cause number four. Keep conventions in the rules file and decisions, with their reasons, somewhere searchable.
One thing to do today
Write down the last three decisions you made with an agent, each with a single sentence of why. Put them where the next session will read them: your rules file at minimum, a memory layer if you have one. Tomorrow, before you ask the agent to build anything, ask it "what did we decide about X?" If it answers correctly, you've just closed all five causes for that decision. Then do it for the next three.
Top comments (0)