Data Freshness and Trust in Agent APIs

When an AI agent tells someone that a product costs £249 and is in stock, the person trusts that answer. They click through expecting to find that price on the retailer’s website. If the price has changed to £279 since the data was last checked, or the item has sold out entirely, that trust is broken - and it is very hard to rebuild.

Data freshness is one of the least discussed and most consequential design problems in agent-facing APIs.

The staleness problem

Product data goes stale the moment it is captured. Prices change because of promotions starting or ending, competitor price matching, stock-level-driven pricing adjustments, or simply because the retailer updated their catalogue. Availability changes because products sell out, are restocked, or move between fulfilment centres.

The rate of change varies by category and merchant. A popular electronics product during a sale event might see price changes multiple times a day. A niche accessory from a smaller retailer might hold steady for weeks. The challenge is that a data service cannot know in advance which products are about to change - it can only know how recently it checked.

This creates an asymmetry. The data service knows the age of its data. The consuming agent, and by extension the user, often does not - unless the service explicitly communicates it.

The cost of getting it wrong

When fresh data and stale data look identical in an API response, the agent has no way to calibrate its confidence. It presents a two-day-old price with the same certainty as a two-hour-old one. The user acts on information that may no longer be accurate.

The consequences range from mild inconvenience (the price is slightly different when they arrive at the retailer) to genuine frustration (the product is out of stock and they have wasted their time). Over repeated interactions, even small inaccuracies erode the user’s trust in the agent - and, by extension, in whatever data source the agent is using.

For an agent developer, this creates a secondary problem. If your agent gives unreliable price information, users stop using it for purchasing decisions. The agent’s value proposition degrades regardless of how well the rest of the experience is designed.

Designing for freshness

The solution is not to make all data perfectly fresh - that is impractical and, for many products, unnecessary. The solution is to be explicit about freshness so that every participant in the chain can make informed decisions.

Timestamp everything. Every data point in an API response should carry a timestamp indicating when it was last verified against the source. Not “last updated” in a vague sense, but specifically when the data was confirmed to match the retailer’s current state. This is the single most important design decision a product data API can make for agent trust.

Let agents filter by freshness. If an agent is making a purchase recommendation, it may want to exclude any listing that has not been checked in the last six hours. If it is doing a broad market survey, week-old data might be acceptable. Giving agents the ability to set freshness thresholds in their queries lets them match data quality to context.

Communicate freshness bounds in response metadata. Beyond per-listing timestamps, the overall API response should include the age of the oldest and newest data points in the result set. This gives the agent a quick summary view: “these results include data ranging from 2 hours old to 18 hours old.”

Prioritise refresh cycles intelligently. Not all products need the same refresh frequency. High-demand items, products currently on sale, and categories with volatile pricing should be checked more often than stable, low-demand listings. This makes efficient use of rate limits and processing budget while keeping the most consequential data as fresh as possible.

The trust chain

Data freshness is ultimately about a chain of trust. The retailer publishes a feed. The data service ingests and normalises it. The agent queries the data service. The user acts on the agent’s response. At every link in this chain, the age of the data matters.

A data service that is honest about freshness - that timestamps everything and never presents stale data as current - gives agents the information they need to maintain their own trust relationship with users. The service does not need to guarantee that every price is accurate at the moment of query. It needs to guarantee that the agent knows exactly how old the data is, so it can decide how to present it.

Opacity about data age is the fastest way to undermine an otherwise well-designed API.