The Agents Were Following the Process
My AI agents kept stating stale facts as current. The cause was hiding in my own instructions.
Last week I sat down to review a document that existed for exactly one reason: to fix the problem of my AI agents stating stale information as if it were current fact.
Inside it, I found a stale snapshot stated as current fact.
The builder assigned to implement the fix caught it. That was the seventh time in one session that an agent in my fleet had asserted something outdated as if it were live truth. And the seventh one was hiding inside the cure.
I want to walk you through what we found when we finally stopped blaming the agents, because the answer turned out to be about my business, and probably yours, more than it was about AI.
Last week I published the full checklist I run before trusting any AI output. If it didn’t hit your inbox, it’s here. Its third check, did I verify it or did I trust the report, is the one this whole story is about. This was the week that check earned its keep inside my own system.
Seven wrong facts, zero lies
Here’s the part that made this hard to diagnose. None of the seven assertions were hallucinations. Every single one had been true when someone first observed it.
A queue that had been empty was reported empty, hours after it filled. An email described as “scheduled for tomorrow” had already been rescheduled by another process. A deployment URL that was correct on Friday was quoted confidently on Sunday, after it changed.
The information had simply expired between the writing and the reading. That difference matters, because you can catch a lie with a fact-check. An expired truth passes every fact-check you run against the moment it was written.
The investigation that pointed back at me
I run a small fleet of AI agents that draft content, manage publishing, watch queues, and coordinate through a shared database. When the stale assertions kept coming, we did what you’d do with an underperforming employee: we studied the employee.
Four separate expert reviews analyzed the agent’s behavior. Detailed, thoughtful work. Then an independent reviewer did something none of the others had done.
It read the standing orders.
Our operating instructions declared one planning file “the single source of truth for session state” and told every agent to read it first, before anything else. That file held 670 lines of append-only history. Entries from days and weeks earlier, stacked oldest to newest, under a heading that called itself Session State.
Every line in that file was a dated historical claim. Every agent had been instructed to read it as current fact.
The agents weren’t violating the process. They were following it.
I’ve been building software for twenty years, and I still needed an outside reviewer to see it. When every actor in a system makes the same mistake, the instructions are the suspect, and the instructions were mine.
Assertion laundering
That’s the name for the mechanism, and naming it is important, because once you name it you see it everywhere: assertion laundering.
An unverified claim gets written into a status document. The document gets read as evidence. A summary quotes the document, a handoff quotes the summary, and three retellings later nobody remembers that no one ever checked the original claim against reality. The claim didn’t get more true along the way. It just got harder to trace.
Your business does this. Mine did. The status deck that says the integration is “on track” because the last deck said so. The wiki page describing a process the team abandoned in March. Each was true once. Each is read as true now.
A document is not a status. Anything append-only is a stack of dated historical claims, and the moment someone reads it as “the current state,” the laundering has begun.
Why “be more careful” was never going to work
My first instinct was to add a rule. Something like: verify information before asserting it. We actually had versions of that rule already. The agents ignored them, and it turns out they were being economically rational.
I measured what verification costs in my stack. A full state refresh means about fifteen separate reads across the systems that hold real truth. The single cheapest one costs 3.6 seconds of wall clock. Recalling something from notes costs nothing, and it feels exactly as certain.
That’s the whole contest. Fresh truth costs seconds and effort. Stale memory is free and feels identical. A rule that says “be more careful” asks every reader, human or AI, to keep paying a tax that laziness refunds instantly. That gradient wins every time, in my fleet and in your Monday standup.
So the fix can’t be a plea for discipline. It has to change what the data itself looks like.
The fix: make freshness visible
What shipped is small and boring, which is usually a good sign.
First, every state read in the fleet now leads with a timestamp. “AS OF 07:03 UTC,” stamped by the system that answered, and stamped only when the read actually succeeded. A claim without a timestamp is visibly naked now. You can’t quote it without noticing you don’t know how old it is.
Second, the 670-line file got restructured. The current-state section is 15 lines. The history didn’t get deleted, it moved below the fold and got labeled as what it always was: history. The file went from 840 lines to 871 in total. We removed nothing. We just stopped letting the past wear the present’s name tag.
Honesty requires me to tell you this fix is a first tier, and a reviewer has already found two defects in it. That’s fine. The goal was that a stale claim now looks different from a fresh one, so catching the difference stops depending on anyone’s virtue.
The test for your own business
You don’t need an agent fleet for this to bite you. You need exactly two things: a document people trust, and time.
So here’s the test I’d run on any document your team treats as truth. Pick a load-bearing claim from it and ask when it was last observed, by whom, against the real system. If the answer is a date, you have a status. If the answer is “it’s in the doc,” you have laundering.
The uncomfortable version: the more trusted the document, the better the laundering works. Nobody re-verifies the source of truth. That’s what makes it one.
Do this in the next ten minutes
Open the one document your team treats as current truth. The status page, the master tracker, the handoff doc.
Find the three claims that would cost you the most if they were stale. Next to each one, write the date it was last verified against the actual system rather than against another document. If you can’t produce a date, mark the claim “unverified as of today.”
That’s it. The process is still unfixed, and you’ve already done something better: you’ve made the staleness visible, and visible problems are the only kind that get fixed.
P.S. It took an outside reviewer to spot what my own instructions were doing, and that’s not an accident. You can’t proofread your own operating assumptions. That’s exactly what the AI Workflow Audit is: 30 minutes of checking what’s actually true about where your hours go, instead of what the docs and the habits claim. Short intake, a working call, and a written map of your highest-impact automation opportunities, ranked. Ten founding-rate spots this week: audit.g8n.ai



