How an AI agent reads an order book

An AI agent reads an order book by requesting normalized market data through a single API, then building an internal model of bids, asks, and depth. The API connects to each venue on the agent's behalf, translates venue-specific formats into a common structure, and enforces safety limits before the data ever reaches the agent. Because the system is non-custodial, the agent sees only public quotes and its own scoped position context, never withdrawal permissions or account secrets.

What is an order book and why does an agent care?

For a human trader, an order book is a screen of colored rows showing buyers and sellers lined up at different prices. For an AI agent, it is a structured feed of bids and asks that changes many times per second. The agent needs this feed to know the current price, the spread between the highest bid and the lowest ask, and the depth of liquidity available at each level. Without this information, any trade would be effectively random.

Order books vary across market types. A stock broker may display shares at decimal prices. A crypto venue may show satoshi-denominated ladders. A perps venue might mix funding rates into the quote. An options venue could quote premiums in implied volatility plus strike prices. A prediction market might express prices as percentages between zero and one hundred. The agent does not need to learn each visual layout because it never looks at a screen. Instead, it receives a normalized payload that describes the same logical structure everywhere: who wants to buy, who wants to sell, how much, and at what price.

The agent uses this payload to build a local model of the market. It does not care about fonts, colors, or chart graphics. It cares about the sorted list of bids in descending order and the sorted list of asks in ascending order. From these two lists, it can compute the mid price, the spread as a percentage, and the volume available within a given price range. This is the raw material for every subsequent decision, whether the agent is looking at equities or derivatives, as outlined in how does an AI agent trade stocks.

How does market data reach the agent?

The agent does not open a web browser or log into a trading venue. It connects through an MCP tool or a direct REST call using a single API key, and the infrastructure behind that key handles the rest. The API maintains persistent connections to venues, often over WebSocket for real-time streams and REST for initial snapshots. When the agent asks to subscribe to a symbol, the API routes that request to the correct venue, starts the stream, and begins forwarding updates.

Because order books change constantly, the API usually sends incremental updates rather than full snapshots on every tick. An incremental update might say that the best bid increased in size, or that a specific ask level was removed entirely. The API applies these deltas to its own internal copy of the book, then forwards a coherent, complete book to the agent at a pace the agent can handle. This shields the agent from the complexity of managing sequence numbers, checksums, and dropped packets.

This pipeline is where the first layer of safety lives. The API checks the agent's key scope before delivering any data. If the key is limited to reading a single market, the gateway drops everything else. The agent cannot request a feed it is not allowed to see, and it cannot read account balances or withdrawal addresses. This is part of the non-custodial design: the owner controls the wallet, and the agent only sees what it needs to trade. You can read more about structuring this pipeline in building a market data pipeline that respects agent hard limits.

Latency matters here. The API coalesces and timestamps each update so the agent can judge whether the book is current or stale. If the connection to a venue drops, the API signals the absence of data rather than freezing the last known quote. This prevents the agent from making decisions on a silent, outdated book. The agent can then choose to pause trading until the feed resumes, rather than acting on false information.

Why does the API normalize what the agent sees?

Every venue speaks its own dialect. One venue might quote Bitcoin per US dollar with five decimal places. Another might use inverse contracts where the size is denominated in US dollars but the price is in Bitcoin. An options venue could quote premiums in implied volatility plus strike prices. A prediction market might express prices as percentages between zero and one hundred. If the agent had to parse each of these formats individually, its strategy code would need a separate branch for every venue.

The API solves this by translating every incoming book into a common model. The agent sees a uniform set of fields: symbol, side, price, size, and timestamp. Size is expressed in plain US dollars, so the agent does not need to calculate contract multipliers, lot sizes, or notional values. When the agent later decides to trade, it sends an order in dollars, and the API converts that into the venue-native format. This normalization is what lets one agent trade stocks, crypto, perps, options, and prediction markets through the same logic. The details of this abstraction are covered in how to trade every market through one API with hard limits.

Normalization also protects the agent from subtle errors. A venue might change its tick size during high volatility or introduce a new contract type. The API absorbs those changes and continues emitting the same stable schema. The agent's code does not break when a venue updates its API, because the agent is insulated from the venue's surface.

• ·Price is always quoted as the cost per unit in US dollars.
• ·Size is always the notional value of the order in US dollars.
• ·Side is always either bid or ask, regardless of whether the venue calls it buy, sell, long, short, yes, or no.
• ·Timestamp is always Unix milliseconds in UTC.
• ·Depth is presented as a ranked array from best price to worst, so the agent can walk the book linearly.

