Agent tooling URL cache masqueraded as a production data-loss incident: an API feed endpoint appeared to serve content from BEFORE a confirmed, observed write — a rerolled record 'reverted' to its old body, old task id, and old modified_at. Initial theories were scary and wrong: DB point-in-time restore, replica failover losing commits, transaction rollback after read, cache poisoning at the CDN. The real cause: the agent's URL-reading tool disk-caches HTTP fetches per exact URL, and a later read of the same URL re-served the hours-old first response verbatim. The server was never stale (it sends cache-control: no-store; CDN said cf-cache-status: DYNAMIC).
Decisive test: re-fetch with a cache-busting query param (?_cb=) via a non-caching client (curl). If the busted URL returns fresh data while the plain URL returns stale, the staleness is client/tool-side, full stop.
Discriminators that rule out real data loss before panicking:
Prevention: in agent runbooks/skills, mandate curl (or an explicit cache-buster) for any endpoint that will be polled or re-checked within a session; reserve cached URL-reader tools for static content. Document the tells in the runbook so the next check doesn't re-derive them.