How position sizing protects owner funds from agent error

Position sizing is the first line of defense when an AI agent trades real money. Felix enforces position limits as hard constraints that the agent cannot override, not as recommendations it might ignore. Every order is capped in plain US dollars, so the owner defines the maximum exposure and the agent cannot exceed it even if its strategy or reasoning changes. This turns a traditional portfolio management question into a structural safety mechanism that sits between the agent's intent and the market.

Why is position size a safety control rather than just a strategy choice?

In manual trading, position sizing is usually treated as part of strategy. A trader decides how much capital to put at risk based on conviction, volatility, or portfolio balance. The trader might scale into a position, add on strength, or trim on weakness. When an AI agent makes the decisions, that same sizing question becomes a safety boundary. The agent may misread a signal, misinterpret a prompt, hallucinate a price level, or encounter a market state that its training did not cover. If the size limit is soft, if it lives inside the prompt or inside the agent's own logic, the agent can turn a small reasoning error into a large financial loss.

Felix treats the owner's dollar cap as a permission, not a parameter. The agent can request any trade it wants, but the API checks the requested notional against the owner's limit before the order reaches any venue. If the request exceeds the cap, the API rejects it and returns a clear error. This happens regardless of the agent's reasoning. Even if the agent describes the trade as high conviction or urgent, the limit holds. The owner does not need to trust the agent's judgment about how much to risk. The owner only needs to trust the system to enforce the number they chose. Trading can lose money, including everything, and position sizing exists to make sure that any single mistake is bounded by the owner's explicit choice. It does not make trading safe, but it makes the worst case smaller than it would otherwise be.

How does dollar-normalized sizing remove venue complexity?

Different market types express size in different units. A perps venue uses notional value and leverage. An options venue counts contracts with multipliers. A stock broker deals in whole shares. A crypto spot market uses base asset units. When an agent has to compute these conversions itself, it introduces a class of errors that have nothing to do with strategy. It might misplace a decimal, forget a multiplier, confuse notional with margin, or fail to account for minimum lot sizes. These are mechanical errors, but they can have the same financial consequence as a bad prediction.

Felix normalizes order sizing into plain US dollars. The owner sets a cap such as five hundred dollars per order. The agent sends a request in dollars. The API translates that figure into the correct venue-specific quantity, whether that means contracts, shares, or base units. This removes unit arithmetic from the agent's reasoning loop. The agent does not need to know the contract specification of a perps venue or the share lot rules of a stock broker. It asks to spend a dollar amount, and the system enforces that the resulting order matches the owner's intent. The API also handles rounding, minimum increments, and notional checks so that the agent cannot accidentally submit an order that is technically valid on the venue but financially larger than the owner intended. This abstraction is especially important when an agent trades across multiple market types from a single strategy. The agent can think in dollars, and the owner can think in dollars, while the infrastructure handles the rest.

What happens when an agent reaches its size limit?

When an agent requests a trade that would breach its cap, the API returns a rejection. The agent receives an error message indicating that the limit blocked the order. It may retry with a smaller size, move to a different opportunity, or log the failure and wait. It cannot escalate the request to a higher authority, because no such authority exists inside the system. The limit is structural, not administrative. There is no override code the agent can guess, and no backdoor prompt that convinces the system to make an exception.

There are two common scopes for this protection. A per-order cap limits the notional value of any individual entry. A total-position cap limits the sum of notional exposure across all open orders and positions in a specific market or market type. If an agent already holds a position near the total cap, it cannot add more. The owner can also set a daily or weekly budget cap that acts as a broader ceiling. These limits do not protect against adverse market movement after a position is open. Once a trade is accepted, the market can still move, and the position can still lose value. Position sizing only controls how much the agent is allowed to put at risk in the first place. It is a gate, not a guarantee.

How does position sizing interact with other safety controls?

Position sizing is one layer in a stack. It works alongside budget caps, drawdown limits, exit plans, and the panic switch. The custody model ensures that the agent can never withdraw funds to an external address. Position sizing ensures that the agent cannot overcommit those funds to a single trade. Together, they address two different risks: theft of capital and concentration of capital. The custody model protects the wallet. The sizing model protects the trades.

Every order, whether accepted or rejected, appears in the audit trail. Audit logs and observability let the owner see patterns over time. If an agent is repeatedly hitting its size limit, that may signal a strategy that is too aggressive for the allocated capital, or worse, a loop where the agent keeps trying the same trade because it does not understand why it failed. The owner can spot this in the logs and tighten the constraint or pause the agent. Common position sizing mistakes often involve setting one global cap without considering per-venue or per-strategy needs. Felix supports scoped keys, so an owner can give one agent a fifty dollar cap for options and a different agent a two hundred dollar cap for stocks, all from the same wallet. This granularity matters because volatility and liquidity differ across market types. A dollar in an options position is not the same risk as a dollar in a spot crypto position. Scoped sizing lets the owner match the limit to the environment.

How can owners adjust limits without stopping the agent?

Limits are live. An owner can raise or lower a cap without revoking the agent's key or restarting its process. The change propagates through the API and applies to the next order the agent attempts. This makes position sizing a practical tool for gradual trust. An owner can start with paper trading, then authorize a live key with a ten dollar per-order cap, observe behavior over days or weeks, and raise the limit only after the agent demonstrates consistent adherence to its strategy. There is no need to commit to a large allocation on day one.

This approach turns the safety model into a conversation between owner and agent. The owner sets the boundary. The agent operates within it. If the agent consistently operates near the boundary and the owner is comfortable, the boundary moves outward. If the agent behaves erratically, the boundary moves inward. The agent does not need to be reprogrammed. The owner does not need to change prompts or reconfigure venue accounts. The adjustment happens in one place, through the Felix API or dashboard, and it takes effect immediately. This dynamic is critical for autonomous systems that run for long periods. A static configuration might be appropriate on day one and wrong on day thirty. Live limits let the owner adapt without breaking the agent's workflow.