How does real-time data augmentation improve agent performance?

What you need to know

Freshness needs differ by fact

Implementation

• Read-through tools for facts that must be current: always call the system of record.
• CDC or event streams into the retrieval index, so search is minutes behind, not a day.
• Short-TTL caching for hot reads, with a bypass for "right now" questions.
• As-of timestamps on every fact. The model can say "as of 10:42", and traces reveal stale data.

Failure modes and controls

• Latency added to every turn. Cache what you can and call live tools in parallel.
• Confidently stale answers when a source is down and a cache answers silently. Return an explicit "unavailable" instead.
• Skew between two sources that disagree. Pick one system of record per fact.
• Freshness SLOs per source, monitored like uptime.

A real-life example

A travel-booking agent for a railway and bus aggregator answered "Are there seats on the Mumbai to Pune train tomorrow morning?" from a search index refreshed every 30 minutes. During the festival season, it said "yes, 42 seats" when the train had sold out 20 minutes earlier. Customers reached the payment page and failed.

The fixes:

• Availability and fares now come only from check_availability, a live call to the booking system, with a 1.5-second timeout.
• Station info, train timings and amenities stay in the index; they change rarely.
• Every availability result carries as_of. The agent says "42 seats as of 9:14 am; availability changes quickly".
• If the live call times out, the agent says "I could not check live availability just now" instead of using the index.

Failed-payment complaints from "seat not available" dropped by about 90% during the next sale period, at the cost of about 0.8 seconds more per availability question.

Follow-up questions to expect

• "Why not just re-index more often?" — For fast-changing facts like seats and prices, even a minute can be too stale. Those should be read live; indexes suit slower-changing content.
• "How do you handle a slow live source?" — Timeout, degrade honestly ("could not check"), and never fall back silently to stale data for facts the user will act on.
• "How do you detect staleness in production?" — Log as_of on every fact, and alert when the gap between as_of and the answer time exceeds the source's freshness SLO.