How to manage risk before your first automated trade

Risk management for an automated trading agent is not an advanced topic you defer until after the system is profitable. It is the first configuration step you complete before the agent ever connects to a market. If you have never automated a trade, you should think of risk controls as the guardrails that keep the agent inside a boundary you define, because once the agent is live, it will read data, form intent, and place orders faster than you can react manually. These controls do not require you to predict every failure mode. They exist to bound the damage from the failures you cannot predict.

What is the minimum risk setup before going live?

Before you connect a large language model to a live market, you need four non-negotiable controls. First, a spend cap that limits the total notional value the agent can deploy over a given period, such as a day or a week. Second, a position limit that caps the size of any single order or the total open exposure in one instrument. Third, a kill switch that can flatten all positions and revoke the agent's key instantly, cutting off all market access. Fourth, a paper trading environment where the agent can execute against live market data without committing real capital. These controls are not optional layers of caution or training wheels. They are the structural foundation that makes automated trading non-custodial and survivable.

Felix enforces these limits at the infrastructure level, not inside the LLM prompt. The agent receives a scoped key that can place orders and manage positions but cannot withdraw funds to an unapproved address. The owner approves withdrawal addresses ahead of time, and the agent key has no ability to alter that list or create new withdrawal paths. This means that even if the model produces a dangerous instruction, or if the underlying account is compromised at the prompt layer, the infrastructure blocks the movement of funds. The agent can spend within limits, but it can never steal.

How do spend caps and drawdown limits actually work?

Spend caps and drawdown limits are your first line of defense against compounding mistakes. A spend cap limits the total notional value the agent can place into new orders over a fixed window, such as one day or one week. It counts the intended size of orders, not just executed fills, so an agent cannot circumvent the cap by placing many limit orders and hoping some miss. A drawdown limit triggers an automatic halt when the unrealized or realized losses across the agent's activity hit a threshold you define in dollars. When the threshold is breached, the key is suspended and no new orders are accepted until you manually review and reset.

These limits are enforced below the API layer, so the agent cannot negotiate around them, ask for exceptions, or split orders to evade detection. Suppose you set a daily spend cap of five hundred dollars. If the agent attempts to enter a position that would exceed the remaining budget, the order is rejected before it reaches a market venue. The rejection is logged, and the agent receives a clear error message that it can report back to you. This is fundamentally different from asking the model to be careful. A prompt is a request that the model may interpret creatively. A spend cap is a wall.

You should set these limits conservatively for your first deployment. A common beginner mistake is to set caps that look reasonable on paper but are large relative to the test capital. If you are trading with one thousand dollars, a daily spend cap of eight hundred dollars leaves almost no room for error or for normal market fluctuation. How developers should set spend caps and drawdown limits for trading agents in 2026 covers the specific ratios that tend to work for small initial accounts, including why your first live cap should often be a single digit percentage of your total capital.

Why should you start with paper trading?

Paper trading is the practice of running the agent against live market data while executing on a simulated ledger. The prices are real, the slippage models are realistic, and the order flow behaves like production, but no capital moves and no real positions are opened at a broker or venue. Felix offers paper trading as a first-class environment because it lets you test the full loop, model reasoning, API latency, error handling, and limit enforcement, without risking money. The agent does not know it is in simulation unless you tell it, so you can observe its genuine behavior under pressure.

You should run the agent in paper mode for long enough to observe how it behaves across different market conditions. A calm market on a Tuesday morning is not a useful sample if the agent will eventually run during volatile periods or around scheduled events. Watch how it responds to rejected orders, how it sizes positions when the account balance fluctuates, and whether it respects the hard limits you configured. Only after you have verified the behavior across multiple sessions and at least one unexpected market move should you authorize a live key. Live trading requires explicit owner authorization of the key, so the transition is a deliberate step, not an accidental toggle. Many beginners skip extended paper testing because they are eager to see real results. This impatience is itself a risk.

What is the difference between a prompt rule and a hard limit?

