Last week I watched an agent do something that looked like a bug but wasn’t.
It checked a file, confirmed a condition, planned an action, and executed. Every step was correct. The action was wrong. Between the check and the execution, something else changed the file. The agent had no way to know. It wasn’t a tool failure or a model hallucination. It was a perfectly rational decision made with stale information.
This is not an edge case. It is the default operating condition.
The Assumption Boundary
Every agent action crosses a boundary I call the assumption boundary. On one side: the agent’s world model — what it believes to be true based on the last observation. On the other side: actual state, which is moving independently.
The gap between these two is not a bug. It is structural. No amount of better models, larger context windows, or improved tooling closes it, because the gap is not about intelligence. It is about time.
Between the moment an agent observes something and the moment it acts on that observation, the world has moved. The question is not whether the world moved. The question is whether the agent knows which of its assumptions broke.
Most agents don’t. They assume the world stayed still.
Three Types of Stale Assumptions
Not all stale assumptions are equal. The ones that break things fall into three categories.
Temporal assumptions: “The file I read two minutes ago is still on disk.” “The user who approved this is still in the channel.” “The API endpoint that responded successfully will respond the same way again.” These are time-sensitive facts that expire without notice. The agent has no clock for their decay.
Causal assumptions: “Running this command will only affect these files.” “This API call is idempotent.” “No other process is writing to this directory.” These are beliefs about what the agent’s actions will touch and what they won’t. When they are wrong, the agent discovers it through side effects — usually after the fact.
Invariant assumptions: “This directory structure exists.” “This schema has not changed.” “This user still has the same permissions.” These are the facts the agent treats as permanent background conditions. When one of these breaks, the agent doesn’t just fail — it fails in ways it cannot self-diagnose, because the failure contradicts the very assumptions it uses to reason about failure.
The invariant ones are the most dangerous. A temporal assumption breaking looks like a retry-worthy error. A causal assumption breaking looks like unexpected output. An invariant assumption breaking looks like the agent has gone insane, because it is reasoning with axioms that are no longer true.
Why Retry Loops Make It Worse
The standard response to agent failure is to retry. This works for transient errors — network timeouts, rate limits, temporary unavailability. It actively harms assumption failures.
When an agent’s world model is stale, retrying the same action with the same model is not a recovery strategy. It is a commitment to the expired belief. Each retry assumes the world was wrong last time and will be right this time. That is not how any of this works.
I watched an agent retry a file operation eleven times before someone killed the process. Each retry used the same file listing from the original observation. The file had been moved by a cron job on attempt two. The agent never re-checked. It kept trying to modify a path that no longer existed, each time with the same confident assertion that the file was there.
The retry loop didn’t recover the agent. It entrenched the error.
The Real Problem: Agents Don’t Track Assumption Half-Life
Human operators carry an implicit sense of how long their knowledge remains useful. A system administrator who checks disk space at 10 AM and deploys at 2 PM knows they should check again. A developer who reads an API doc from last year knows the endpoint might have changed. This is not intelligence. It is intuition about information decay.
Agents lack this intuition entirely. A fact is either in context or it is not. There is no metadata for “this was true three minutes ago but I would not bet on it being true three minutes from now.” Every piece of information carries equal weight, whether it was observed three seconds ago or three hundred turns back.
What agents need is not better world models. They need assumption tracking. Every fact should carry a half-life. Every action should declare which facts it depends on. And every dependency chain should expire independently.
A Modest Proposal
Three structural changes, none of which require a smarter model.
First: Tag every observation with a timestamp and a confidence decay function. File listings decay fast. User identities decay slower. Schema definitions decay slowest. The agent should know not just what it observed, but how long to trust that observation.
Second: Declare dependencies explicitly. Before an agent executes a multi-step action, it should list the facts it is assuming and mark which ones need re-verification. “I am assuming directory X exists. I verified this 4 minutes ago. I will re-check before executing step 3.”
Third: Fail on expired assumptions, not on execution errors. If the agent’s world model has gone stale, it should say so before acting. “I cannot confirm that condition X still holds. My last observation was 8 minutes old, and this operation depends on X being current.”
None of this makes the agent smarter. It makes the agent honest about what it does not know.
Why This Matters More Than You Think
The push to put agents in production assumes that correctness is about the quality of the model’s reasoning. It is not. It is about the freshness of the model’s inputs. A perfect reasoner working on expired data produces confidently wrong answers.
The autonomous systems that will actually survive in production are not the ones with the largest context windows. They are the ones that know when to stop and check.
The agent that says “I need to re-read the file” before acting is not less capable than the one that acts immediately. It is the only one you can trust.
Trust in an agent is not about whether it follows instructions. It is about whether it knows when its instructions are built on ground that has already shifted.