Decide Which Data Must Be Current Before an AI Agent Acts

Before expanding an AI agent’s role, define the evidence it needs to make a particular business decision. A company does not need every record refreshed continuously to produce useful work. It does need to know which facts can change the outcome, which source governs them, and how long those facts remain usable. That distinction gives technology leaders a practical way to prioritize data investment without waiting for an enterprise-wide cleanup.

An agent is software that uses a model to choose and carry out steps toward a task. When those steps include booking work, allocating inventory, or making a customer commitment, the quality of its answer depends on the business state behind the words. An agent can interpret its instructions correctly and still act on facts that are no longer true.

In a September 23 SAP feature, Reltio CEO Manish Sood connected agent readiness to the quality, timeliness, and context of enterprise data.[1] His perspective is relevant, but it comes from a vendor. The decision for a technology leader is more specific than a general call for trusted data: which information needs improvement before the next proposed action becomes acceptable?

Readiness depends on the decision

Consider a hypothetical service company using an agent to arrange an equipment repair. The agent needs to understand the problem, identify a suitable technician, check parts, and offer an appointment. A historical service note may help it interpret the fault even if that note is several months old. The available appointment and unreserved part count can change while it is working. A technician’s qualification must be valid for the planned work, not simply present in a profile.

These facts need different treatment. Reprocessing every historical note on the same schedule as available appointments would add work without making the appointment more reliable. Conversely, a current-looking summary of the customer account would not establish that the required part is still available. The business owner should define the evidence needed for the commitment, and the data team should trace where that evidence comes from.

The same source can also be suitable for one purpose and insufficient for another. Yesterday’s inventory summary might support a planning discussion. It should not, by itself, authorize a promise that the last available component will be used for a particular repair. The relevant standard follows the intended action and the consequences of being wrong.

A recent retrieval can still return an old fact

Record when the fact was observed or became effective, as well as when the agent retrieved it. Those times answer different questions. A tool called moments ago might return a warehouse extract from the previous night. The new request establishes when the agent received the information; it does not establish that the source reflects subsequent changes.

The ChurnBench preprint, revised September 20, offers a useful way to examine this problem. Vivek Kumar Singh, Preeti Priyam, and Gautam Bhowmick describe a benchmark that changes synthetic enterprise data over time and distinguishes freshness errors from reasoning errors. A previously correct answer can become incorrect because the world represented by the data changed.[2] That distinction helps identify whether a failure calls for better reasoning or a different data-refresh process.

The study has important limits: it uses a single model, agent framework, and domain with synthetic data. Its reported error counts are not estimates of failure rates in real enterprises. Its practical contribution here is a test design. Evaluate the answer against the facts at the relevant time, rather than only against a fixed collection of documents.

For the repair example, retain the source, observation or effective time, and relevant record version for appointment availability and parts. Decide how the workflow will recognize a delayed feed or a missing update. A freshness rule that cannot detect failure of its own refresh process provides less assurance than its stated interval suggests.

Make the evidence requirement explicit

Use one short evidence specification for the proposed action. It should say which source is authoritative for each consequential fact, the validity or freshness condition, and the response when that condition cannot be established. Keep it close to the workflow so the business owner, data team, and application team can review the same requirement.

For an appointment commitment, the specification might require the scheduling service to confirm and reserve an available slot. It might require the inventory service to accept a reservation for the needed part. The qualification record must cover the type of work and the scheduled date. These are illustrative requirements, not universal service-industry standards; the actual conditions belong to the company operating the process.

Source authority matters when systems disagree. A recently updated customer note may conflict with the executed service agreement. Choosing whichever record has the newest timestamp would confuse recency with authority. The workflow needs a designated source for the decision and a defined way to resolve a conflict. A model’s fluent explanation of the discrepancy does not resolve it.

The business owner should set the consequence and acceptable delay. Data owners should explain what their sources and pipelines can substantiate. Application owners should implement the checks and expose failures to the workflow. This division prevents a refresh interval chosen for technical convenience from silently becoming the business’s risk tolerance.

Close the gap between checking and committing

Fresh information can change between a check and the action it supports. Two requests can both see the same available appointment before either reserves it. Increasing the refresh rate alone does not prevent that conflict. The service responsible for the booking must verify the relevant condition as it accepts the reservation.

This is an established software problem, not a property that a stronger language model removes. PostgreSQL’s documentation illustrates why the timing of reads and concurrent updates matters: at its Read Committed level, successive queries can observe different committed data. Its Serializable level provides stronger transaction guarantees, with the possibility that an application must retry a conflicting transaction.[3] These mechanisms are examples, not a recommendation to change database settings across the enterprise.

Engineers must select an appropriate method for the actual system, such as a reservation or a conditional update that succeeds only while the relevant state still holds. A transaction in one database does not automatically protect a separate scheduling or supplier system. Where several services are involved, the application needs an explicit way to coordinate commitments and handle a partial result. Asking the agent to check again is not equivalent to making the check and commitment indivisible.

Spend on freshness where it changes the result

Tighter freshness can require more frequent queries, event delivery, additional monitoring, and higher availability from source systems. Those costs are justified when they reduce a consequential exposure or enable valuable work. They are harder to justify for facts that rarely change or decisions that tolerate a stated delay.

Begin with the smallest set of facts that could invalidate the selected action. Compare the cost of improving their delivery with the cost of keeping the agent in a narrower role. If a reliable reservation cannot be obtained, the agent might prepare options for review without promising an appointment. A person should not be asked to approve the same uncertain information blindly; the review must provide a way to obtain the missing evidence or choose a safe alternative.

Test this boundary deliberately. Change a relevant record after retrieval, delay an update, make the authoritative source unavailable, and introduce a conflict between sources in a controlled test environment. Observe whether the workflow refreshes, withholds the commitment, or proceeds incorrectly. NIST’s AI Risk Management Framework calls for context-specific evaluation and documented limitations; it does not prescribe one freshness threshold for every application.[4]

Separate stale-data failures from reasoning failures in the review. Also measure commitments withheld unnecessarily, time spent waiting for evidence, and the operational cost of obtaining it. These measures show whether the proposed control improves the business process or merely transfers work to another team.

At the next funding review, require one proposed agent workflow to identify the facts that can invalidate its decision and demonstrate how each is checked. Fund the missing source access, update mechanism, or verification step against that defined need. The result is a bounded investment with an observable test, while the rest of the data estate can improve in an order the business can defend.