How to paper trade an AI agent with hard limits it cannot cross

Paper trading with an AI agent only prepares you for live markets if the hard limits enforced in simulation are identical to the constraints you will use with real money. A useful paper environment lets the agent place, manage, and exit orders across stocks, crypto, perps, options, and prediction markets while physically preventing it from exceeding budget caps, position sizes, or drawdown thresholds you set. When the limits are real and uncrossable, paper trading becomes a test of the agent's decision making under the same restrictions it will face later, not a fantasy of unrestricted capital.

Why do soft limits fail during paper trading?

If the paper environment allows the agent to breach a budget with a warning instead of a hard stop, the test is meaningless. Agents do not learn caution from suggestions; they learn from blocked actions. A soft limit that logs an overage but fills the order anyway teaches the agent that constraints are optional. When the same strategy later meets a live market with real settlement, the behavior collapses. The goal of paper trading is to validate that the agent operates within boundaries, not to optimize returns in a boundary free sandbox.

Hard limits mean the API returns an error when the agent tries to spend beyond its cap, open a position larger than allowed, or submit an order that would violate a scoped key. The agent must then handle that error, retry with a smaller size, or stop. This error handling loop is part of what you are testing. If you skip it in paper mode, you are not testing the system; you are only testing a signal generator. The agent should experience the same friction it will face when real capital is at risk, because the infrastructure enforces the same denial regardless of whether the underlying settlement is paper or live.

How should you configure a paper trading budget that the agent cannot exceed?

Start by treating the paper budget as a real wallet with a fixed amount of US dollars. The Felix API normalizes order sizing in plain dollars, so you can set a global budget cap in the same unit across all five market types. How an AI agent trades within a hard budget it cannot exceed. The key that the agent uses should be scoped to paper trading only, with a maximum spend limit attached to that key at the infrastructure level. Even if the agent's reasoning loop requests a ten thousand dollar position, the key blocks it if the remaining budget is lower.

You should also set sub limits. Break the global cap into daily or per strategy budgets. If the agent runs multiple models, each model should receive its own scoped key with its own cap. This prevents a single buggy strategy from consuming the entire paper allocation. When one model hits its ceiling, the others continue. This mirrors the way you would likely allocate live capital, so the paper test remains structurally honest.

Include a drawdown limit inside the paper environment. How to set spend caps and drawdown limits for trading agents. If the paper portfolio loses a defined percentage of its starting value, the key should freeze new orders and require owner intervention. In live trading, this protects the remaining balance. In paper trading, it tests whether the agent recognizes that its mandate has been suspended and stops sending signals. If the agent continues to fire orders into a frozen account, you have discovered a failure mode that must be fixed before any real money is deployed.

Which safety controls must mirror live trading during paper runs?

Every control that will exist in production should exist in paper mode. This includes position limits per instrument, maximum order sizes, allowed market types, and time based restrictions. If the live agent will only trade crypto and perps, the paper key should not grant access to options or prediction markets. If the live agent will cap single positions at five percent of the portfolio, the paper key should enforce the same five percent ceiling. The mapping between paper and live should be one to one, so that behavior observed in simulation transfers directly to production.

The panic or kill switch must also be wired into paper trading. How to set guardrails for a trading agent. You should test flattening all positions and revoking the key mid session. In paper mode, this costs nothing, but it verifies that the mechanism works and that the agent handles the resulting state gracefully. A live panic event is the wrong time to discover that the agent loops errors when its key is revoked. You should also test partial revocations, such as disabling a single market type while leaving others active, to see if the agent adapts or crashes.

Exit plans and take profit automation should be active in paper trading too. If you intend to automate exits in live trading, the agent should practice them now. This reveals whether the agent's reasoning conflicts with the automated exit rules. Suppose the agent tries to add to a position that the exit plan is trying to close. Catching that conflict in paper mode prevents a live fight between the agent and its own safety layer. The controls are not decorations; they are load bearing parts of the system, and paper trading is where you verify that they bear load without breaking.

