How to check data freshness before an AI agent answers

Read the result and use the exported policy

In the synthetic example, the decision time is September 15, 2026 at 12:00 UTC. The HubSpot company dataset is 30 hours old against a 24-hour limit, even though its source reports a more recent successful commit. Stripe invoices are one hour old against a four-hour limit. The support dataset has no successful commit timestamp, so its freshness is unknown. These are teaching values, not a live account result.

Start your own check with manual timestamps, or paste the { "data": [...] } structured output from get_freshness. Review the required items and each age limit. When you apply a later snapshot, existing requirements stay in the check: an absent item remains unknown, while a newly seen item starts optional. Start a new check when you intend to replace the scope.

The JSON download contains your supplied evidence, policy and calculated checks. The Markdown version adds a readable report and instructions for the next agent answer. Recheck at the new decision time; the download does not enforce an agent, authenticate metadata or refresh a source. Source state, authorization and coverage need their own checks even when all required timestamps meet the policy.

This measures age since a reported commit. Measuring the delay from an upstream change to the agent seeing it requires the separate end-to-end drill below. Use the existing twelve-case answer-verification lab for incorrect amounts, missing evidence and unsupported citations after freshness is checked.

Define “fresh enough” for the decision

Start with the decision the answer will influence. A weekly account review can tolerate a different delay from an operational alert. Write an explicit requirement such as: “For this daily briefing, each required source must have committed successfully within the last 24 hours.” This is an example policy, not a Combined service guarantee.

Specify the time zone, required datasets and behavior when the requirement is missed. For a low-stakes summary, a labeled partial answer may be useful. For a time-sensitive action, the application may need to stop and request a new sync or human review.

Freshness is also different from event time. An invoice can be ingested today while describing a payment from last month. Use the business event field for the requested date range, and the ingestion state to explain when the system last checked the source.

Check four signals independently

For an answer joining two systems, check both. Fresh billing data cannot make stale CRM ownership data current. If a result depends on the intersection, the weakest required source can constrain the whole conclusion.

A source can also be healthy while a newly added field is absent from the approved selection. Treat schema changes as something to review, not evidence that an agent should automatically broaden its access.

Give the agent an explicit answer contract

Put the freshness requirement beside the business question. This sample uses a 24-hour threshold purely as an example:

Before answering this daily briefing:
- List the required sources and datasets.
- Check the committed freshness of each source.
- Treat data older than 24 hours as stale for this task.
- State missing datasets or fields. Do not infer zero
  activity from missing access or missing records.
- Run only permitted read-only queries.
- Include the time window, receipt ID, and truncation.
If a required source is stale, return a labeled partial
answer or explain what must be refreshed.

In Combined MCP, use discovery tools to identify the granted sources, describe_dataset to inspect fields and freshness, and get_freshness for source status. The documented freshness tool accepts up to eight sources per request; split a larger check into bounded requests.

Keep query receipts as traceability evidence. They help identify the request and applicable controls, but do not replace a record-level audit or prove that an answer considered every relevant source.

Run a freshness drill before relying on the answer

Use a test workspace or a source you can safely change. Record a known value, make a source change, run or wait for the configured sync, then confirm when the new value becomes queryable. Repeat with a field outside the selected scope to confirm that the agent describes the gap correctly.

1. Check a successful sync and a known changed record.
2. Check a stale source against the task’s freshness requirement.
3. Check a query that reaches its output limit and must disclose truncation.
4. Check a dedicated test grant after revocation.
5. Confirm that the final answer distinguishes “no matching records” from “unable to inspect the required data.”

Combined supports manual, daily and allowlisted hourly sync choices. Availability depends on the connector and account policy; do not promise real-time freshness for every source. Read the source and freshness reference and verify the actual configuration in your workspace.

Sources and further reading

Explore the documentation behind this guide. Product details checked on September 15, 2026.

• Combined sources and freshness
• Ingestion and provenance
• MCP freshness and discovery tools
• Source troubleshooting