Agentic tradingRisk managementPosition sizingDevelopers

How to size positions for an AI trading agent step by step

A step-by-step checklist for setting position sizes that keep an AI trading agent within budget caps, hard limits, and owner-defined risk boundaries without guesswork.

By the Felix team9 min read
Key takeaways
  • 01Position sizing is a structural guardrail, not a profit prediction, and it should be enforced outside the agent's reasoning loop.
  • 02The owner should define a total budget cap in notional dollars, then subdivide it into per-market envelopes and per-trade ceilings that the API enforces.
  • 03Open positions drift in notional value as markets move, so the owner must pre-define rules for trimming, rebalancing, or recycling freed capital.
  • 04Every entry size must be paired with an exit plan that accounts for how easily that size can be unwound under stress.
  • 05Paper trading should validate sizing compliance across all market types before the owner authorizes a live key.

Position sizing for an AI trading agent is the process of translating an owner-controlled budget into discrete orders that cannot exceed hard limits. It is not a prediction of profit, but a structural guardrail that caps how much capital the agent can expose at any moment. Trading can lose money, including everything, and position sizing does not prevent losses; it only limits their scale. This checklist walks through the practical steps to build that boundary, from total budget allocation down to the exact dollar value of a single order.

What is the maximum capital the agent is allowed to touch?

Before the agent submits its first order, the owner must decide the total dollar value the agent can deploy across all markets. This number belongs in a budget cap that lives outside the agent's reasoning loop, enforced by the API or wallet permissions, not by the agent's own logic. The cap should ignore leverage multipliers and focus on the actual notional dollars at risk. Suppose the owner funds the wallet with ten thousand dollars and sets a five thousand dollar cap. The agent cannot reach the remaining five thousand even if it believes an opportunity is urgent. This distinction between wallet balance and spendable budget prevents accidental all-in bets. It also creates a reserve that remains untouched if the agent hits a streak of losing trades. The owner should treat this cap as the single source of truth. If the agent asks for a trade that would push total deployed capital over the cap, the system rejects it. There is no appeal process and no override prompt that can bypass the limit. This is the foundation of the sizing stack, and every other rule sits on top of it. The owner should also separate one-time seed capital from recurring budget. If the agent is expected to trade for a month, the owner might divide the five thousand dollar cap into weekly tranches of one thousand two hundred fifty dollars. This prevents the agent from burning through the entire budget in the first week. It also gives the owner a natural review point to adjust the cap based on observed behavior without rewriting the entire policy.

How do you convert a dollar budget into a per-trade size?

The Felix API sizes orders in plain US dollars, so the agent does not need to compute contract quantities, lot sizes, or margin multipliers. The owner defines a maximum dollar amount per trade, and the API translates that into the correct units for the venue. A simple method is to divide the total budget cap by the intended number of concurrent positions. Suppose the cap is five thousand dollars and the agent is allowed to hold up to five positions at once. Each position might then be limited to one thousand dollars. The owner can further refine this by assigning different weights to different markets. A stock position might carry a one thousand dollar allocation, while a perps position carries five hundred dollars because the owner considers it more volatile. Another useful constraint is the maximum number of orders the agent can place in a single session. Even if each order is small, a high frequency of entries can accumulate to a large gross exposure. The owner should set a session order count or a session gross notional limit that sits alongside the per-trade limit. This prevents the agent from splitting a single large intent into many tiny slices that evade the per-trade ceiling. The exact request schema is in the docs; the shape looks like this:

{
  "key": "YOUR_KEY",
  "market_type": "perps",
  "dollar_size": 500,
  "side": "buy",
  "symbol": "BTC-USD"
}

The agent should not dynamically increase this size based on recent wins or losses unless the owner explicitly updates the cap. Compounding into larger sizes after a profitable stretch is a common failure mode that silently breaks the original risk assumption. The owner should treat the per-trade size as a constant parameter that changes only through a deliberate configuration update, not through market feedback. It is also useful to set a floor. If the remaining budget is below the per-trade minimum, the agent should stop opening new positions rather than scale down to a trivial size that cannot justify transaction costs or slippage. The owner should codify both the ceiling and the floor in the agent's instructions so that the sizing logic is explicit and auditable.

How should you set per-market and per-side limits?

Not all markets behave the same way, so the sizing plan should treat each market type as its own budget envelope. Stocks, crypto spot, perpetual futures, options, and prediction markets each have different volatility profiles and settlement mechanics. The owner can scope the agent's key so that a single budget cap is subdivided by market type. Suppose the owner allows two thousand dollars in stocks, one thousand dollars in prediction markets, and one thousand dollars in perps, even though the total cap is four thousand dollars. Within each envelope, the owner can also set side limits. If the agent is meant to be long-biased, the owner can restrict short notional to a smaller fraction or disable it entirely. These scopes are enforced by the infrastructure, not by hoping the agent respects a prompt. This is part of the non-custodial trading checklist and prevents the agent from drifting into unintended exposure. The owner should also consider correlation. If the agent holds two stock positions in the same sector, the owner might want to treat them as a single cluster with a shared sub-cap. Otherwise, the agent could accidentally concentrate risk by choosing five similar assets that all move together. The same logic applies to crypto pairs that track the same underlying macro factor. Sizing by market type is necessary, but sizing by correlation cluster is often what actually protects the owner from concentrated drawdowns.