What safety controls exist while the agent is reading?

Reading an order book sounds harmless, but unrestricted access can still create risk. An agent that sees every market might be coaxed into overtrading. An agent that can read sensitive account metadata might leak information. The safety model addresses this by treating market data as a scoped resource, just like trading permissions.

The first control is the scoped API key. The owner generates a key that explicitly lists which symbols or asset classes the agent may observe. The key also carries a read-only flag if the owner wants to test the agent without any trading capability. Second, budget caps and position limits are enforced at the API layer, below the agent. Even if the agent misreads the book and decides to trade, it cannot spend beyond its cap. Third, a panic or kill switch lets the owner revoke the key instantly, flattening any open positions and cutting the data feed. These mechanisms are described in more detail in how trading APIs keep AI agents safe.

Because the system is non-custodial, the agent's key does not grant withdrawal rights. The agent can request quotes and send orders, but it cannot move funds to an external address. Withdrawal addresses are owner-approved only, and the API rejects any transaction that attempts to cross that boundary. This means a compromised agent reading a book is still trapped inside a cage of hard limits.

There is also a privacy benefit to scoping. The agent does not see the owner's total net worth, other open positions, or historical trades unless the owner explicitly grants that scope. The agent sees only the market data and its own allowed trading context. This limits the blast radius if the agent's memory or logs are ever inspected by an external model or service.

How does the agent turn an order book into a decision?

Once the normalized book arrives, the agent parses it into an internal data structure, perhaps a sorted array or a dictionary mapping prices to sizes. From this structure, the agent derives several immediate facts. The best bid and best ask define the top of book and the spread. The difference between them tells the agent how much friction exists to enter or exit a position.

The agent then walks down the book to estimate depth. Suppose the agent wants to buy ten thousand dollars worth of an asset. It starts at the best ask, adds up the size at that level, then moves to the next ask, and continues until the cumulative size meets ten thousand dollars. The price at the last level touched is the estimated fill price, and the distance between that and the best ask is the expected slippage. This calculation lets the agent decide whether the market is liquid enough for its intended size.

Some agents also track how the book changes over time. If large asks appear and disappear quickly, the agent might infer resistance. If bids stack up aggressively, it might infer support. These inferences are only as good as the data feed, so the agent typically timestamps every observation and discards books older than a defined threshold.

The agent may also compare books across venues. Because the API normalizes every feed to the same schema, the agent can line up the order book from a stock broker next to the order book from a crypto venue without rewriting its comparison logic. It looks for cross-market spreads or hedging opportunities using the same depth-walking code. When the agent finally decides to act, it calls the execution layer, which sends an order in plain US dollars and lets the API handle the venue-specific mechanics, a process described in how does an AI agent trade stocks.

What can go wrong when an agent reads live quotes?

Reading an order book does not guarantee profitable trading. The most common failure is stale data. If the network between the API and the venue lags, the agent may see a tight spread that has already widened. An order sent against that stale view can fill at a worse price than expected, or not fill at all.

Another risk is misinterpretation. An order book shows only visible liquidity. A venue may support hidden or iceberg orders that do not appear in the public feed. The agent might conclude that there is no depth beyond the second ask level, then discover that a large block order was hiding there. This can cause sudden price jumps that the agent did not model.

Latency is also a physical constraint. Even with a fast API, the time between the agent reading the book and the order reaching the venue is non-zero. In volatile markets, the book can shift dramatically in that window. The agent might submit a limit order at what it thinks is the best bid, only to find that the bid has moved away.

Finally, the agent itself can contain bugs. A parsing error, an off-by-one in the depth walk, or a unit confusion between dollars and contracts can produce nonsensical trades. This is why paper trading exists. An owner should run the agent against simulated data to verify that it reads the book correctly before authorizing live trading. Paper trading uses the same normalized feed but routes orders to a simulation engine instead of a live venue. Only after the owner observes stable, sensible behavior should they authorize a live key. Trading with real money can lose everything, including the entire budget assigned to the agent.

An AI agent reads an order book through a pipeline that fetches, normalizes, and scopes market data before the agent ever sees it. The architecture is designed to give the agent enough information to act while withholding everything it does not need, from withdrawal rights to raw venue protocols. By keeping the agent inside a boundary of hard limits and normalized data, the owner can let it observe markets across stocks, crypto, perps, options, and prediction markets without surrendering control of the funds.