The rule for combining sources
The agentutility registry now lists 799 endpoints across 18 clusters. Calls cost between $0.001 and $0.50 in USDC over x402 on Base mainnet.
Every paid response should answer a practical question: which facts came from where?
We blend sources under two conditions:
- Separate sources supply distinct fields. A market feed might supply the latest price, while an asset reference supplies the trading status.
- The endpoint contract calls for an aggregate result. That could be a median across eligible observations or another named method.
Equivalent values stay separate unless the endpoint contract defines how they’re combined. A blended number always has a declared method. Conflicts that could change an agent’s decision appear in the response rather than disappearing inside the final value.
Freshness matters too. Each source contribution carries the time it was observed or retrieved. An agent can compare that timestamp with its own staleness limit before placing an order, publishing a claim, or continuing a workflow.
What a blended response looks like
Suppose a market-data call gets the price from one feed and the asset status from a separate reference. Endpoint schemas vary, but this representative body shows the provenance policy:
{
"data": {
"symbol": "EXAMPLE",
"price_usd": "24.18",
"as_of": "2026-08-24T14:03:12Z",
"status": "active"
},
"provenance": [
{
"source": "exchange-feed",
"fields": ["/data/price_usd", "/data/as_of"],
"observed_at": "2026-08-24T14:03:12Z",
"record": "EXAMPLE-USD"
},
{
"source": "asset-reference",
"fields": ["/data/symbol", "/data/status"],
"observed_at": "2026-08-24T13:58:40Z",
"record": "EXAMPLE"
}
],
"blend": {
"method": "field_selection",
"source_count": 2,
"conflicts": [],
"policy_version": "2026-08-24"
}
}
The fields arrays map each source to JSON Pointer paths in data. That mapping lets a router inspect only the fields that affect its next action. source_count measures contribution; agreement appears under conflicts and the named method.
If two eligible feeds report different values, the response can expose both observations inside conflicts, along with the rule used to choose or combine them.
When one source wins
A single source is selected when it owns the record being requested. Base chain state is one example. A named dataset in an endpoint contract is another.
We also pick one source when combining equivalent observations would blur their meaning. Exchange prices taken at different milliseconds shouldn’t become an unlabelled average. The endpoint either returns the selected observation or applies the aggregation method promised by its contract.
A single-source response still carries provenance:
{
"data": {
"transaction_hash": "0x8f2c...91ad",
"status": "confirmed",
"block_number": "<base-block-number>",
"confirmations": 12
},
"provenance": [
{
"source": "base-chain-record",
"fields": ["/data"],
"observed_at": "2026-08-24T14:05:09Z",
"record": "0x8f2c...91ad"
}
],
"selection": {
"method": "source_of_record",
"reason": "canonical chain state"
}
}
If a fallback source supplies the response, selection.reason records that choice. Agents can then accept the result, require a newer observation, or call again under their own policy.
Reading provenance in an agent loop
Start with the fields that control the next action. Check that each one has a provenance mapping, then compare observed_at with the maximum age your task permits.
Look at the method before treating a blended value as consensus. field_selection means sources contributed separate fields. An aggregation method means several observations affected one returned value.
Humans building with x402 can store the provenance object beside the payment receipt in audit logs or prompt traces. For a high-value action, require the named source, acceptable freshness, a known policy version, and an empty conflict set before execution.