How AI agents read order books

An AI agent reads an order book by consuming streams of bids and asks, normalizing them into a single format, and comparing the resulting prices and sizes against its own strategy rules before it decides to place an order. The process is mechanical: the agent polls or listens to a data feed, parses the depth levels, and records the best available prices and quantities. It does not guess. It reads the state of the market as a structured table and reasons about it within the bounds set by its owner.

What does an order book actually contain?

An order book is a two sided list of all open limit orders for a given asset at a given venue. The buy side, called bids, is arranged from highest price to lowest price. The sell side, called asks, is arranged from lowest price to highest price. Each row in the book is a price level, and each level contains the total size available at that price. That size is the sum of all individual orders that share the same price, though the underlying queue is usually ordered by time, with earlier orders filling first. The top of the book is the first row on each side. The best bid is the highest price someone is willing to pay. The best ask is the lowest price someone is willing to accept. The difference between them is the spread. A tight spread generally means more agreement about price, while a wide spread means less certainty or lower liquidity. Below the top level, deeper levels show larger amounts of capital at prices further away from the midpoint. The cumulative depth at each level tells the agent how much it would cost to buy or sell a specific dollar amount without moving the market price beyond that level. If the cumulative ask depth up to level five is only two thousand dollars, then an order to buy five thousand dollars will inevitably consume some of level six, seven, and beyond, resulting in a worse average fill price. This concept, often called slippage or market impact, is one of the most important numbers the agent extracts from the book. The agent does not care about the identity or intent behind the orders. It treats the book as a dynamic matrix of price, size, and side. It may also record the last traded price and the sequence ID of each update so that it knows whether its local copy is current or stale.

How does an agent connect to market data?

An agent needs a reliable pipe into the venue's data feed. There are two common patterns. The first is polling, where the agent sends a request every few seconds and receives a full snapshot of the book. This is simple but slow, and between polls the agent is blind to changes. The second is a streaming connection, often over WebSocket or server sent events, where the venue pushes every relevant change as it happens. For agents that need to react quickly, streaming is the standard choice. When the stream opens, the venue usually sends a snapshot of the full book. After that, it sends only deltas, which are incremental updates. A delta might add a new bid at a new price level, increase the size of an existing ask, or remove a level entirely because its last order was canceled or filled. The agent must maintain its own local copy of the book and apply each delta in the exact order received. If a delta arrives out of sequence, the local book becomes corrupted, and the agent must either request a fresh snapshot or halt trading until it can resynchronize. To prevent this, feeds include sequence numbers or timestamps. The agent checks that each new message is exactly one step ahead of the previous message. Some venues also send a heartbeat or a ping interval so the agent can detect a dropped connection. If the connection dies and the agent does not notice, it may trade against a stale book, which is dangerous. Through Felix, the agent can access normalized order book streams across multiple asset classes through a single API key. The underlying venue specific connection management, authentication, and delta parsing are handled by the infrastructure, but the agent still receives the normalized snapshot and delta objects it needs to reconstruct the book.

The exact request schema is in the docs; the shape looks like this:

{
  "market": "ETH-USD",
  "side": "bid",
  "price": 2650.00,
  "size": 1500.00,
  "sequence": 1849203
}

After the agent receives the data, it stores the book in memory or a local cache. It updates the cache on every delta, recalculates derived values such as mid price and cumulative depth, and then exposes those values to the strategy layer.

Why does normalization matter for cross venue trading?

An agent that trades only one asset on one venue can afford to learn that venue's native format. An agent that trades multiple assets across multiple venues cannot. Every venue has its own conventions for how prices and sizes are quoted, and those differences create friction that breaks automated logic. In crypto spot markets, one venue might quote bitcoin in whole coins, another in fractions down to one hundred millionth, and a third in satoshi terms. A perps venue might use contracts that represent a fixed dollar amount of exposure, while another uses contracts tied to the underlying token size. An options venue quotes premiums per contract, but the contract multiplier might be one hundred shares, so the total premium for the actual position is the quoted price multiplied by one hundred and then multiplied by the number of contracts. A prediction market can quote prices between zero and one, representing probabilities, but the payout is in dollars and the implied return is nonlinear. Without normalization, the agent would need a custom parser and a separate math module for every venue. Worse, it would need to convert between these formats inside its strategy logic, which is exactly where bugs appear. A strategy that compares a stock bid with a perps ask must be able to trust that both numbers are in the same unit, denominated in the same currency, and refer to the same notional exposure. Felix handles this by presenting every order book in a uniform format. Prices and sizes are expressed in plain US dollars. The agent sees a bid for one asset at a price of fifty dollars and a size of two thousand dollars, and it can compare that directly with a bid for another asset at a price of one hundred dollars and a size of one thousand dollars. The API normalizes the venue specific contract math, tick sizes, and multipliers before the agent ever sees the data. This allows the agent to reason about value and liquidity without knowing whether the underlying venue is a stock broker, a crypto exchange, or a perps platform. How to evaluate a trading API for an AI agent covers what to look for when you need this kind of unified data layer.