A prompt rule is a natural language instruction you give to the LLM, such as "never risk more than two percent per trade" or "avoid concentrated positions." A hard limit is an API constraint enforced by the trading infrastructure, such as a position size ceiling that rejects any order over one hundred dollars. The difference is that the model can misinterpret, ignore, or creatively reason around a prompt rule. It may decide that a three percent position is acceptable because the setup looks strong, or it may miscalculate the percentage based on a shifting account balance. It cannot reason around a hard limit because the limit lives outside the model, in the infrastructure that processes the order.

This distinction matters because beginners often overestimate the reliability of prompt engineering. You might spend hours refining a system prompt that describes risk management in detail, only to find that the model rounds a percentage incorrectly, interprets "conservative" differently than you do, or becomes confused when the account balance changes after a loss. How to write prompts that keep trading agents inside hard limits explains how to use prompts for intent and strategy while relying on infrastructure for enforcement. The prompt should describe the logic; the hard limit should enforce the ceiling. Treat the model as a strategist, not a compliance officer.

How do you size positions when the agent thinks in dollars?

Felix normalizes order sizing into plain US dollars, which hides the complexity of venue-specific contract math. This is helpful for beginners because you can tell the agent to open a fifty dollar position without understanding lot sizes, tick values, notional multipliers, or margin requirements. The API translates your dollar instruction into the correct number of shares, contracts, or units for the specific venue. However, the convenience of dollar sizing does not remove the need for a maximum position limit at the key level.

You should configure the maximum position size in the key or account settings, not inside the prompt. If you tell the agent "trade small" but the key allows a ten thousand dollar position, the model could theoretically deploy far more capital than you intended, especially if it interprets "small" relative to a large account balance. A hard position limit of, say, one hundred dollars per order ensures that even a misinterpreted instruction cannot expose the account to an outsized trade. Common position sizing mistakes when letting an AI agent trade real money details the specific errors beginners make when they mix prompt instructions with unscoped keys, including the mistake of letting the agent infer position size from percentage prompts without a dollar ceiling.

What does a kill switch do and when should you use it?

A kill switch is an emergency control that immediately flattens all open positions and revokes the agent's access. It is not a stop loss. A stop loss is an order that closes a position at a predefined price or loss level, and it is a normal part of strategy execution. A kill switch is a manual or automated circuit breaker that says "stop everything now, regardless of price, profit, or strategy." When activated, it sends close orders for all open positions and disables the scoped key so the agent cannot place new orders.

You should use the kill switch when the agent is behaving in a way you do not understand, when market conditions are moving faster than the model can adapt, or when you simply need to step away and reassess. Beginners sometimes hesitate to use the kill switch because they worry about interrupting a "correct" strategy or locking in a temporary loss. This hesitation is dangerous. If you are unsure, you should flatten. Trading can lose money, including everything, and the kill switch exists to prevent a bad session from becoming a catastrophic one. The correct mental model is to treat the kill switch like a fire alarm, not a fine-tuned dial. What beginners get wrong about kill switches for trading agents breaks down the psychological and technical traps that delay its use, including the myth that you need to understand the problem before you halt the agent.

How do you review what the agent did after the fact?

Observability is part of risk management because you cannot improve what you do not measure, and you cannot detect drift if you are not watching. Every order, rejection, cancellation, panic flattening, and limit breach should be visible in an audit log that you can review without relying on the agent's own summary. The agent may tell you it had a successful session, but the logs will show whether it hit spend caps, received repeated rejections, or violated expected timing. The agent's narrative and the mechanical truth can diverge, especially when the model is asked to summarize its own behavior.

You should review logs after every session, even paper ones. Look for patterns such as repeated rejections, which indicate the model is not understanding the limit structure, or clusters of small orders that add up to more exposure than you expected. Look for latency spikes that might cause the agent to act on stale data, or for orders placed outside the time windows you intended. Good observability turns risk management from a one-time setup into a continuous feedback loop. Over time, this practice will teach you more about your agent's actual behavior than any prompt refinement. The logs are the ground truth; the model's explanation is merely a second opinion.