fetched_at is an ISO-8601 timestamp in REST meta/data._hive and MCP _hive metadata recording when Hive completed the retrieval. observed_at is Hive's first observation or original cache-population time; it is not automatically an upstream timestamp. cache_age_ms describes Hive's cache age.

Why does fetched_at matter for AI agents?

AI models have training cutoffs. fetched_at proves a Hive retrieval occurred at a known time; observed_at, cache_age_ms, source, and cache_status describe Hive's retrieval path. A provider timestamp, block, slot, or candle close is still required to establish source recency when available.

Do other crypto APIs return fetched_at?

Providers expose different clocks, such as last_updated or block_timestamp. Hive consistently exposes fetched_at for retrieval completion and adds observed_at/cache_age_ms at the execution layer; provider timestamps inside the payload remain relevant when present.

Should agents always cite fetched_at?

When grounding numerical claims (prices, TVL, balances, percentages), yes: the user should know whether the agent is reasoning over live data or training-cutoff approximations. For qualitative answers (definitions, explanations) fetched_at is less critical because the underlying knowledge changes slowly.

What is fetched_at? | Freshness Timestamps for AI Agent Data

fetched_at is the ISO-8601 timestamp when Hive completed a tool retrieval. Read it with observed_at, cache_age_ms, source, and cache_status to understand Hive's retrieval/cache path, then use provider-native clocks to judge source recency.

A typical Hive tool response includes:

json

{
  "ok": true,
  "data": {
    "bitcoin": { "usd": 67421.50 },
    "ethereum": { "usd": 3245.80 },
    "_hive": {
      "tool": "get_price",
      "provider": "CoinGecko",
      "fetched_at": "2026-05-30T14:23:18.000Z",
      "observed_at": "2026-05-30T14:23:17.900Z",
      "cache_age_ms": 100,
      "runtime_status": "ok"
    }
  },
  "meta": {
    "tool": "get_price",
    "fetched_at": "2026-05-30T14:23:18.000Z",
    "observed_at": "2026-05-30T14:23:17.900Z",
    "cache_age_ms": 100,
    "runtime_status": "ok"
  }
}

The agent cites fetched_at as retrieval time and uses observed_at plus cache_age_ms to assess Hive's capture/cache timeline. A provider payload may also contain a market timestamp, block, or slot that should be preserved.

Why this matters

AI models have training cutoffs. They know the world as of some date in the past, often months, sometimes years, before the current conversation. For most crypto data (prices, TVL, funding rates, wallet balances) the training-cutoff value is the wrong answer; the live value is what the user wants.

Without an explicit retrieval signal, an agent answering "what's the price of ETH?" might return a value from training data. fetched_at proves the tool ran; observed_at, cache_age_ms, and source/cache status say whether Hive newly retrieved or reused the response. They do not by themselves prove upstream freshness.

Hive normalizes retrieval completion as fetched_at. CoinGecko may return last_updated, Moralis may return block_timestamp, and chain tools may return a block or slot. Those provider clocks are not silently rewritten. Hive's observed_at and cache_age_ms supplement them with execution-layer evidence.

How agents should use it

Agents should surface fetched_at, observed_at, cache_age_ms, and provider timestamps when a user asks "right now," "today," or "latest." A recent Hive retrieval is not proof of an upstream-fresh datum. If the provider supplies no native clock, say source recency is unknown and retry or corroborate when the decision requires a current value.

Why this matters

How agents should use it

Related terms