What is fetched_at?
fetched_at is the ISO-8601 timestamp Hive Intelligence includes in execution metadata — recording exactly when the underlying data was retrieved from the upstream provider.
A typical Hive tool response includes:
{
"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",
"runtime_status": "ok"
}
},
"meta": {
"tool": "get_price",
"fetched_at": "2026-05-30T14:23:18.000Z",
"runtime_status": "ok"
}
}The agent reads fetched_at to know exactly how fresh the data is — and can cite that timestamp when grounding an answer.
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 freshness signal, an agent answering "what's the price of ETH?" might return a value from its training data, presented as if it were current. With fetched_at, the agent knows whether it's reasoning over live data or training-cutoff knowledge — and grounds its answer in the right source.
Hive normalizes the freshness signal as fetched_at in execution metadata. CoinGecko returns last_updated on some endpoints; Moralis returns block_timestamp on chain-data endpoints. The naming differs, but the principle — explicit freshness — is what separates grounded agent answers from hallucinated ones.
How agents should use it
Agents should surface fetched_at when a user asks "right now," "today," or "latest." They should also compare it against the current time before making trading, risk, or portfolio claims. A stale timestamp is not an error by itself, but it changes how confidently the agent should answer and whether it should retry the tool call.