How an AI agent reads an order book safely

An AI agent reading an order book through Felix never holds your funds or controls withdrawal addresses. The API returns normalized market data to the agent while enforcing scoped permissions, budget caps, and a kill switch that can revoke access instantly. This means the agent can observe prices and liquidity across stocks, crypto, perps, options, and prediction markets without being able to move your capital. The safety model treats data access as a privileged operation that must be bounded, logged, and revocable by the owner at any time.

What does an AI agent see when it reads an order book?

An AI agent connected to Felix does not browse a website or parse HTML. It receives structured, normalized data that represents the current state of a market. For a stock broker, this might be the top ten bids and asks for a ticker. For a perps venue, it could be the funding rate alongside the order book depth. For a prediction market, it might be the current bid and ask on yes or no shares. For an options venue, it could be the bid, ask, and implied volatility for a specific strike and expiration. The API flattens these venue-specific formats into one common shape so the agent can reason about liquidity without learning each venue's unique schema. The agent consumes prices, sizes, and timestamps to build an internal model of supply and demand. It does not receive any execution capability simply because it can read the book. The data is scoped to the markets the owner has authorized for that specific key. If the key is limited to crypto and perps, the agent cannot read stock or options order books. This scoping is the first layer of the safety model. It prevents an agent from leaking information across market types or reading data the owner never intended it to see.

Developers should treat order book access as a permission, not a default. When you connect an agent through an MCP tool or the REST API, you grant it a window into live market state. That window should be as narrow as the strategy allows. If the agent only trades one asset, it should only read that asset's book. The API enforces this by checking the key's market scopes on every request. A read operation that exceeds the key's scope returns an error. This is not merely a convenience feature. It is a structural boundary that limits the blast radius if an agent behaves unexpectedly. An agent that cannot read irrelevant markets is less likely to hallucinate trades on them. The connection through Claude, Cursor, or another MCP client uses the same scoped key, so the limits apply regardless of how the agent connects.

How does the API separate market data from execution rights?

Reading and executing are distinct operations inside the API, and they can be governed by distinct permissions. A developer can create a key that allows read access to an order book but disallows live trading entirely. This is useful during development and backtesting. The agent can observe real spreads and depth while operating on a paper trading balance. When the owner is ready, they can authorize a separate key with execution rights, or upgrade the existing key with explicit consent. Live trading never happens by accident. The authorization step requires the owner to confirm that the key may now submit orders that can lose real money. Until that confirmation occurs, the key is blocked from sending live orders regardless of what the agent reads. The API maintains this boundary at the infrastructure layer, not just in the agent's prompt. Even if the agent's reasoning loop decides to buy, a read-only key cannot execute.

The non-custodial architecture reinforces this separation. Funds remain in a wallet the owner controls. The agent can spend within limits, but it can never withdraw to itself or steal. Withdrawal addresses are owner-approved only. So even if an agent with execution rights misreads an order book and decides to trade, it cannot remove capital from the owner's control. It can only lose money within the budget cap, which is a separate limit on the key. This design means that reading an order book is never a stepping stone to stealing funds. The worst case is a bad trade, and that is contained by the position limits and exit plans that the owner configures before the agent starts.

How does a developer request order book data through the API?

Developers connect agents through MCP tools or the REST API. The connection uses a scoped key that defines which markets the agent may read and whether it may trade. The exact request schema is in the docs; the shape looks like this.

curl -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"market":"example-market","depth":10}' \
  https://api.felix.trade/v1/market-data/orderbook

The response contains normalized bids and asks in plain US dollars. The key's scopes are checked before the request reaches any venue. If the key lacks permission for the requested market type, the API returns an error before any data leaves the infrastructure. This means the agent cannot probe markets outside its scope. The YOUR_KEY placeholder represents a scoped key that the owner generates in the dashboard. Developers should rotate these keys regularly and revoke them when an agent is decommissioned. The API logs every request for audit purposes, so the owner can review what the agent read and when. This observability is part of the safety model. An agent that reads an order book without authorization leaves a trace that the owner can detect and block.

Why is non-custodial design essential for safe data access?

Non-custodial trading means the owner retains the private keys or account credentials that control the underlying funds. The agent operates through a delegated key that has spending limits, not ownership rights. This matters for order book reading because developers sometimes assume that live data access requires depositing funds into a custodial API account. It does not. The Felix API connects to markets non-custodially. The agent reads the book, and if authorized, submits orders that settle against the owner's wallet. The API normalizes venue-specific contract math so the agent reasons in plain US dollars. The agent does not need to parse tick sizes, lot sizes, or margin requirements manually. This reduces the chance that a misread value leads to an oversized order.

