Why Your AI Agents Act on Stale Facts (and the One-File Fix)

For several weeks this year, every agent we launched refused a category of work we had explicitly permitted. The rule change was real, written down, and dated. The agents never saw it — because the script that briefs each agent at launch carried its own hardcoded copy of the old rules, and nobody remembered the copy existed. Nothing errored. Nothing looked broken. We just quietly paid for weeks of an agent fleet enforcing a policy we had repealed. That is the shape of the most expensive mistake in running a business on AI agents, and it is not a model problem. It is a filing problem: we let one fact live in two places.

A copied fact is a forked fact

Every operating fact in your business — a price, a policy, a brand value, a product count, a thing you no longer sell — has to live somewhere your agents can read it. The moment it lives in two somewheres, you have not made it more available. You have forked it. From that commit forward, the two copies are independent facts that happen to agree, temporarily. The day you update one, the other becomes a live landmine with your old decision inside it, and an agent will eventually step on it — because to a model, a confidently written stale fact is indistinguishable from a confidently written current one.

Humans survive this because humans get suspicious. A person reading a doc that contradicts what they heard in Tuesday's meeting stops and asks. An agent does the opposite of stopping: it acts on whichever copy landed in its context window, at machine speed, with machine confidence, in parallel across every session you have running. Duplication that costs a human team an awkward Slack thread costs an agent operation real money — wrong prices published, permitted work refused, correct work flagged as violations.

An agent executing a stale copy doesn't get suspicious. It gets confident.

Four ways the fork bites — all four from our own ledger

These are not hypotheticals. Each one is a dated entry in the failure log we keep on ourselves, and each one traces to the same root cause: a fact with more than one home.

1. The launch script with its own copy of the rules

The opener. Our agents spawn through a gate script that injects operating rules into every new session — which is the right idea. The wrong part: the script contained the rules instead of reading them. When leadership lifted four restrictions, the canonical rules file was updated the same day, and the hardcoded copy inside the script sat there for weeks, shackling every agent with constraints that no longer existed. The eventual fix was not updating the copy. It was deleting it: the script now renders the rules from the canonical file at spawn time, so there is nothing to drift.

2. The brand value every agent re-derived for itself

A brand color was missing from our canonical file, so each agent that needed it did the resourceful thing: derived it from artwork, screenshots, or older docs. Resourceful, and catastrophic — the hex value flip-flopped across nine files in a week, three different “official” values, each written by an agent certain it had found the real one. The lesson we wrote down afterward: if agents keep re-deriving a fact, the fact is missing from the truth layer. Re-derivation is not initiative; it is a gap report.

3. The verification tool that enforced a repealed fact

This one hurts because the tool's whole job was catching drift. Our quality gate — the script that has to pass before a deliverable ships — had a public-facing figure hardcoded into one of its checks. Then the decision behind that figure changed. The canonical file was updated; the gate was not; and our own verification layer started failing correctwork for matching the current decision. When the police carry a stale copy of the law, being right gets you arrested. Verification tooling must read facts from the canonical source or cite it — never embed a private copy.

4. The export that parsed perfectly and was four months old

A pipeline that selected our “newest” items was built on a data export sitting in the repo. The export parsed cleanly, had plausible dates, and looked authoritative. It was four months stale — it contained nothingreleased after its snapshot date, so the “newest items” selection was silently four months behind and structurally unable to pick anything new. No error, ever, because the failure mode of a stale snapshot is not a crash. It is a confident answer from the past. A snapshot file is a copy of a fact too, and it drifts the same way: any snapshot an agent reads needs a refresh step in the cadence, or it is rot with a filename.

Why this compounds in an agent operation

