Why Your AI Keeps Suggesting the Thing You Already Rejected
You come back to a project after three weeks away. You open Claude Code, describe what you're building, and it...
You come back to a project after three weeks away. You open Claude Code, describe what you're building, and it confidently proposes an approach — the exact one you tried in June, watched fall over, and deliberately killed. Same idea, same enthusiasm, no memory of the funeral. So you explain, again, why it doesn't work. Then next month you explain it a third time.
This isn't the model forgetting a fact. It's forgetting a decision — the thing you tried, the reason you rejected it, and the line you drew. Facts and decisions fail differently, and almost every fix on offer only addresses the first one.
Why does AI keep re-proposing approaches you already rejected?
Because when a session ends, the reasoning behind your decisions is thrown away — and the model has no record that a choice was ever made and killed.
An agent's working context holds everything during a session: the approach you debated, the one you ruled out, the reason it failed at your write volume. That's live only while the session is. Coding agents parse a configuration file at startup and purge the ephemeral session reasoning once the session terminates. Next session, the agent reconstructs its suggestions from your code and your prompt — neither of which says "we tried this and it broke." So it lands on the same locally-reasonable idea it landed on last time, because from where it's standing, nothing rules it out.
This is the confident-wrong failure mode: the agent isn't hedging. It proposes the rejected approach with total certainty, because it has no way to know the idea already has a body count. It's a close cousin of the stale-context problem — right-sounding, authoritative, and wrong for a reason the model can't see.
Why don't CLAUDE.md and AGENTS.md fix this?
Because rule files communicate guidelines, not vetoes — and making them longer measurably hurts.
A CLAUDE.md is good at "use tabs, run the test suite before committing, prefer functional components." It's bad at "here are the fourteen approaches we've rejected and the specific reason each one died," because that list grows without bound and no one maintains it by hand. Decision history is append-only and project-specific; a rule file is a static snapshot someone has to curate.
And bloating the file backfires. According to a February 2026 arXiv study by Gloaguen et al. on agent context files, automatically generated instruction files decreased task success rates by around 3% while raising inference token costs by over 20%. More instructions isn't more reliability — past a point, it's less, at a higher price. The file that's supposed to carry your context starts taxing it.
So the rule file isn't where a growing log of rejected decisions belongs. It was never built for that job.
Doesn't Claude's memory already solve this?
No — and the reason is the one that matters most: the decision usually didn't happen in Claude.
You rejected that database approach in a GitHub PR review. You killed the pricing model in a Notion doc. You talked your team out of the rewrite in Slack. Claude's memory only knows what happened inside Claude conversations — so it has no idea a decision was made and buried somewhere else three weeks ago. It can't warn the agent off an approach it never witnessed being rejected. That single gap defeats platform memory before the other two problems even arrive.
The other two still matter. Memory synthesizes conversations into a profile — preferences, projects, recurring facts. A rejected decision isn't a preference; it's a specific chain with a dead end attached, and reactive summarization tends to compress the why out of it, if it keeps it at all. And it's Claude-only: even a perfect record inside Claude does nothing for Cursor or Codex, which cheerfully re-propose the same rejected thing because none of it travels. This is the difference between remembering facts and remembering decisions — and memory is built for the first.
What's the difference between remembering facts and remembering decisions?
A fact is a state; a decision is a state plus the path not taken.
"We use PostgreSQL" is a fact. An agent that knows it will use Postgres. But "we evaluated event-sourcing and rejected it because the team couldn't debug it under load" is a decision — and it carries a negative constraint the fact doesn't: don't propose event-sourcing, and here's why. Facts tell an agent what to do. Decisions tell it what to stop suggesting.
Most memory and context systems store facts well and decisions poorly, because decisions need three things preserved together: the choice, the alternatives considered, and the reason for the veto. Drop the reason and the constraint looks arbitrary, so the next model re-litigates it. Drop the alternatives and you can't tell whether today's suggestion is one you already ruled out. Negative constraints are the highest-value context an agent can have, and the least likely to survive a session.
How do you actually persist decision history for an agent?
You write decisions down in a structured, machine-readable place and serve them into the agent at session start — separate from your rule file.
The established pattern is the Architecture Decision Record (ADR): a short, dated file per decision capturing the context, the choice, the alternatives, and the consequences. ADRs have been a practitioner standard since Michael Nygard formalized them in 2011, and the format is having a second life precisely because it's readable by agents as well as humans. Tooling exists to make them agent-visible:
- ADR files in-repo — a
docs/adr/folder the agent can read. Cheap, version-controlled, but only as current as your discipline. - MCP-served decision logs — open-source MCP servers for ADRs inject decision records into an agent's startup context as structured data, so the "don't do X" constraints load before you type.
- Negative-constraint sections — an explicit "rejected approaches" log, kept separate from the guidelines in your rule file so it can grow without bloating the instructions the model reads every turn.
Each of these keeps the why attached to the what, which is the part that stops re-litigation.
Where does personal context fit?
Right where the other fixes stop: decisions don't live in your repo, and they don't live in your AI chat.
An in-repo ADR captures architecture calls. But plenty of the decisions your agent keeps re-deriving were made in a Notion doc, a GitHub comment thread, an email, a Slack argument — the places work actually gets settled. None of that is in docs/adr/, and none of it is in Claude's memory. It's scattered across the tools where the reasoning happened, invisible to every agent by default.
A personal context layer pulls decision history from those sources and serves it to any tool over MCP, so the veto you issued in a PR three weeks ago is loaded into the next session — in Claude Code, Cursor, or Codex, not just the one place it was recorded. The reasoning outlives the session and the tool it happened in. This is also why it should be context you own rather than memory locked inside one vendor: a decision that only lives in Claude dies with your Claude subscription, and it was never in Claude to begin with.
Unabyss maintains that layer — extracting the decisions and context from the tools where they actually happen, keeping them current, and serving them to every agent you use. Set it up once, and your agents stop pitching you the idea you buried in June.
[Get started free →]
