How an AI agent executes an order from decision to fill

When an AI agent decides to trade, it emits a structured intent that describes the market, side, notional size, and instrument. The trading infrastructure receives this intent, validates it against owner-configured safety limits, converts the plain dollar amount into venue-specific instructions, submits the order to the appropriate market, and reports the fill or failure back to the agent. Every step is non-custodial: the agent can request trades within scoped boundaries but can never access the wallet itself, move funds to a new address, or withdraw capital. The owner alone controls the wallet and the destination addresses.

What happens when an agent first decides to trade?

An agent begins with a reasoning step. It evaluates market data, its current positions, and its objective function, and concludes that a trade is warranted. It then invokes a tool to act on that conclusion. The tool is either an MCP server function, such as when the agent runs inside Claude, Cursor, or another MCP client, or a direct REST call from a custom system. The payload is a structured intent, not a natural language sentence. The intent specifies the market type, the side, the notional amount in US dollars, the instrument identifier, and the order type, which may be market or limit. It can also include optional conditions, such as a limit price, time in force, or a trigger condition. This layer is deliberately abstract. The agent expresses what it wants to accomplish, not how to accomplish it at a specific venue. The infrastructure treats the intent as a request that must be validated, not as a command that must be obeyed blindly. Separating intent from execution means the agent does not need to know venue APIs, authentication schemes, or contract specifications. It also means the owner can change the underlying routing, add new markets, or rotate credentials without changing the agent's code. This abstraction is the foundation of using one API for every market.

How do safety checks intercept the order before it reaches the market?

Once the intent arrives at the infrastructure, it enters a validation layer that the agent cannot see or override. The first check is key scope. A scoped key might be permitted to trade stocks and crypto, but explicitly blocked from options, perps, or a prediction market. Second, the system checks whether the key is authorized for live trading or restricted to paper trading. If the owner has not explicitly promoted the key to live mode, the order is rejected. Third, the system evaluates budget caps. If the agent has already spent its daily, weekly, or all-time limit, the new order is blocked. Fourth, it checks position limits and any active exit plan. If the order would push the portfolio beyond a per-asset exposure ceiling, a total notional cap, or conflict with an automated exit plan, the system halts it. Fifth, it checks the drawdown floor and the kill switch state. If the account has declined to the maximum allowable loss, or if the owner has activated the panic switch, all new orders are stopped. These limits are enforced by the infrastructure, not by the agent's own prompt or code. The agent cannot reason its way around them, hide them, or ask for an exception. You can read more about how these limits work in practice in How an AI agent trades stocks within hard limits it cannot cross. For agents that trade across multiple asset classes, How to keep a multi-market agent portfolio from blowing up explains how position limits interact across stocks, crypto, and derivatives.

How does the API normalize orders across five market types?

After the safety checks pass, the API begins normalization. This is the process of converting the agent's plain language intent into the precise instructions that a specific venue requires. The agent requested a notional amount in US dollars. For a stock broker, the system converts that dollar value into the correct number of whole and fractional shares at the prevailing price. For a spot crypto venue, it converts the amount into the correct units of the base asset, accounting for minimum order sizes. For a perps venue, it maps the dollar exposure to the correct contract size and margin requirements, and it may apply leverage constraints that the owner configured. For an options venue, it handles contract multipliers, strike spacing, and expiration dates. For a prediction market, it converts the dollar amount into the appropriate number of outcome shares, which may trade in discrete increments. The agent does not need to know lot sizes, tick sizes, margin formulas, or venue-specific identifiers. It does not need to calculate how many shares equal five hundred dollars, or how many contracts represent that same exposure on a perps venue. This is the core benefit of sizing orders in plain dollars. The same shaped intent can route to any asset class by changing a single field. There are common mistakes developers make when assuming all markets behave identically, which we cover in Common mistakes when using one API for every market with real money. The exact request schema is in the docs; the shape looks like this:

{
  "key": "YOUR_KEY",
  "market": "stocks",
  "side": "buy",
  "notional": 500,
  "symbol": "EXAMPLE",
  "type": "market"
}

The API then routes the translated order to the correct venue using the owner's connected accounts. The agent never sees venue credentials, endpoint URLs, or authentication tokens. The order is submitted under the owner's identity, and the funds remain in the owner's wallet at all times. The agent is a requestor, not a custodian. If the venue requires additional parameters, such as a time in force or a post-only flag, the infrastructure applies sensible defaults based on the order type and market, unless the agent explicitly specified otherwise. The agent remains unaware of these details. The owner can rotate credentials, change default routing, or add redundancy without the agent knowing or caring.

What happens while the order is waiting for a fill?

Once submitted, the order enters a lifecycle that the agent can observe but cannot control beyond the actions the owner has allowed. The status moves from pending to open, and then to filled, partially filled, rejected, or cancelled. A market order is typically filled immediately if the venue has sufficient liquidity, though there is no guarantee of instant execution or of the exact price. The actual fill price may differ from the last traded price the agent saw, a phenomenon known as slippage. Slippage can be positive or negative, and the agent should not assume it will always receive the mid price. A limit order rests on the venue's order book until the price is hit or until its time in force expires. If the agent requested a large notional amount relative to the available liquidity, it may receive a partial fill. In that case, the agent receives a report showing the filled portion and the remaining open quantity. It can then decide whether to leave the order open, modify the limit price, or cancel the remainder. The infrastructure reports what actually happened, not what the agent expected. Trading can lose money, including the full notional amount, and the agent must account for fees, slippage, and adverse price movement in its reasoning. If the agent relies on webhooks or automation to trigger further actions, those carry their own risks that we discuss in How to manage webhook and automation risks for trading agents in 2026.

How does the agent receive the result?

After the order fills, fails, or is cancelled, the system compiles a structured report and returns it to the agent. The report contains the executed average price, the filled notional amount, any fees paid, and the resulting position or cash balance. For stocks and spot crypto, the agent now holds an asset in its portfolio. For a perps venue, the agent holds an open position with unrealized profit or loss that changes as the mark price moves. For an options venue, the agent holds a contract that may expire worthless, be exercised, or be sold back to the market. For a prediction market, the agent holds outcome shares that resolve to zero or one when the event concludes. The agent uses this report to update its internal memory, context window, or state database. Its next trading decision must be based on actual positions, not intended ones. If the agent fails to update its state after each fill, it will operate on stale assumptions. It might double its exposure by placing the same trade again, or it might fight against its own previous orders by taking an offsetting position without realizing it already holds one. This feedback loop is critical for coherent behavior over multiple trading sessions.

What can go wrong during execution?

Several failures can occur after an intent passes safety checks but before it reaches final settlement. The venue may reject the order due to insufficient margin, a trading halt, or a sudden change in minimum order size. The price may move between the agent's decision and the order's arrival, causing the fill to execute at a level that changes the risk profile. A partial fill may leave the agent with an unintended position size that does not match its model. In extreme cases, a venue may experience an outage after the order is accepted but before it is acknowledged, creating a temporary uncertainty about whether the order is live or dead. The infrastructure handles reconciliation by querying the venue for the true state and reporting it back to the agent. If the kill switch is activated while orders are open, the system can flatten positions and revoke the key. The owner retains full custody throughout, and the agent cannot prevent a shutdown or a withdrawal to an owner-approved address. These are ordinary operational risks of automated trading, and the owner should expect them and plan accordingly.