• Agents multiply the read count. A stale doc a human opens twice a year is opened by agents dozens of times a day. Every read is a fresh chance to act on the fork.
• Agents write more copies. Summaries, handoffs, generated docs, code comments — each is a new home for the fact, created faster than any human housekeeping can track. Fork count grows unless something structural stops it.
• Context assembly is invisible.You rarely know which copy a given session actually loaded. When two sessions disagree, both cite “the docs” — different docs.
• Stale facts pass every syntax check. Linters, parsers, and builds all bless a file whose contents were true in April. Currency is the one property no tool checks by default.

The truth-file pattern

The fix that ended this class of failure for us is small enough to describe in one sentence: every operating fact gets exactly one home, in one plain-text file, and everything else either reads it or cites it — nothing copies it. Ours is a JSON file; yours could be one page of markdown. The shape matters less than the monopoly:

truth.json
{
  "pricing":   { "consult_call": 150, "as_of": "2026-08-01", "set_by": "owner" },
  "policy":    { "refunds": "14 days, no questions", "as_of": "2026-06-12" },
  "brand":     { "primary_hex": "#0A84FF", "name_rule": "full name in public copy" },
  "dead_lanes": [ "cold outreach to past clients — killed 2026-05-19" ],
  "precedence": "truth.json > handbook > agent memory > anything an agent infers"
}

Four rules make the monopoly hold. Each exists because one of the failures above happened to us without it:

1. 1Consumers read or cite — never embed.Launch scripts, prompts, hooks and verification tools load the fact at run time, or reference it by key (“per truth.pricing.consult_call”). Any tool that hardcodes a value from the truth file is a fork waiting for its day. (Failures 1 and 3.)
2. 2Write the precedence order down. Agents encounter contradictions constantly — an old doc, a chat memory, a generated summary. Without a written ranking, each session resolves the conflict its own way. One line ends it: the truth file outranks everything, and anything that contradicts it is the thing to fix. (Failure 2.)
3. 3Facts carry provenance. Every entry gets an as_ofdate and who decided it. This is what turns “which copy is right?” from an investigation into a lookup — and it makes stale entries in the truth file itself detectable, because a two-year-old as_of on a volatile fact is its own alarm.
4. 4Snapshots get a refresh step or they don't get read. Any exported data an agent consumes for current-state decisions needs a regeneration command at the top of the workflow that uses it. If refreshing is not part of the cadence, the snapshot is not a source — it is a fossil. (Failure 4.)

The drift audit: find the forks you already have

You do not start clean; you start with forks already in the wild. One evening finds most of them:

1. 1List your ten load-bearing facts. Prices, turnaround times, the refund policy, what you no longer offer, the brand basics. If an agent stating it wrongly in public would cost money, it is on the list.
2. 2Search for each fact's literal value everywhere agents read. Grep the repo, the prompt library, the instruction files, the hook scripts, the docs folder — for the value itself (150, the hex code, the old policy wording), not the concept. Every hit outside the truth file is a fork: replace it with a read or a citation.
3. 3Search for the previous value too. The old price and the repealed rule find the copies that already drifted — the ones currently lying to your agents. These are the urgent ones.
4. 4Date-check every snapshot in the pipeline. For each exported file an agent reads, ask: what regenerates this, and when did that last run? A snapshot with no regeneration answer gets deleted or gets a refresh step — not a third option.
5. 5Re-run the audit on a schedule. Agents create new copies as a byproduct of working. A monthly thirty-minute sweep keeps the fork count near zero; a one-time cleanup just resets the clock.

The bottom line

Stale-fact failures never announce themselves — no stack trace, no error, just an agent doing last quarter's bidding with this quarter's confidence, and a bill that arrives later as refused work, republished old prices, or a pipeline that cannot see anything newer than its snapshot. The fix is structural and small: one home per fact, consumers that read instead of copy, a written precedence order, and a recurring sweep for forks. Build the file this week. If you want the whole method it belongs to — the truth layer, the gates, the pipelines, and the failure ledger behind them — that is The AI Operator Method ($97). How the broader instruction stack loads, and why instructions alone don't enforce anything, is covered free in how to write a CLAUDE.md that gets followed and how one person runs a whole company on AI agents.