Because the owner controls the wallet, they can revoke the agent's access instantly. The panic or kill switch flattens any open positions and revokes the key. This applies to both reading and trading. When the switch is triggered, the agent loses its connection to the market entirely. It cannot read new data or place new orders. This is a critical safety feature. An agent that has gone off course may be reading manipulated or stale data and making bad decisions. Cutting off its data feed is as important as stopping its trades. The non-custodial model ensures that the owner can always pull the plug without requesting permission from a custodian. The checklist for non-custodial AI trading covers how to set up these controls before the agent first connects.

What guardrails prevent an agent from acting on bad or stale data?

Order books can change in milliseconds. An agent that reads a book and then acts on it seconds later is working with stale information. The safety model does not rely on the agent to know this. It relies on hard limits. Budget caps prevent the agent from losing more than a defined amount in a given period. Position limits prevent it from taking exposure beyond a set size. Exit plans can flatten positions automatically if certain conditions are met. These guardrails exist independently of the data quality. They are the second line of defense when the first line, the agent's reasoning, fails. Trading can lose money, including everything, and these limits exist to bound that risk.

Developers should also think about how the agent interprets the normalized data. The API returns plain US dollar sizes. This removes a common source of error: contract size math. If the agent had to do the multiplication itself, it might miscalculate and submit an order many times too large. The API handles this normalization so the agent sees a one-hundred-dollar ask as exactly one hundred dollars. This does not eliminate risk. The agent can still lose money. But it reduces the class of errors caused by venue-specific formatting. Sizing positions from first principles is still the developer's responsibility. The API provides accurate data and safe plumbing, but the strategy and the risk parameters belong to the owner.

How does dollar-based normalization reduce misreading risk?

Dollar-based normalization is a safety feature disguised as a convenience. Different venues express size in different units. One might use lots, another might use contracts, and another might use the base asset. An AI agent that has to convert between these units on every read is likely to make a rounding error or a decimal placement error. Such errors are dangerous. They can lead to orders that are ten or one hundred times larger than intended. The API removes this risk by presenting every order book level as a dollar amount. When the agent decides to buy two hundred dollars worth of an asset, the API translates that into the correct number of contracts or shares for the specific venue.

This normalization extends to the entire order book. The best bid, the best ask, and the depth at each level are all expressed in dollars. The agent does not need to know the tick size or the minimum lot size. It reasons in the same currency it uses for its budget cap. This alignment between reading and spending reduces cognitive load on the agent and reduces the chance that a mismatch between observation and action leads to a fat-finger trade. Developers should still verify that the agent understands the difference between the notional value it sees and the total risk it is taking. Reading a thick order book does not guarantee that the agent can fill at the price it sees. Slippage and liquidity changes are real. Suppose an agent reads a prediction market order book and sees a large ask at fifty cents. It might assume it can buy a large position at that price. In reality, the depth behind that ask could be thin, and the next ask could be at sixty cents. The agent needs logic to handle this, and the owner needs limits to contain the damage if the logic fails.

How should developers test an agent's order book reading before going live?

Paper trading exists so that an agent can read live order books and submit orders against a simulated balance. The market data is real. The execution is not. This lets developers verify that the agent parses the book correctly, identifies the right price levels, and does not confuse bid and ask. It also lets you test how the agent behaves when the book moves quickly or when liquidity thins out. If the agent makes a mistake, the loss is theoretical. Only after the owner explicitly authorizes a live key should the agent trade real money. The authorization step is a deliberate friction point. It forces the developer to confirm that the agent has been tested, that the budget caps are set, and that the kill switch is configured. This two-step process separates experimentation from production.

Developers can also use backtesting to validate strategies against historical order book snapshots. This is not the same as live reading, but it helps refine the agent's logic before it touches real data. The backtesting guide for AI trading strategies explains how to evaluate results before authorizing live access. When moving from paper to live, start with a small budget cap and a narrow market scope. Watch the logs. Verify that the agent reads the book, makes a decision, and then the API enforces the dollar sizing and limits correctly. Gradual exposure is safer than full deployment. Suppose an agent is designed to read a perps venue order book and trade on funding rate divergences. In testing, the developer might discover that the agent misinterprets a wide spread as a signal. It is better to find this in paper trading than with a live budget. The transition to live should happen only when the owner is confident that the agent reads accurately and the safety controls are active. Paper trading is free, but mistakes in live trading can cost everything.