How should you size positions for an AI trading agent in 2026

Position sizing for an AI trading agent in 2026 is not a question of maximizing expected value. It is the process of defining how many dollars the agent is allowed to place at risk, and what happens when that limit is reached. The owner configures a fixed budget, scoped keys, and per-trade limits through one API, and the agent cannot override these boundaries because the infrastructure enforces them at the wallet level. This turns position sizing from a speculative tactic into a safety architecture.

What is the right unit of risk for an agent?

An agent does not think in shares, contracts, or tokens. It reasons in abstract goals and natural language. The owner must translate those goals into a concrete unit of risk, and the simplest unit is the US dollar. The Felix API normalizes venue-specific contract math so that an order can be stated in plain dollars, and the system converts that into the correct number of shares on a stock broker, contracts on a perps venue, or tokens on a crypto venue. This removes an entire category of error where an agent miscalculates notional size because it misunderstood a tick size, decimal place, or multiplier. Sizing in dollars also makes risk comparable across all five market types. A $200 position in a stock and a $200 bet on a prediction market represent the same initial capital at risk, even though the volatility and payoff structure differ. The owner should constrain the agent so that every order is denominated in the amount of capital it can lose, not in the face value of the instrument. In perps and options, the notional value can be many times larger than the actual risk, especially when leverage or premium is involved. The agent should not be given a target notional; it should be given a target risk. For prediction markets, the risk is nearly binary. The agent either loses the wager or wins a return, and the capital is often locked until the market resolves. Sizing here is simply the amount of the bet. The owner should cap individual wagers at a small fraction of the total budget, because the outcome is discrete and the funds are unavailable for other trades during the resolution period. By keeping the unit of risk constant and visible, the owner can audit the agent’s behavior without converting between market-specific conventions.

How do you set a budget cap that actually limits damage?

A position size is only safe if the total pool of capital is bounded. The owner should create a scoped key with a hard budget cap before the agent is allowed to send any order. This cap is not a guideline; it is a protocol-level limit enforced by the non-custodial infrastructure. Funds sit in a wallet the owner controls, and the agent can spend within the cap but can never withdraw to itself or to an unapproved address. If the agent reaches its daily, weekly, or total budget, it halts. This is a safety feature, not a failure mode. The owner can layer a daily loss limit underneath the total budget. Suppose the total budget is $5,000, but the daily loss limit is $500. A streak of losing trades will trigger a cooling-off period before the entire allocation is consumed. How a single API keeps AI trading agents safe by design explains this architecture in detail. The key insight is that the API sits between the agent and the market, so it can reject any order that would breach the cap, regardless of how the agent reasons. The owner can also set position limits, such as a maximum of $500 per trade or a maximum of three open positions at once. These limits are configured outside the agent, so even if the agent's reasoning is compromised, the financial damage is bounded. The owner should set the cap at an amount they are fully prepared to lose. Trading can lose money, including everything allocated to the agent. The panic switch, or kill switch, provides a final layer of protection. If the owner observes unexpected behavior, they can flatten all positions and revoke the key instantly. Budget caps and position limits are the first line of defense; the kill switch is the last.

Why should position sizing differ across market types?

A single position sizing rule does not fit all five market types. Stocks, crypto, perps, options, and prediction markets have different volatility profiles, liquidity depths, and leverage characteristics. The owner should define market-specific sizing fractions rather than letting the agent apply a uniform contract count or notional value everywhere. Suppose the owner allocates a total budget of $10,000 to the agent. They might decide that any stock position is sized at 1% of the budget, or $100, because equity moves are typically moderate and the position can be held for the long term. For a perps venue, they might set the rule at 0.25% of the budget, or $25, because leverage amplifies both gains and losses. The API still accepts a dollar-denominated order, but the owner’s pre-trade logic scales the dollar amount down for higher-risk markets. This is a human decision, not an agent discovery. Options require additional care. A long option position is limited to the premium paid, but the path and theta decay can erode the position quickly. The owner should size option trades so that the premium represents a small fraction of the budget, and they should avoid letting the agent sell naked options unless they have explicitly modeled the unlimited downside. Prediction markets, as noted, are binary. A $100 bet is a $100 risk. The owner should treat each prediction market position as a standalone wager with no diversification benefit, and size accordingly. The agent does not inherently understand these differences. The owner must encode them into the strategy, the prompt, or the pre-trade checks. The API provides the plumbing, but the risk logic belongs to the owner.

