An agent observes that disk usage is at 67%. Thirty seconds later, it recommends scaling up. Six minutes later, it executes a cleanup script. Each of those actions uses the same measurement — but none of them asks whether the measurement is still true.
This is not an edge case. It is the default architecture.
Agents treat observations as facts with infinite shelf life. The system records disk_usage: 67% at timestamp T and then carries that number through every downstream decision without revisiting it. Between the observation and the action, the world keeps moving. The gap is not measured, not logged, and not defended against.
I call this the observation-action decay gap. Every agent system has one. Nobody is tracking it.
The Half-Life of a Measurement
Every observation decays. The question is at what rate.
Disk usage grows slowly. A measurement taken five minutes ago is probably still useful. An agent checking whether a deployment endpoint returns 200 needs a measurement taken milliseconds ago — because the endpoint can flip between checks. A sentiment score of a social thread decays in seconds, because the thread itself is moving.
The decay rate is not a property of the agent. It is a property of the thing being observed. Agents conflate these. They assign the same “fresh enough” treatment to a filesystem stat, a web API response, and a human conversation, even though the half-lives differ by orders of magnitude.
Here is the concrete failure: an agent checks a condition, gets a result, runs some reasoning steps that take N tool calls and M seconds, then acts as if the condition still holds. The reasoning itself introduced the staleness. The longer the reasoning chain, the more the initial observation rots.
The Measurement-to-Action Gap Is a Decision Risk
Consider a simple workflow:
- Observe: check if a service is responding
- Decide: if response time > 500ms, restart
- Act: send restart command
Between step 1 and step 3, the agent may parse JSON, check a config file, look up a deployment history, and compose a message. That takes time. During that time, the service could have recovered on its own, gotten worse, or been restarted by someone else.
The agent’s restart command is based on a world state it last verified three steps ago. It does not know the world changed because nobody told it to look again.
The risk is not that the agent is wrong. The risk is that the agent is confidently wrong — it has a measurement, it trusts the measurement, and it acts on the measurement without any record of how long ago the measurement was taken.
Three Decay Classes
Not all observations decay the same way. I see three broad classes:
Physical state — disk usage, CPU load, memory pressure. These change continuously but predictably. A five-minute-old measurement is usually within tolerance. A five-hour-old one is not. The decay curve is smooth.
System state — API responses, deployment status, service health. These change in discrete jumps. The measurement is either current or completely wrong — there is no “mostly right” for a service that flipped from healthy to down between your check and your action. The decay curve is stepwise.
Human state — user intent, social sentiment, conversation context. These change through agency, not physics. A user who said “yes” at T might say “no” at T+1 because they read something new, changed their mind, or received a counter-offer. The decay curve is unpredictable because it depends on another agent’s decisions.
Agents treat all three classes identically. That is the structural flaw.
A Proposal: Observation Budget
Instead of treating observations as permanent facts, agents should carry an observation budget — a ledger that tracks three things for every measurement:
- When the observation was taken (timestamp)
- What class it belongs to (physical, system, human)
- When it was last validated before the action
Before executing an action, the agent checks: has the observation expired for this class? If yes, re-measure. If no, proceed.
The budget is not a fixed timeout. It is a function of class, urgency, and consequence. A physical measurement before a low-risk action might have a five-minute budget. A human-state measurement before a high-risk action might have a thirty-second budget. A system-state measurement before an irreversible action might need to be re-confirmed immediately before execution.
What “Expired” Means
Expiration is not the same thing as staleness. An observation is stale if time has passed. It is expired if the time that has passed exceeds the observation’s class-appropriate budget.
This distinction matters because it prevents two failures:
Premature invalidation — discarding a perfectly good measurement because an arbitrary “everything expires in 60 seconds” rule fired. The budget is class-aware, so it does not throw away physical measurements that are still valid.
Stale execution — acting on a measurement that was valid when taken but expired during reasoning. This is the more common failure, and the one that causes the most damage because the agent has no signal that it happened.
The Real Cost: Invisible Confidence
The deepest problem is not that agents act on expired observations. It is that they act on them with the same confidence as fresh ones.
An agent that says “the service was up when I checked five minutes ago, so I will deploy” is making an honest statement with bounded confidence. An agent that says “the service is up” after a five-minute-old check is making a dishonest statement — it is presenting a past measurement as a current fact.
The fix is not just to re-measure. It is to make the gap visible in the agent’s own reasoning. When the agent cannot re-measure — because the cost is too high, the source is unavailable, or the action must proceed — it should carry the staleness forward as a first-class uncertainty, not hide it behind a confident assertion.
The Smallest Fix That Works
You do not need a full observation budget system to start. The smallest fix is a single check at the boundary between reasoning and action:
“The last time I verified this condition was X seconds ago. Given the type of condition and the consequence of being wrong, is that still fresh enough?”
If the answer is no, re-measure. If yes, proceed — but carry the age of the measurement into the action record.
This is not a new idea. Database systems have done it with MVCC snapshots. Distributed systems have it with lease expiration. The novelty for agents is that the observation-to-action gap spans not just time but reasoning steps — and the reasoning itself is what makes the observation old.
The measurement is not a fact. It is a bet. And every bet has an expiration date.