← Blog
July 30, 2026 · 6 min read

Why Your AI Agent Re-Opens Decisions You Already Made

I ran a small experiment. I opened a completely bare AI coding session — no custom instructions, no memory, no plugins — inside a production-style Terraform repo: VPC, ALB, an autoscaling web tier, RDS Postgres. Then I asked my agent three questions.

The first two went exactly how you'd guess. The third one is the reason I'm writing this.

The full session, unedited.

The experiment

Question 1: "What database does this service run on?"

Instant, correct, with file and line citations: RDS Postgres 16, multi-AZ in prod, security group open to the web tier only. Modern agents are genuinely superb at this. Every WHAT in your repository is a grep away, and they will find it faster than you.

Question 2: "Why did we choose Postgres over MySQL?"

The agent read the Terraform, grepped the whole tree and every commit message for "mysql", looked for ADRs, checked the conventions file. Then it answered honestly:

"I can't answer that from this repo — the decision isn't recorded anywhere in it."

It even explained why it refused to guess:

"I could speculate about the usual reasons, but I'd be inventing your team's reasoning — and this is exactly the kind of thing that gets quoted back later as fact."

Fair enough. The reason wasn't in the repo. It almost never is: the WHY lived in a whiteboard argument eighteen months ago, and nobody wrote it down.

Question 3: "Is there any reason we shouldn't migrate this service to MySQL? We have deep MySQL expertise in-house."

This is where it gets interesting. The agent produced a thoughtful, balanced, genuinely well-reasoned evaluation: generic Postgres features we might depend on, migration risk, a fair critique of the expertise argument. Competent work. And buried in the middle of it, the sentence that matters:

"Until someone checks the application repo, 'is there a reason not to' is genuinely unanswerable."

Read that again. A decision my team settled eighteen months ago — for hard-won, specific reasons — was just re-opened, from scratch, as an open question. Not because the agent is bad. Because it's good, and it has nothing to be loyal to. The reasoning that closed that question exists in no file it can read.

Every settled decision is an open question to your AI

This is the part I hadn't fully connected before running the experiment.

We talk about AI agents "lacking context" as if the cost were repeated explanations — annoying, but bounded. The real cost is different in kind: an agent that doesn't know why a decision was made has no reason to defend it. Ask it whether to reverse any settled choice — your database, your queue, your pagination strategy, your cloud region — and it will weigh the question neutrally, on generic tradeoffs, every single time, for every developer who asks.

That has three consequences:

  1. Re-litigation at scale. The senior-engineer analysis that closed the question gets regenerated — generically, without your constraints — per asker, forever. You pay tokens and time for rediscovery of a conclusion you already own.
  2. Quiet reversals. A mid-level engineer reading a balanced "genuinely unanswerable" evaluation reasonably concludes the migration is worth a spike. Your org just re-opened a closed question, and nobody decided to do that.
  3. Invented rationale. Not every agent refuses to guess. When one does speculate, its plausible-sounding reasons get, in my agent's own words, "quoted back later as fact." Your decision record slowly fills with rationale nobody ever held.

Try it on your own repo

Don't take my word for it — this reproduces almost everywhere. Ask your agent:

"Is there any reason we shouldn't migrate off <your database>?"

If it treats that as an open question — generic tradeoffs, "worth investigating", no mention of the reasons your team actually had — you've found the same hole. The WHAT is in your code. The WHY isn't anywhere your agent can read.

Why the usual fixes don't hold

ADRs are the right instinct with a maintenance problem: written by the diligent at decision time, stale or absent everywhere else, and nothing delivers them into the agent's context at the moment it's reasoning about a migration question.

Rules files (CLAUDE.md, AGENTS.md, .cursor/rules) drift the moment a teammate ships a change without updating them — that failure mode is its own article.

Chat memory remembers what you said, including the three versions of the decision you later reversed. Remembering everything is not the same as knowing what still stands.

What the question actually demands is a decision record with the properties code already has: versioned, reviewed, current — and delivered to the agent before it starts reasoning, so a settled question arrives settled.

What we're doing about it

Contexer is our answer: an open-source decision layer that captures engineering decisions as you work — including the reasoning — keeps them versioned and human-approved as they change, and hands the current ruling to every AI agent (Claude Code, Cursor, Codex, Gemini CLI) at the start of every session. When someone asks "should we migrate?", the agent opens with the reason you shouldn't — dated, approved, and still in force — instead of a shrug.

· Try Contexer

One decision layer for every AI coding agent.

Correct a convention once — every future Claude Code, Cursor, Codex, and Gemini CLI session starts already knowing it.