How do you build an exit plan before the agent enters?

Position sizing is incomplete without a planned exit. The dollar amount at risk is not the entry price multiplied by the quantity; it is the distance from the entry price to the stop loss, multiplied by the quantity, plus any slippage. Every trade should have a take-profit and a stop-loss defined in advance, and the agent should submit them as bracket or conditional orders at the same time it opens the position. Bracket orders tie the entry, target, and stop into a single package, so the agent cannot enter without also committing to the exit. How to build an exit plan that automates take profits and stop losses covers the mechanics of this approach. The exit plan is part of sizing because it determines the realized loss. A tight stop on a $200 position might risk only $10. A wide stop on the same $200 position might risk $50. The owner should size the position so that the maximum distance to the stop, multiplied by the number of units, equals the predetermined dollar risk for that trade. If the stop cannot be placed tightly enough, the position size must be reduced. The agent should not be allowed to move the stop loss further away to avoid a loss. This is a common failure mode in automated systems. The owner can prevent it by setting hard stop distances in the scoped key parameters, or by requiring that any modification to an exit plan reduces the total risk rather than increasing it. In 2026, agents can use webhooks to update exits based on new data, but the owner should review whether the updated exit still respects the original risk budget.

When should you move from paper to live sizing?

Paper trading exists for testing. The purpose is not to generate hypothetical profits, but to verify that the agent respects sizing rules under realistic conditions. The owner should watch for concentration, drift, and escalation. Does the agent stay within the per-trade limit? Does it spread capital across markets, or does it pile into one? Does it honor the exit plan, or does it cancel stops? What it takes to move an AI trading agent to live trading in 2026 outlines the full checklist. The transition to live trading should happen only after the agent has demonstrated consistent adherence to the budget and position limits for a meaningful period. Live trading requires explicit owner authorization of a key, which is a deliberate friction point. The owner should not authorize a large budget on the first day. Instead, the owner should start with a small budget. How to start an AI agent with a small budget explains why this matters. A small budget forces the agent to prove it can manage scarce capital before it is trusted with more. It also limits the damage from a latent bug that did not appear in paper mode. The owner can increase the cap incrementally, but only after reviewing logs and confirming that the agent’s sizing behavior remains stable.

What does a developer need to enforce sizing programmatically?

Developers connect agents through MCP tools or the REST API. The integration layer is where sizing rules are translated into actual orders. The exact request schema is in the docs; the shape looks like this.

curl -X POST https://api.felix.trade/ORDERS_ENDPOINT \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "market": "EXAMPLE",
    "direction": "buy",
    "amount_usd": 150.00,
    "risk_cap_usd": 50.00
  }'

The developer should not rely on the agent to calculate its own position size. The sizing logic should live in a pre-trade filter, either in the agent’s prompt instructions or in a separate risk layer that validates the order before it reaches the API. The API rejects orders that exceed the scoped key’s budget, but the developer should also validate that the amount_usd field matches the strategy’s rule. MCP tools let Claude, Cursor, and other clients call trading functions, and the developer can wrap those functions with hard-coded maximums. For example, a developer might expose a tool called buy_stock that accepts a ticker and a dollar amount, but the tool itself caps the dollar amount at $500 and checks the remaining daily budget before forwarding the request. This means the agent can ask for any size, but the tool enforces the ceiling. The agent cannot bypass the tool because it does not have direct access to the API key. This pattern, where the agent proposes and the infrastructure disposes, is central to safe agentic trading.