Five Data Sources. Five Failure Modes. One Agent.
Every DeFi agent is quietly building its own data pipeline. That's where reliability goes to die.
An AI Agent making a single swap decision has to pull five categories of data (price, liquidity, gas, protocol risk and cross-chain routing) from five different sources, each with its own failure mode. The agent’s reliability ends up capped by whichever feed in that stack is having the worst day.
AI Agents need oracles. The oracles that exist today weren’t built for them, and the mismatch is where a lot of current agent reliability problems quietly start.
Start with what the agent is actually doing
An AI Agent wants to swap 10 ETH for USDC. A human would open a DEX, glance at the price and hit swap. The agent can’t eyeball a chart, so it has to reason about the trade programmatically, which means pulling in data from more sources and with higher reliability than most of those sources currently provide.
Before the agent submits a single transaction, it has to work through a short list of questions, and each one is really a data problem in disguise.
The first is price. Not the price five minutes ago or the price on one exchange, but a real-time multi-source price with a confidence signal attached. The agent has to know whether the number is reliable, whether it’s stale and whether it’s being manipulated. A human trader develops intuition for this kind of thing over years; an agent needs structured inputs that express the same judgement numerically.
Then there’s liquidity depth. The spot price is meaningless without knowing whether 10 ETH will actually fill at that price, so the agent needs order book or liquidity pool data to estimate slippage. On AMMs that means reading the pool’s reserves and fee tier; on aggregators it means comparing routes. This data lives across DEX subgraphs, pool contracts and aggregator APIs, all with different formats and refresh rates.
Gas is the next problem, and it goes well beyond “what’s the current base fee”. The agent has to predict what gas will actually cost when the transaction lands, account for the complexity of the swap route (a multi-hop swap through three pools costs more than a direct pair) and decide whether the trade is still worth executing after fees. On L2s the estimate also has to include the L1 data posting cost.
Protocol safety is the question most agents skip, and it’s the one that burns them. Has the protocol been exploited recently? Is there unusual activity in the pool? Are governance proposals pending that might affect the contract? Protocol risk isn’t a static score; it changes by the hour.
Finally there’s the cross-chain picture. If the best price is on a different chain, the agent needs bridging data: bridge fees, transfer times and destination chain gas costs. At that point the agent isn’t just making a swap decision any more, it’s making a routing decision across chains, and the data inputs multiply accordingly.
That’s five data categories at minimum, each one a decision input that has to come from somewhere reliable.
What oracles were built to do
Oracles exist because smart contracts can’t read the outside world on their own. A lending protocol needs to know the price of ETH to calculate collateral ratios. A perps exchange needs the price of BTC to trigger liquidations. Since these contracts live on-chain, they need a trusted way to get external data pushed in.
Chainlink, Pyth and similar networks solved that problem. They aggregate price data from multiple sources, push it on-chain at fixed intervals or on demand and let smart contracts consume it in a standardised format. It’s a narrow and well-done job: get a reliable price feed to a contract at execution time, without introducing a single trusted party.
That’s useful work, but it isn’t what an AI Agent needs.
Where the mismatch shows up
Smart contracts consume oracle data at execution. The price feed is read inside a transaction, used in a calculation and written to state; the contract doesn’t need context, only a number.
Agents work the other way around. They consume data before execution, while they’re still deciding whether to execute at all and on what terms. That shifts what the data layer needs to provide in a few concrete ways.
The first is breadth. Price alone isn’t enough when liquidity depth, slippage, gas, protocol risk and cross-chain routing all matter to the decision, so an oracle that only delivers prices covers maybe a fifth of the decision surface.
The second is freshness on demand. Periodic on-chain updates work fine for a lending protocol that only needs to liquidate when a price crosses a threshold, but an agent evaluating a live trade needs sub-second freshness on the exact inputs it’s reasoning about right now.
The third is confidence signals. A smart contract is happy with a number, but an agent wants the number alongside a read on how much to trust it: is this price from three sources or one, how divergent are they and what’s the confidence interval.
The fourth is queryable structure. Oracle price feeds are push-based and fixed-format, whereas an agent’s queries are dynamic. “What’s the deepest liquidity for this pair across these five venues right now, and what would a 10 ETH fill look like?” isn’t a feed you can subscribe to; it’s a query you have to be able to answer.
None of this is a criticism of existing oracles, which do the job they were designed to do. The point is that agents have shown up as a new kind of user with a different problem, and the infrastructure hasn’t caught up yet.
What agents do today instead
The current answer is cobbling. Every agent stitches together CoinGecko for price, DEX subgraphs for liquidity, RPC calls for gas, a handful of scattered dashboards for protocol risk and bridge aggregators like LiFi or Across for cross-chain data, with each pipeline inheriting its own set of failure modes.
For a hackathon demo that’s fine. For an agent managing real capital it becomes a ticking problem. An API that rate-limits at the wrong moment leaves the agent flying blind on risk for a live decision. A lagging feed puts it into a trade at a price that no longer exists by the time the transaction lands. A format change upstream can break the pipeline silently while the agent keeps executing, and silent failures are the hardest ones to catch.
The underlying problem isn’t that agents lack data. It’s that they have fragmented data they’re forced to treat as equivalent, with no structural way to know when any given input has quietly gone bad.
What an agent-native oracle looks like
If you work backwards from the agent’s decision, an oracle designed for agents would have to deliver a full decision context rather than a single datapoint. That means multi-domain data in one layer covering price, liquidity, gas, risk and routing, pull-based queries alongside (or instead of) push-based feeds, confidence scores attached to every value, freshness guarantees that match the agent’s decision cadence rather than the contract’s settlement cadence, and a query interface that treats the agent as the primary consumer rather than a smart contract.
What you end up describing is a different primitive. It borrows from oracles in that it has to be trusted, verifiable and multi-source, and from data APIs in that it has to be flexible, queryable and structured, but it doesn’t map cleanly onto either category. Whether the industry ends up calling it an agent-native data layer or an oracle for agents matters less than whether someone actually builds it.
The bottom line
AI Agents do need oracles. The ones we have today serve smart contracts well and agents poorly, because agents are a different kind of user with different requirements around breadth, freshness, confidence and queryability.
That gap is going to close, and the infrastructure that closes it will look less like faster price feeds and more like a purpose-built data layer for agent decision-making. As agents move from toy demos to managing serious capital, the gap stops being a nice-to-have and starts being the ceiling on what agents can actually do reliably.
This post is exploratory and does not represent a specific roadmap.