How does an agent turn depth data into a decision?

Having a correct local copy of the book is necessary, but it is not sufficient. The agent must decide whether to place an order, and if so, at what price and size. This decision is made by the strategy layer, which is simply a program that reads the reconstructed book and returns an action. The strategy does not feel momentum or fear missing out. It evaluates numbers. The most basic input is the mid price, calculated as the average of the best bid and best ask. The mid is a rough estimate of the current fair price, though it can be gamed by small orders placed just inside the spread. A more robust input is the microprice, which weights the best bid and ask by their relative sizes. If the best bid has ten thousand dollars of size and the best ask has one thousand dollars of size, the microprice shifts closer to the bid, suggesting that buying pressure is stronger. For larger orders, the agent looks past the top level. It calculates the weighted average fill price across the first N levels on the relevant side. This is the effective price it will pay if it sends a market order. It also computes the total depth required to fill its intended size. If the intended size exceeds the depth available within a reasonable range of prices, the agent knows it will suffer slippage. Some strategies choose to split the order into smaller slices that sit at different levels of the book, becoming maker orders that add liquidity rather than taker orders that consume it. The agent may also track book imbalance, which is the ratio of bid depth to ask depth within the first ten levels. A heavy bid imbalance suggests more buying interest, while a heavy ask imbalance suggests the opposite. Some strategies use this as a filter, requiring a minimum imbalance before entering a directional position. All of these calculations happen in milliseconds. Once the strategy emits a desired action, the agent passes it to the execution layer, which checks the action against the owner's hard limits. The execution layer verifies that the order size is within the scoped key's budget, that the resulting position would not exceed the position cap, and that the order is denominated in the correct US dollar terms. Only after these checks pass is the order sent to the venue. How an AI agent trades within a hard budget it cannot exceed explains how these constraints prevent overspending even when the book looks attractive.

What safety checks happen before an order is sent?

Reading the book is only half the task. The other half is knowing when not to trade. The agent may see a tight spread and deep liquidity, but if the market is moving faster than its latency allows, or if a recent delta shows anomalous size that looks like a fat finger error, the strategy can choose to wait. Beyond the strategy, the Felix infrastructure imposes hard limits. The agent cannot spend beyond its budget cap, cannot open positions beyond its limit, and cannot withdraw funds to any address the owner has not preapproved. These constraints are enforced by the infrastructure, not by the agent's own code, so a bug or prompt injection in the agent cannot override them. If the owner triggers the panic switch, the infrastructure flattens positions and revokes the key. The agent can read the book, but it cannot act outside its cage. There is also the risk of stale data. If the stream lags or the agent fails to apply a delta, its local book may show prices that no longer exist. A well built agent includes a sanity check: it compares the timestamp of its last book update against the current time, and if the gap exceeds a threshold, it pauses trading and requests a fresh snapshot. Some agents also cross reference the book against recent trade prints to confirm that the last traded price lies within the current best bid and ask. Trading can lose money, including everything. An agent that reads the book correctly is not guaranteed to profit. It is guaranteed only to act on the data it has, within the limits set by its owner. A practical checklist for non-custodial AI trading walks through how to set these boundaries before the first connection is opened.

How can a developer test this without risking capital?

Developers should not point an agent at live markets while they are still debugging how it parses depth or handles stale snapshots. Felix provides a paper trading mode where the agent connects to the same normalized feeds, reads the same order books, and submits orders that are simulated against real market depth. The agent experiences the same latency and slippage logic, but no capital moves. This is where you catch errors such as inverted bid and ask parsing, off by one level indexing, or failure to account for a venue's minimum size increment. It is also where you discover that your strategy logic looks at the top of the book but ignores depth, leading to simulated fill prices that are far worse than expected. Paper trading reveals whether the agent's local book reconstruction stays in sync with the feed over hours or days, which is difficult to verify in a short unit test. Common mistakes developers make with paper trading for AI agents lists the specific bugs that appear most often during this phase. When the agent handles paper book data correctly and respects its budget in simulation, the owner can authorize a live key. The transition from paper to live is explicit: the owner must approve a scoped key, set a budget cap, and define an exit plan before the agent can place its first real order.