How long before data becomes risky for an AI agent?

No. A page's modification date says when the container changed, not whether every item inside it is still suitable for the decision at hand. A product description may be stable, its price may change during the day, and availability may change between two consecutive requests. Treating the whole document as either current or old hides the distinction that matters most.

The problem becomes clearer when the reader is expected not only to answer, but to act. If an assistant reports an outdated price, it produces a wrong answer. If an agent uses that price to select a supplier, prepare an order, or promise a cost to a customer, stale data enters a process and creates consequences. Freshness stops being an editorial quality and becomes an operating condition.

FreshLLMs distinguishes questions built on stable knowledge from questions that require fast-changing information, and shows how difficult the latter remain for models relying on learned knowledge. The useful lesson for a company is not that every answer must search the web. It is that each field needs a policy matched to how quickly it changes and how much damage an error can cause.

There is no universal duration that works across industries. A B2B price list revised every quarter and the dynamic price of a flight are both prices, yet they have different rhythms, sources, and consequences. Useful lifetime must be set by the process owner after considering four factors: actual change frequency, cost of error, reversibility of the action, and availability of an authoritative source that can be checked again.

The table does not assign absolute time limits. It gives a starting policy that each organisation must turn into a measurable threshold. Slow data can be retained longer, but should be invalidated when the official source changes. Volatile data should be read close to the decision. Regulatory data requires the applicable version and effective date, not simply the most recent page a search happened to find.

A single label such as "updated today" is not enough. Reconstructing a decision requires at least four distinct moments: when the fact became true at the source, when the system read it, how long the process considered it usable, and when the agent used it. Mixing these together makes it impossible to tell whether an error came from the source, collection, cache, or an action executed too late.

The first is event time, such as when a tariff takes effect. The second is `observed_at`, when the system observed the value. The third is `recheck_after` or `valid_until`, the process threshold. The fourth is `used_at`, when the data contributed to an answer or action. Systems need not adopt these exact names, but they need to preserve the distinction.

RFC 9111 on HTTP caching provides useful vocabulary: a response can be reused while fresh; once it is no longer fresh, it can be validated with the origin instead of being downloaded blindly or treated as if nothing changed. This is not an AI-agent standard, but the principle transfers. Expiry does not always mean deletion. It means new evidence of validity is required before reuse.

It contains a rule that both the system and its accountable owner can understand. For each critical field, it declares the accepted source, maximum observation age, check required before use, behaviour when sources conflict, and owner of the decision. Without those elements, "use up-to-date data" remains an intention that nobody can test.

The contract should be proportional to the action. When suggesting three products on an informational page, showing an observed price with its time and asking for a final check may be acceptable. When placing an order automatically, that same price should be read from the transactional source immediately before confirmation. The model does not decide how much risk to accept. The process does, before the model runs.

Data published by the brand should express the same discipline. Schema.org, for example, defines `priceValidUntil` to state the date after which a price is no longer available. The property alone does not guarantee that an engine will use it, but it makes explicit something that would otherwise remain implied. Quality comes from consistency across page, feed, structured data, and source system, not from adding one isolated attribute.

An agent should not turn the absence of fresh data into false certainty. Once a threshold is exceeded, there are three healthy options: verify again, return an explicitly limited result, or stop the action and ask for intervention. The choice depends on the cost of delay and the cost of error. Continuing silently is usually the worst option because it hides the trade-off.

Verification fits when the source is available and the cost of the call is lower than the risk. Degrading means offering something less binding, such as a comparison without a final price or a non-executable draft. Stopping is appropriate when the action is hard to reverse, involves money, rights, safety, or external communication, and a required value is missing. A stop is not a technical failure. It is a control function.

NIST includes creation time, modifications, and sources among the information that provenance metadata may carry. Provenance does not prove that content is correct, but it makes that content challengeable and reconstructable. In an agentic workflow, traceability must extend to the action: which value was used, from which source, observed when, and under which rule.

Testing the ideal path with available sources and consistent data is not enough. A useful test deliberately introduces uncomfortable conditions: an expired price, conflicting sources, a slow response, a missing field, and an update occurring between selection and confirmation. The result to observe is not only whether the agent completes the task, but whether it recognises when it no longer has the conditions to complete it correctly.

Build a small set of cases with an expected decision for each: use, verify, degrade, or stop. Run the same set whenever the workflow changes and measure at least the rate of actions based on stale data, correct blocks, unnecessary blocks, latency added by verification, and source cost. Optimising only for speed encourages too much reuse; optimising only for caution stops everything.

Then test the handoff between systems. A value can be fresh in the origin API and stale in a search index, intermediate database, or prompt assembled for the model. For every critical field, follow the complete path to the output and check where it is stored, transformed, or duplicated. Freshness is a property of the chain, not only of the final call.

Start with one workflow and the five fields capable of changing its decision. For each, write down the source, owner, observed change frequency, initial threshold, and behaviour beyond that threshold. If you cannot choose a duration, use a conservative rule and measure how many checks it produces. Real process data can then justify making it longer or shorter, rather than relying on intuition.

Next, separate stable facts from volatile values. Stable facts can live in a versioned knowledge base and update when the source changes. Volatile values should be retrieved close to inference or, when the agent acts, close to confirmation. This separation reduces unnecessary calls without pretending that everything indexed yesterday remains valid today.

Finally, make the limit visible to the user and the team. An answer with its source and observation time is more useful than an apparently precise number without context. An agent that says it cannot confirm availability protects the process better than one that always completes the task. Maturity is not measured by how many actions are automated, but by how many run under declared conditions.