What happens when open positions change in value?

Position sizing is often treated as a one-time decision at entry, but the notional size of an open position changes as the market moves. Imagine a one thousand dollar position that grows to one thousand five hundred dollars. It is now consuming more of the budget cap than planned. The owner must decide whether the agent should rebalance, trim, or ignore this drift. One approach is to define a notional ceiling: if the position value exceeds its original size by a fixed percentage, the agent must reduce it back to the target before opening new trades. Another approach is to let winners run but block new entries until the total deployed capital falls back under the cap. Either way, the rule should be mechanical and pre-defined, not left to the agent's discretion. Failing to account for drift can lead to a situation where the agent is fully deployed but the owner believes half the budget is still free. The owner should also account for the direction of drift. A losing position that shrinks frees up budget, but the owner may not want the agent to recycle that freed capital into new trades immediately. Doing so can turn a controlled five-position portfolio into a churning sequence of seven or eight trades in the same session, each with its own fees and slippage. A cooldown rule or a minimum cash buffer can prevent this recycling behavior.

How do exit plans and sizing interact?

Every position size should be paired with a plan for how it leaves the market. The size of a trade determines the impact of its exit, and the exit plan determines whether the size is allowed to grow or shrink before departure. For instance, a take-profit rule that scales out in thirds implies the initial size must be divisible into three clean slices. A stop-loss rule that flattens the entire position implies the size must be small enough that a sudden exit does not move the market against the agent. The owner should configure exit plans and take-profit automation before the agent enters, because adjusting size after entry usually means adding to a losing position or chasing volatility. The sizing logic and the exit logic should be written as one system, not two separate prompts. The owner should also consider the sequencing of exits. If the agent holds multiple positions and the exit plan triggers on a portfolio-wide drawdown, the order in which positions are closed matters. Large positions should not all exit into the same thin order book at the same time. Staggering exits by size or by market can reduce the footprint of the departure. The sizing decision at entry therefore includes a rough estimate of how easily that size can be unwound under stress. Finally, the owner should document the sizing plan in a form that is readable by both humans and the agent. Ambiguity in a prompt is a common source of oversize trades. Writing the rule as a simple table (market type, max per trade, max concurrent, max per side) and including it in the system prompt reduces the chance of drift. The agent should cite the relevant rule before it submits each order, creating an audit trail that the owner can review.

Why should sizing rules be tested in paper trading before going live?

Paper trading lets the owner observe how the agent respects dollar limits across different market conditions without risking real money. The owner should look for three specific behaviors during the paper phase: whether the agent correctly sizes down when the remaining budget is small, whether it refuses to open a position that would breach the per-market envelope, and whether it handles the notional drift of open positions without manual intervention. If the agent finds ways to circumvent the sizing logic through creative reasoning, the owner can tighten the API-level scopes before authorizing a live key. This step is essential in the MCP safety model and should be completed before taking an agent live. Once the paper tests show consistent compliance, the owner can promote the same parameters to a live key with confidence that the infrastructure, not the agent's temper, controls the size. The owner should run paper tests across multiple market types if the agent is multi-market, because a sizing rule that works for stocks may fail for options or prediction markets where minimum ticks and margin rules differ. The paper environment mirrors the live normalization of dollar sizes, so the behavior observed there is representative of what will happen when real money is at stake.

Frequently asked questions

Can the agent override its position size if it detects a high-confidence opportunity?

No. The size limits are enforced at the API and wallet level. The agent can request a trade, but if the dollar amount exceeds the scoped cap, the request is rejected before it reaches the venue.

Does leverage change the dollar size the agent can use?

The owner should size in notional dollars at risk, not in margin posted. A five hundred dollar position is a five hundred dollar position regardless of leverage. The API normalizes this so the owner does not need to compute venue-specific margin math.

What if the agent holds multiple positions in the same market?

The per-market envelope aggregates all positions in that market type. If the stock envelope is two thousand dollars and the agent already holds two positions of one thousand dollars each, it cannot open a third stock position until one closes or drops in value.

Should the owner update size limits during a drawdown?

The owner can update limits at any time, but the change should be deliberate. Lowering the cap in response to losses is a valid risk control, while raising the cap to recover losses is dangerous and breaks the original plan.

How does the kill switch affect open position sizes?

The kill switch flattens all open positions and revokes the agent's ability to trade. It does not resize positions; it removes them entirely, returning the portfolio to cash or wallet balance according to the exit plan.

Is there a minimum position size the agent can use?

The practical minimum is set by the venue's minimum order value, not by Felix. The agent should check that its intended dollar size meets the venue floor before submitting, though the API will reject sub-minimum orders automatically.

Give your agent a key.

One key to trade stocks, crypto, perps, options, and prediction markets. Live after owner authorization.

Keep reading

Not a brokerage, exchange, or investment adviser. Not investment advice. Trading involves risk, including total loss.