Agent Decisions on Stale Data: Freshness Contracts & Write-Time Validation

Introduction: The Procurement Assistant Example

A procurement assistant Agent queries budget availability and supplier qualification, then recommends submitting an application. However, the business system rejects the submission because the budget was just consumed by another request and the supplier status may have changed. The Agent's logic is sound, but the facts it retrieved do not belong to the same moment. Swapping in a stronger model cannot close this time gap.

"Just Queried" Does Not Equal "Just Happened"

A piece of information may have been generated in the business system yesterday, entered the data warehouse today, updated in the retrieval index minutes ago, and only just fetched by the Agent. The query time is recent, yet the content can be old. If an interface returns only "current supplier status" without source, version, or update timestamp, the Agent cannot judge whether to treat it as background material or as valid evidence for submission.

Therefore, data responses should include the source, the source record version or update time, and the read time. If the data passes through indexing, caching, or batch synchronization, the system must also indicate which version or time range was synchronized. When this lineage is unclear, the freshness is unknown — do not merely label the endpoint "real-time data."

Retrieval relevance and timeliness are separate concerns. An outdated policy that matches perfectly may rank higher than a slightly different current policy. A good match does not prove current applicability.

Different Data, Different Freshness Contracts

Supplier descriptions can tolerate some staleness, whereas balances and access status often require stricter guarantees. Pushing all data to be "real-time" can overload business systems. Instead, define a data freshness contract for each use case: how stale the data may be, how to detect expiry, and what to do when it expires.

Supplier background — used for summaries and material compilation; cite source and date, do not rely on it for access proof; if source unavailable, use explicitly labeled historical material.

Procurement policy — interpret according to effective scope; verify current version and applicable project; if uncertain, ask the rule owner.

Available budget — used for preliminary suggestions; the source system must check and pre-occupy at submission time; if unavailable, pause budget-dependent submissions.

Supplier access status — assists go/no-go decisions; validate effective state in a controlled business operation; do not treat a previous pass as a current pass.

User permissions — limit read and operation scope; re-verify on every sensitive operation; if source unreachable, restrict operations per a pre-defined disconnect strategy.

Concrete time windows must be derived from business risk and synchronization capability, not from arbitrary rules like "cache for five minutes." Cache TTL is an implementation parameter; business validity depends on whether data has been revoked or overwritten.

Multiple Facts Read Are Not Guaranteed Simultaneously True

Querying budget, then supplier, then project — each succeeding individually — does not prove the three states held at the same instant. Even within a single database, transaction isolation matters. For example, PostgreSQL's documentation states that under Read Committed isolation, two successive queries in the same transaction can see different snapshots. Cross-service queries are even less likely to reflect a single point in time.

When producing an analysis report, list the timestamp and source of each datum. At submission time, delegate the checks to the responsible services: the budget service confirms whether the amount can still be reserved, the procurement service verifies the request against current rules. The Agent assembling a complete report does not replace those service-level checks.

If cross-system coordination is truly required, design explicit pre-occupancy, state progression, and failure handling mechanisms. Additional model queries cannot substitute for these mechanisms.

Pre-Submit Re-Query Still Misses the Final Step

Many architectures schedule a "source query before execution." This helps, but state can still change between the query and the actual write. Critical conditions must be validated at write time . For instance, the request can carry the version read earlier; the service only proceeds if the version still matches. Alternatively, the budget service checks availability and performs the reservation within its own transaction. If conditions have shifted, reject the submission and let the task re-evaluate.

Rules such as "budget cannot be over-occupied" belong in the business service. Adding an Agent does not remove the need for server-side enforcement.

Event streaming can propagate changes faster, but messages may duplicate, arrive out of order, or be lost. A late old event must not overwrite a newer record; a slow consumer must be able to detect its lag.

Permissions and Deletions Also Require Propagation

When a source record is withdrawn, copies may linger in search indexes and caches. Revoking a user's permission does not instantly invalidate all existing sessions. Therefore, permission revocation must notify downstream systems, queries must re-check current permissions, and copies must be cleaned up per policy. Testing must cover not only "how long until new data is searchable" but also "how long until withdrawn data becomes unreadable."

Validate the mechanism with scenarios: source record update, index delay, event reordering, version change before submission, and permission revocation. The key is whether the system can recognize unknown or expired states and halt when necessary, rather than merely counting successful query responses.

A rejected purchase application due to a budget change may actually indicate the business service correctly enforced the rules. The greater risk is that data has changed yet the system still submits successfully using stale results. Only after handling such changes should Agent permissions be gradually expanded.

References

PostgreSQL, Transaction Isolation:

https://www.postgresql.org/docs/current/transaction-iso.html