How AI agents misread order books step by step

AI agents often misread order books by treating a single snapshot as a static truth, ignoring how liquidity shifts between the moment of observation and the moment of execution. They step through the book level by level without accounting for depth decay, hidden orders, or latency, which leads to incorrect size estimates and unrealistic price expectations. These mistakes compound when agents aggregate data across multiple venues without normalizing for tick size, lot size, or fee structures. The result is a systematic overestimation of available liquidity and an underestimation of slippage, both of which can increase losses and erode the very edge the agent was designed to capture.

Why do agents treat order book snapshots as static prices?

Many agent implementations fetch an order book snapshot, extract the best bid and ask, and then proceed as if those prices are fixed inputs for a decision tree. This is a category error. An order book is a signal of intent, not a contract. By the time the agent has parsed the JSON or MCP response, market participants may have added, removed, or modified orders. When the agent writes a prompt or a function call that says the current price is X because the best ask is X, it locks itself to a value that may already be stale. The step-by-step logic then assumes the book will still contain that exact liquidity at execution time, which is rarely true in any market with meaningful turnover.

This mistake is reinforced by backtesting frameworks that replay historical snapshots as if they were executable. An agent trained on static snapshots learns to expect perfect fill at the best ask, which almost never happens in live markets. The transition from paper trading to live trading often reveals this gap, because paper engines may fill at the snapshot price while real venues match against a moving book. The agent has not learned to expect partial fills, slip to deeper levels, or cancellation of the orders it was counting on. A reliable pipeline must treat each snapshot as a transient event, not a persistent state. How to build a reliable market data pipeline for trading agents covers the infrastructure side of this problem, including buffering and timestamp validation that reduce the illusion of stability.

The problem is exacerbated when agents use large language models that consume the snapshot as part of a long context window. The model may summarize the book, reason about trends, and then emit a tool call minutes later. To the model, the book is still the same object, but to the market, it is a completely different object. The step-by-step breakdown the model produces is intellectually satisfying and often wrong. Agents that operate this way need to either bypass the reasoning step for time-sensitive data or re-validate the book immediately before execution. Otherwise, the static snapshot assumption becomes a systematic source of negative drift.

How does depth decay invalidate simple size calculations?

After reading the best bid and ask, an agent often calculates the size it can trade by walking down the book and summing depth until it reaches its target notional value. This step-by-step summation assumes that the orders it counted will still exist when its own order reaches the venue. In reality, depth decays as other traders take liquidity, and the agent's own order may itself move the market if it is large relative to the book. The error is usually invisible in small notional trades, but it becomes severe when the agent scales up. Suppose an agent sees fifty thousand dollars in cumulative ask depth and decides to buy forty thousand. It may assume a fill near the best ask. If thirty thousand of that depth consists of orders from a single participant who cancels before the agent's order arrives, the remaining ten thousand may be at prices far worse than expected. The agent then experiences slippage it never modeled and may violate its own risk thresholds in a single trade.

This risk is present across stocks, crypto, perps, and options, though the exact mechanics of lot sizing and tick increments differ. Felix normalizes order sizing in plain US dollars so the agent can reason about notional exposure without learning venue-specific contract math, but the agent still needs to respect the actual depth available on the venue. The API cannot create liquidity that does not exist. Agents that ignore this often discover that their supposedly conservative position sizing logic is actually aggressive, because they sized against an illusion of depth. One API for every market explains how the API abstracts sizing, though the agent must still interpret the book correctly rather than trusting cumulative depth as a guaranteed fill path.

Some developers attempt to solve this by adding a safety margin, such as assuming only half the displayed depth is real. This is a heuristic, not a model, and it fails when the book is genuinely thick or when the half the agent chooses happens to be the half that cancels. A better approach is to size orders against a budget cap and a position limit rather than against the visible book alone. The book informs the agent about likely cost, but the hard limits prevent the agent from relying on that information too heavily. This separation of estimation from authorization is a core principle of non-custodial agent design.

What happens when agents confuse nominal quotes with execution costs?

Another common mistake is equating the quoted mid-price or best ask with the true cost of execution. An agent that reads the order book, computes the average of the best bid and ask, and then uses that mid-price as its fair value benchmark is ignoring the spread, fees, and market impact. The step-by-step logic might proceed: read book, compute mid, compare to model prediction, decide to trade. But the actual entry price will be the ask plus taker fees, and the exit price will be the bid minus taker fees, assuming the agent takes liquidity. The spread alone can consume the expected edge on a short-term strategy, and that is before accounting for slippage if the agent's size exceeds the top level.

