I built a guard for AI agents that act on stale information
I kept running into a failure mode that wasn’t really a hallucination.
An agent reads something—a balance, inventory level, account status or policy—and reasons correctly from it. Then the world changes before the action runs. The reasoning was valid when produced, but stale at execution time.
I built FreshCtx as a small open-source Python runtime for that gap. Reasoning declares the evidence it depended on, and FreshCtx checks those sources again at the action boundary. If something relevant changed, the affected reasoning is invalidated instead of silently reaching execution.
It is deliberately not another agent framework, memory system or vector database. It is meant to be a narrow reliability layer that can sit beside existing agent stacks.
GitHub: https://github.com/Hyperwise-LLC/freshctx
I’m trying to understand whether other builders have encountered this problem and how they currently handle it. Do you re-read everything before an action, use version checks, rely on transactions, or solve it somewhere else in the workflow?
A reproducible scenario
In one simulated workflow, an agent reads an account balance and decides that a payment can proceed. Before execution, another payment changes the balance.
Without revalidation, the original decision continues toward execution using stale evidence.
With FreshCtx, the balance is registered as a dependency. At the action boundary, FreshCtx reads it again, detects that it changed and invalidates the affected reasoning before the payment action runs.
This is a controlled simulation, not a production customer result. The test is intended to make the failure mode reproducible and open to criticism.
The stale information problem is going to get more important as AI agents start taking actions instead of just giving answers. A response based on slightly outdated information is one thing, but an agent making a real change based on it can cause a much bigger problem.
I like the idea of putting a guard around the action rather than trying to make the agent perfect. How you decide what information is considered too stale for a particular action.
This maps onto something we've hit from the other direction. We're building a confirm-before-execute layer for phone commands (send a text, book a calendar event, etc.) — the gap we keep circling isn't stale data exactly, it's stale plan: the user approves an action, then something changes (the calendar slot fills, the contact's info updates) in the seconds between confirmation and execution.
Right now our answer is naive — re-check the specific fields the action depends on immediately before firing, and re-prompt if anything material shifted. Sounds like FreshCtx formalizes exactly that dependency-tracking step instead of leaving it ad hoc per action type.
Question for you: does FreshCtx have an opinion on how to handle the invalidation — auto-abort, silently re-derive, or bubble back up for a fresh human/agent decision? That last one seems like the hard case, since it's not always obvious the new state still satisfies the original intent.
Yes, that is exactly the gap FreshCtx is meant to formalize. Today the default behavior is fail-closed: changed evidence invalidates the dependent decision and blocks the action. There is also a refresh policy with a callback, but I think the application should own whether that means re-derive automatically or return for renewed human approval.
For your phone-command case, I would probably require renewed approval when the changed field affects user intent—different contact, time, recipient or payload—but allow automatic re-derivation for something operational that leaves the approved intent unchanged. Your example would make a very good integration test.
The stale-context problem is a really interesting one because the agent can make the “right” decision and still produce the wrong outcome if reality changes before execution.
What I’m curious about is the layer after FreshCtx: once the re-check happens, how do you independently verify that the agent actually respected the result — especially in cases where it should have stopped, escalated, or requested approval?
That execution-vs-control gap is something we’re exploring with OpsWatch. The control existing is one thing; proving the agent behaved according to it at runtime is another.
Agreed—that is a separate boundary, and FreshCtx does not claim to prove what happens after the action is invoked. It checks declared dependencies, applies the policy, and records whether the protected action was allowed or blocked.
Independent runtime verification would complement it well: FreshCtx answers “was the decision still valid when execution began?” while something like OpsWatch could answer “did execution actually respect that result and produce the intended outcome?”
The core insight here is that "correct reasoning from evidence" and "evidence still valid at execution" are completely separate measurement domains. Most systems collapse them together. You're making visible the gap between reasoning-time and action-time measurement state. That boundary is where silent failures hide - the agent was right at t1, but the world changed by t2. Forcing explicit dependency tracking moves system reliability from "hope nothing changed" to "verify what matters changed." This feels like the execution equivalent of retention curves for data validation - you can't judge correctness without measuring time explicitly.
That is exactly the distinction I was trying to isolate. Time is part of correctness once reasoning and action are separated.
The part I find most important is tracking only the evidence the decision actually depended on. Otherwise the choices become either “hope nothing changed” or re-read the entire world before every action, neither of which scales very well.
The distinction between correct reasoning and still-valid reasoning at execution time is interesting.
Curious whether builders see this as a separate reliability problem, or something they’d rather solve inside their existing transaction/workflow layer.
I think both approaches have a place. A transaction is usually the strongest answer when all relevant state and the write live inside the same transactional system.
FreshCtx is aimed at the messier cases where reasoning depends on several sources—a file, Git branch, API response, MCP resource or approval—and no single transaction can cover them all. In that case it provides a check immediately before the existing workflow or transaction begins.