How AI agents size positions when trading real money across markets

Position sizing for an AI agent trading real money requires translating abstract strategy decisions into concrete dollar amounts while enforcing strict, infrastructure-level boundaries. The Felix API accepts plain dollar values from the agent and normalizes them into venue-specific contract math, shares, or token amounts behind the scenes. Safety constraints are applied at the API layer, so the agent cannot exceed its owner-defined budget regardless of how its reasoning model behaves. This architecture treats the agent as a bounded executor that proposes trades but never controls the final risk limits.

Why does position sizing need special architecture for AI agents?

A manual trader sees a price, decides on a percentage of capital, and types an order into a terminal. An AI agent follows a prompt and can generate decisions at machine speed without the same visual feedback or hesitation. If its sizing logic contains an error, the agent will not notice a typo or a decimal place mistake. It will simply repeat the mistake until stopped. A human might misread a screen once. An agent can misread its own output in a loop, generating dozens of incorrect orders in seconds. This means position sizing cannot rely on the agent's judgment alone. It must rely on deterministic, hard-coded limits that live outside the agent's reasoning loop. The architecture must treat the agent as a fast but fallible system that requires external guardrails.

The architecture therefore separates intent from execution. The agent expresses intent in plain dollars. The API checks that intent against a set of owner-approved constraints. Only if the intent passes every check does it convert into a market-specific order. This separation is the core difference between agentic trading and manual trading. A human can override a gut feeling. An agent lacks that override unless the infrastructure provides it. hard limits differ from manual trading

Trading can lose money, including everything. An agent with flawed sizing logic can accumulate oversized exposure faster than a human can react. The architecture must assume failure modes are probable and design accordingly.

How does the API normalize dollar sizing across five market types?

The API presents a single interface for stocks, crypto, perps, options, and prediction markets. When an agent sends a size, it sends a dollar amount. The API then translates that amount into the native units required by the underlying venue. For stocks, the API converts the dollar amount into a share count, including fractional shares where the connected stock broker supports them. For crypto, it calculates the token amount based on current market price. For perpetual futures, it determines the notional value and contract size at a perps venue. For options, it accounts for the contract multiplier, typically one hundred shares per contract, and adjusts the dollar input so the agent does not accidentally request far more notional exposure than intended. For prediction markets, it converts dollars into the correct share count based on the current market price of the outcome.

The agent does not need to know that an options contract represents one hundred underlying shares, or that a perps venue uses a specific contract size. This abstraction reduces prompt complexity and prevents a common source of error, where an agent confuses notional exposure with contract count. Developers benefit because they do not need to maintain separate sizing logic for each venue. The prompt can state a simple rule, such as allocate five percent of the daily budget per trade, and the API handles the rest. This reduces the surface area for errors and makes the agent easier to audit. The owner can also change the underlying venue or add a new market type without rewriting the agent's core logic, because the dollar interface remains constant.

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

curl -X POST https://api.felix.trade/v1/orders \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{\n    "market": "options",\n    "symbol": "EXAMPLE-OPTION",\n    "side": "buy",\n    "dollar_notional": 500\n  }'

What guardrails prevent an agent from oversizing a position?

Oversizing can happen in two ways: a single order that is too large, or a sequence of small orders that collectively exceed a safe threshold. The architecture addresses both. Single-order limits are enforced by scoped API keys. An owner can configure a maximum dollar amount per order. If the agent requests a trade above that threshold, the API rejects it before any market interaction occurs. Position limits cap the total exposure per symbol, market type, or overall portfolio. Once the cap is reached, additional orders in that scope are blocked.

Beyond single-order limits, the architecture can also enforce order frequency and velocity controls. An agent might be permitted to place ten orders per hour, or to wait a minimum interval between trades. This prevents a runaway loop from building a position through many small orders that individually pass the size check but collectively violate risk intent. Budget caps operate over time. An owner might allow the agent to trade one thousand dollars per day. When the cumulative spend reaches that limit, the API stops accepting new orders until the budget resets or the owner intervenes. This prevents an agent from deploying capital faster than intended.

There is also a panic or kill switch. An owner can trigger it to flatten positions and revoke the agent's access immediately. This exists outside the normal order flow and does not depend on the agent's cooperation. Before going live, owners should audit your guardrails to confirm these limits are configured correctly.

How does the non-custodial wallet model affect sizing decisions?

In a non-custodial setup, the owner's funds sit in a wallet that the owner controls. The agent receives a scoped key that lets it place orders, but it cannot withdraw funds to an external address. The agent can spend what is in the wallet, but only within the owner-defined budget and position limits. This model changes sizing in a practical way. The agent cannot create leverage through hidden credit or overdraft. It can only trade what is present and permitted. If the wallet balance drops, the maximum possible position size drops with it.

The API queries the wallet balance before confirming a size. If the agent requests a five hundred dollar order but the wallet only holds three hundred dollars, the request is rejected. This check happens after the budget cap check but before the order reaches the market. It ensures that the agent sizes positions against real, available capital rather than theoretical allocations. Because withdrawal addresses are owner-approved only, the agent cannot solve a losing streak by moving funds to a different wallet it controls. The sizing architecture is therefore coupled to a physical balance that the agent can deplete but cannot steal. You can read more about this in our overview of the non-custodial custody model.

Trading can lose money, including everything. A non-custodial model protects against theft, but it does not protect against poor sizing decisions that drain the wallet through legitimate trades.

How should developers test sizing logic before authorizing live trading?

Developers should treat sizing logic as critical infrastructure and test it in two stages: paper trading and backtesting. Paper trading lets the agent run against live market data without real capital. It is the best way to observe whether an agent's prompt produces reasonable dollar amounts under varying conditions. A strategy that looks correct in a static example may generate unexpected sizes during volatility. Paper mode reveals those patterns without financial cost.

Backtesting applies the same sizing rules to historical data. It helps developers understand how the strategy would have allocated capital across past market regimes. This is not a prediction of future profits, because past performance does not guarantee future results. It is a way to verify that the sizing logic behaves as intended when prices, volatility, and correlations change. Developers can backtest your sizing logic using the same API shapes that will later run live.

Before authorizing a live key, confirm that the budget caps, position limits, and kill switch are active. Start with a small live budget and compare the live fills to the paper fills. Look for discrepancies in sizing behavior caused by market impact or partial fills. If the agent behaves consistently, the owner can raise the budget cap. If the sizing logic shows flaws, revoke the key, adjust the prompt, and return to paper testing. This gradual approach reduces the chance that an untested sizing error causes significant losses, because trading can lose money, including everything.