Agents also fail to account for the difference between maker and taker fee structures when they reason about limit orders. If the agent places a limit order on the book, it may pay a different fee, but it also faces the risk that the price moves away before fill. The nominal quote does not capture this timing risk. When agents automate strategies that rely on frequent small edges, ignoring the full cost stack turns a theoretically positive strategy into a negative one after fees and slippage. The consequences are straightforward: the agent overtrades, exhausts its budget cap, and accumulates positions that cost more to unwind than expected. This is why safety controls such as budget caps and exit plans are not optional accessories. How to automate exit plans and take-profit rules for an AI trading agent describes how to hard-code exits before the agent enters, so that misreadings do not compound into unbounded losses.

The confusion is worsened by interfaces that display the mid-price prominently. An agent scraping a user interface or a simplified API may default to the mid-price as the market price because it is the single number presented. But trading is not done at the mid. The bid and the ask are the only actionable prices, and the difference between them is a cost the agent must cross twice to complete a round trip. Agents that do not model this round-trip cost as a first-class variable will consistently overestimate their profitability. Every strategy looks better when entry and exit are assumed to be free.

How should an agent request book data without hardcoding venue assumptions?

When developers build agents that fetch order books directly from venue APIs, they often embed assumptions about field names, precision, and response shapes. This creates brittle logic that breaks when a venue changes its format or when the agent is pointed at a new market type. A safer approach is to request normalized book data through an abstraction layer that returns a consistent shape regardless of whether the underlying market is a stock, a perp, or a prediction market. The exact request schema is in the docs; the shape looks like this:

{
  "key": "YOUR_KEY",
  "market": "EXAMPLE_MARKET_ID",
  "depth": 10
}

The response provides bids and asks as arrays of price and size in US dollars, with no venue-specific contract math. The agent can then walk the arrays without parsing decimal shifts or lot multipliers. This normalization reduces one class of error, but it does not eliminate the need for the agent to treat the response as a snapshot that is already aging. Developers should still implement local buffering and timestamp checks rather than calling the API synchronously inside a decision loop. Agents that pause to reason aloud or generate long explanations before acting are particularly vulnerable, because the book they reasoned about may have changed several times before the order is sent.

Why does latency make every step-by-step reading stale?

Even if an agent correctly parses the snapshot, sums depth conservatively, and includes fees in its cost model, it faces a temporal problem. The order book state at time T is not the state at time T plus fifty milliseconds. In volatile conditions, the entire best bid and ask can refresh dozens of times per second. An agent that reads the book sequentially, level by level, in a loop may be analyzing a composite image assembled from different moments. The top level might be from one millisecond, the third level from the next, and the fifth level already stale. The step-by-step reading becomes a fiction that never existed as a whole.

Latency appears in three places: the data feed from the venue, the agent's own processing time, and the round-trip to submit the order. If the agent's reasoning chain is long, for example if a large language model is generating a trading rationale before calling a tool, the book may have changed several times. The agent should minimize the gap between observation and action, and it should never re-read the book, think, and then act on the old read without verifying current conditions. This is particularly dangerous when multiple agents or strategies share a single key. One agent may read the book, conclude there is liquidity, and submit an order just as another agent submits its own order against the same depth. The total desired size may exceed the actual depth, causing both to slip. Coordinating agents so that one agent's book reading does not collide with another's execution requires shared state or serialized access, not just independent tool calls.

Some venues offer co-located feeds or faster WebSocket connections, but the agent's internal architecture can still introduce delay. A parsing loop that iterates over bids and asks, converts strings to floats, applies filters, and then passes the result to a decision module may consume tens of milliseconds. In that time, high-frequency market makers have already updated their quotes. The agent is not trading against the book it sees. It is trading against the book that exists now, which is a different book. Accepting this asymmetry is necessary for setting realistic expectations about fill quality and for designing strategies that do not depend on microsecond precision.

How can safety controls compensate for misreadings?

No amount of parsing precision removes the risk that an agent will misread the book or that the market will move against it. Safety controls exist to bound the damage. Scoped keys ensure that even if the agent misreads liquidity and overtrades, it cannot exceed a pre-set budget. Position limits prevent the agent from building an oversized position because it thought the book was deeper than it was. A kill switch flattens positions and revokes access if the agent behaves unexpectedly. These controls are especially important because order book misreadings often produce immediate, unintended exposure rather than gradual drift.

The agent thinks it is buying a small amount at a fair price, but it actually receives a large fill at a bad price because it misread the depth or because the depth vanished during latency. A panic switch that the agent cannot override is the final backstop. It does not prevent the first mistake, but it prevents the mistake from becoming a disaster. How to build a kill switch your trading agent cannot override explains how to implement this last line of defense, and why it should be configured before the agent is allowed to trade with real money.

Developers sometimes resist these controls because they appear to limit the agent's autonomy. But autonomy without bounds is not a feature. It is a liability. The purpose of an agent is to execute a strategy within constraints defined by the owner, not to discover the limits of the market by exceeding them. Order book misreadings are one of the fastest ways an agent hits an unintended limit, and the owner should define that limit in advance rather than discovering it during a drawdown. The non-custodial model ensures that the owner retains control over the funds and the rules, while the agent retains only the ability to act within them.