Context Windows Don’t Know What’s Still True — I Built a Validity Layer That Does

TL;DR


I built a working benchmark for this in pure Python—no APIs, no LLMs, only a deterministic setup with real numbers and a runnable repository.


The core problem is simple: a context window remembers what happened, but it doesn't know whether that information is still valid. So I developed two deterministic executors that perform identical tasks. One checks whether a dependency remains valid before acting; the other only discovers invalidity after an action fails.


This small difference shows up clearly in the numbers. The second executor performs work that was already doomed from the start. When resource budgets are tight, that wasted effort can cause the entire task to fail.


One of my initial assumptions turned out to be wrong. I expected graph shape to drive the wasted work, but a 96-configuration sweep disproved that hypothesis—size was the real driver. I adapted the experiment to fit the data rather than forcing my original theory, and the refined result proved more precise, leading naturally to the next experiment.


The Problem: Context vs. Validity


In 2026, large language model (LLM) agents increasingly operate within long context windows, processing documents, APIs, and tool outputs that may have been ingested hours or days ago. While a context window can be technically complete—containing every piece of information the agent originally received—it remains a snapshot of the past. It does not track whether that information reflects the present state of the world.


Consider a simple scenario: an agent reads a webpage stating that a flight costs $420. Ten minutes later, the price changes. The context window still says $420, but that number is no longer true. The agent proceeds as if it is, and every subsequent action based on that stale assumption is wasted.


This gap between recall and validity is not merely a theoretical concern. In real-world AI deployments, agents acting on stale context can incur significant costs in terms of compute, time, and financial loss. Yet standard LLM evaluation frameworks rarely measure this mismatch directly. They test whether a model can answer questions or follow instructions, but not whether it knows when its context has become invalid.


The Benchmark: A Deterministic Approach


To quantify the cost of acting on stale context, I created a deterministic benchmark using pure Python. No external LLMs or APIs were involved; the environment was fully controlled, and results were entirely reproducible. The repository is available for anyone to run and verify.


The setup defines two executor archetypes:


  1. Validity-Aware Executor: Before each action, it verifies whether its dependencies (e.g., tool outputs, data entries, or status flags) are still valid. If they are not, it re-fetches or recomputes them.

    1. Baseline Executor: It blithely acts on its current context, only discovering invalidity when an action fails due to a changed dependency.

    2. Both executors were fed identical task graphs, each node representing a discrete action that depends on the output of a previous node. The environment was simulated to change certain dependency values over time, mimicking real-world fluctuations like price changes, API updates, or user status modifications.


      Key Findings: Size Matters More Than Shape


      My initial hypothesis was that the shape of the dependency graph—whether it was wide, deep, linear, or branching—would be the dominant factor in determining the amount of wasted work. I expected complex, interconnected graphs to amplify the cost of stale context more severely.


      To test this, I ran a comprehensive sweep across 96 different configurations, varying parameters such as graph depth, breadth, dependency change frequency, and the timing of validity checks. The results were surprising and humbling: graph shape had minimal impact. Instead, the size of the task—total number of actions and dependencies—was the primary driver of pre-failure work.


      Larger graphs naturally accumulated more stale dependencies over time, leading to a higher volume of doomed actions before the baseline executor encountered a failure. The relative inefficiency of the baseline executor grew almost linearly with task size.


      This finding reframed my approach. Rather than focusing optimization efforts on graph topology, I realized that scalability and the frequency of validity checks deserve more attention. I updated the experiment design to reflect this insight, and the corrective iteration yielded sharper, more precise conclusions.


      The Cost of Stale Context


      To make the impact tangible, I quantified the wasted work using a metric I call Pre-Failure Work: the number of actions a baseline executor completes that are later revealed to be invalid, measured from the start of the task until the first failure occurs.


      In small tasks (under 10 nodes), the difference was marginal—often just one or two wasted steps. But as task size grew to 50 or more actions, the baseline executor could waste 20-30% of its total work on doomed steps. In resource-constrained environments—where each action has a cost in tokens, API calls, or wall-clock time—this inefficiency can be the difference between mission success and failure.


      The validity-aware executor, by contrast, never performed a doomed action because it checked before every step. It incurred a small overhead per check (simulated as a lightweight validation call), but this overhead was negligible compared to the waste it avoided.


      Implications for Real-World AI Systems in 2026


      As AI agents become more autonomous and are deployed for increasingly complex real-world tasks—such as managing supply chains, coordinating software releases, or handling customer service requests—the context window remains a fragile foundation. No amount of context engineering can keep it perfectly up-to-date without explicit validity checks.


      My benchmark demonstrates that this is not an insurmountable problem. By introducing a "validity layer" that actively verifies assumptions before acting, we can dramatically reduce wasted work. This layer can take various forms: pinging a live API for data freshness, comparing timestamps, or querying a database for the current value of a critical field.


      The key insight is that AI systems should not treat their context as an authoritative state of the world. Instead, they should recognize it as a historical record with varying degrees of reliability. Building a validity layer is one practical step toward closing the gap.


      Conclusion


      The benchmark serves as both a warning and a blueprint. For developers and researchers building AI agents, it highlights the hidden costs of stale context—costs that become more severe as tasks scale. It also provides a concrete, reproducible methodology for measuring these costs and evaluating potential solutions.


      For 2026 and beyond, this work lays the foundation for future experiments. I plan to extend the benchmark to include more realistic dependency types, varied failure modes, and adaptive validity-checking strategies. The goal is to create agents that not only remember what they know but also understand what they don't—and know how to find out.


      In an age where AI is increasingly trusted to act autonomously, ensuring that every action is based on current truth is not just a technical challenge—it is a necessity.


      This article was originally published in the Large Language Models category. Reproducible code is available on GitHub.

      via Towards Data Science

Related