What does a paper key with hard limits look like in practice?

The exact request schema is in the docs; the shape looks like this. You would send a configuration object that defines the key type as paper, the allowed markets, the budget cap, position limits, and drawdown thresholds. The infrastructure reads these fields and enforces them before any order reaches a venue.

{
  "key_type": "paper",
  "scope": ["read", "trade"],
  "markets": ["stocks", "crypto", "perps"],
  "budget_cap_usd": 5000,
  "max_position_usd": 250,
  "daily_spend_limit_usd": 1000,
  "drawdown_limit_percent": 10,
  "allow_withdrawal": false
}

After creation, the agent receives the key and connects through MCP tools or the REST API. Every order it submits is checked against these values. If an order would exceed the daily spend limit, the API rejects it with a clear error. The agent must parse that error and decide what to do next. The paper key cannot be upgraded to live by the agent; owner authorization is required to create a live key with a separate process. This separation is intentional. It ensures that the agent never confuses simulation with real settlement, and it forces a human review of the limit configuration before capital is exposed.

How do you evaluate paper results before authorizing live keys?

Look first for limit breaches. In a properly configured paper run, there should be zero. Any breach means the hard limits are not configured correctly or the agent is finding a path around them through sequencing or timing. Both are critical failures. A paper test with breached limits is a failed test regardless of the simulated profit or loss. Breaches include any order that exceeds a cap, any position that violates a size limit, or any drawdown that passes the threshold without triggering a freeze.

Second, review the agent's behavior near boundaries. Did it reduce order size automatically when the budget ran low? Did it stop sending orders when the drawdown limit approached? Did it respect the scoped key restrictions without owner prompts? The logs should show the agent adapting to constraints, not ignoring them. A practical checklist for running autonomous trading systems with real money. If the agent repeatedly hits walls and retries the same oversized order, its reasoning logic is not ready for live trading.

Third, measure the mechanics of order execution. Paper trading normalizes venue specific contract math, so check that the dollar sizing the agent requested matches the simulated fills. Verify that cross market positions sum correctly against the global budget. If the agent trades options and stocks in the same portfolio, ensure the option premiums or notional values are counted toward the cap in the way you expect. Discrepancies here mean your live budget math will also be wrong.

Fourth, confirm that the agent does not attempt to withdraw funds or change configuration. In live trading, withdrawal addresses are owner approved only and the agent cannot alter its own limits. Paper trading should enforce the same restrictions. The agent should never attempt to modify key scopes, raise budgets, or redirect settlement. Any such attempt in logs is a red flag. The agent should treat its environment as immutable except for the trading decisions it is authorized to make.

When should you move the agent to live trading and what changes?

Move to live trading only after the agent has operated within hard paper limits for a statistically meaningful period. There is no fixed number of trades or days that guarantees readiness, but the sample should include multiple market conditions, boundary interactions, and at least one full test of the panic switch. The owner must then explicitly authorize a live key. This is a manual gate that the agent cannot trigger. The authorization step exists because paper trading tests the agent, but live trading exposes the owner to real financial risk, including the risk of losing the entire allocated amount.

The live key should start with the same or stricter limits than the paper key. It is common to maintain a lower live budget initially, effectively paper trading with real money at reduced scale. The controls do not change; only the settlement layer does. The agent should not detect any difference in API behavior, because the constraints are enforced at the infrastructure level for both keys. This continuity is what makes the paper results trustworthy. If the live environment were looser, the paper test would be invalidated.

Keep the paper environment running in parallel. Use it to test strategy updates before deploying them to the live key. A paper key that mirrors the live key's constraints becomes a permanent staging area. When you want to change a limit, test the new value on paper first. If the agent behaves correctly, apply the same configuration to the live key. Over time, this creates a disciplined release pipeline where the agent proves itself in simulation before every production change. Trading can lose money, including everything, so maintaining this discipline is not over caution. It is the minimum standard for autonomous systems that handle real capital.