Common mistakes developers make with paper trading for AI agents

Paper trading lets developers test API integrations and agent logic without risking capital, but it rarely predicts how an AI agent will behave when real money is at stake. The most common mistakes in 2026 involve treating simulated fills as realistic, ignoring network latency, and skipping safety drills because there is no cash on the line. Developers also confuse a successful integration test with evidence of edge or profitability, which encourages overfitting before the agent has ever faced a genuine order book. When the agent is eventually authorized for live trading, these gaps translate into unexpected losses, missed hedges, or runaway positions that paper mode never revealed.

Why does paper trading diverge from live markets?

Paper trading environments are built for safety and convenience, not fidelity. They record the intent to trade and return a simulated fill, but they do not reproduce the friction of a live venue. In a typical paper setup, an order is assumed to execute at the most recent visible price, or at the mid-price between bid and ask, without walking the order book. This assumption is harmless for small integration tests and catastrophic for agents that will later size positions in the thousands of dollars.

In live markets, even a modest order can consume multiple price levels. Suppose an agent sends a market buy for a $5,000 position in a crypto perps venue with a thin order book. The first $1,000 might fill at the ask, the next $2,000 at a higher level, and the remainder at a price the agent never saw in its snapshot. Paper trading usually reports a single fill at the pre-trade mid, so the agent never learns to expect slippage or to adjust its sizing logic for depth.

Latency is another invisible variable. Paper requests travel to a simulator that returns immediately. Live orders must reach a matching engine, compete with other traffic, and confirm back through the stack. An agent that makes decisions on stale data in paper mode may appear perfectly timed because the simulator does not penalize it. In production, that same delay means the signal has already been arbitraged away or the price has moved through the intended stop.

Partial fills are also handled optimistically. A paper venue often fills an entire order or cancels it cleanly. Live venues, especially for options or prediction markets, may fill a fraction of an order and leave the rest working. An agent that assumes binary outcomes will miscalculate exposure, hedge incorrectly, or double-send orders when the first fill is smaller than expected. The agent should be built to handle residual size, but paper mode rarely forces that code path to run.

How do developers overfit to simulated fills?

Developers want evidence that their agent is intelligent, and paper trading offers a stream of frictionless wins that looks like proof. The most damaging mistake is using paper results to tune prompts, thresholds, or model parameters. When an LLM-powered agent sees only successful fills, it may infer a level of precision that does not exist. The developer then reinforces those prompts, effectively overfitting the agent to a dataset where every trade is executable at the price shown on screen.

Imagine an agent that trades prediction markets based on news sentiment. In paper mode, it reads a headline, submits an order, and receives a fill at the pre-event price because the simulator freezes time. The developer sees a high win rate and increases the position size or removes a confirmation step. In live trading, the same headline reaches thousands of participants simultaneously, and the price moves before the agent's order arrives. The agent now buys at the post-spike price and faces immediate losses that paper mode never recorded.

This mistake is compounded by iterative testing. A developer runs the agent for a week, tweaks a prompt after each loss, and declares the system ready when paper equity curves upward. That curve reflects the developer's manual intervention and a forgiving environment, not a durable strategy. What most people get wrong about LLM trading with real money covers the broader problem of conflating language fluency with trading edge, but the paper-specific trap is using a sandbox to validate a model that has never been stressed by adverse selection.

Overfitting also happens at the infrastructure layer. A developer might optimize webhook latency or retry logic against a local simulator that never rate-limits or times out. When the agent is pointed at a live venue, those retry bursts trigger API bans or duplicate orders. The paper environment taught the agent that the network is reliable, which is precisely the wrong lesson.

What safety controls are often skipped in paper mode?

Because no real money is at risk, developers frequently disable or dilute the safety controls that would be mandatory in production. They treat paper trading as a playground where rules are optional, which means the first time those rules are actually needed is under live fire. A common pattern is to treat the budget cap as a fake number, to leave the kill switch dormant, or to assume that position limits do not matter when the balance is imaginary.

• ·Budget caps set to trivially high limits or disabled entirely
• ·Kill switches that are never triggered outside of manual tests
• ·Position limits ignored because the environment carries no real loss
• ·Exit plans that are documented but never rehearsed under simulated stress
• ·Non-custodial permission boundaries that are assumed rather than verified

Felix provides scoped keys, budget caps, position limits, exit plans, and a panic switch that flattens and revokes access. These controls should be configured in paper mode exactly as they will be in live mode, and they should be tested under conditions that force them to trigger. If a kill switch is only tested by manually pressing it during a quiet afternoon, the developer has not verified that it will fire automatically when a drawdown threshold is breached. How to build guardrails for a trading agent explains the architecture, but the operational habit is what matters here.

Paper trading is also the right place to test the non-custodial boundary. In Felix, funds sit in a wallet the owner controls, the agent can spend within limits but can never withdraw to itself, and withdrawal addresses are owner-approved only. Even in paper mode, the developer should verify that the agent cannot request a withdrawal or escalate its own permissions. Treating paper as a security rehearsal, not just a strategy rehearsal, closes a gap that becomes critical when real capital is attached. A practical checklist for non-custodial AI trading offers a step-by-step guide.

Another skipped control is the exit plan. Developers test entry signals repeatedly in paper mode but rarely test how the agent behaves when it must close a position under duress. An exit plan that relies on a specific order type may fail if that order type is rejected by a venue in fast markets. Paper mode should include deliberate stress tests where the agent is forced to reduce exposure, rebalance, or shut down entirely while holding open positions.

When should an agent move from paper to live?

The transition should be treated as a deployment milestone, not as a trivial toggle. A common mistake is to authorize live trading immediately after a short winning streak in paper mode. Winning streaks in simulation are often artifacts of perfect fills and delayed data, so they are poor evidence of readiness. The correct signal is a completed integration and safety checklist, not an upward sloping paper equity curve.

Developers should require explicit owner authorization of the live key, which is a built-in step in Felix. Before that authorization, the owner should confirm that withdrawal addresses are correct, that the budget cap reflects actual risk tolerance, and that the kill switch is connected to a notification channel the owner monitors. Skipping this ceremony because paper trading felt easy is how small errors become large losses.

The first live trades should be small, mechanical, and closely monitored. The goal is not to make money on the first day; the goal is to observe how the agent behaves when fills are real, slippage exists, and emotions are present even if the agent itself has none. If the agent cannot handle a $100 live position correctly, it will not handle a $10,000 position correctly. Scaling should happen only after the live behavior matches the intended design under observed latency and partial fills.

It is also important to recognize that paper trading can persist alongside live trading. A developer can run a paper instance to test prompt changes while the live instance continues with proven logic. Mistaking paper for a one-time gate and then discarding it removes a safe sandbox for future iteration. The two environments should coexist, with a strict policy that no untested logic reaches live capital without first passing through the paper pipeline.

How should developers use paper trading without creating false confidence?

Paper trading is best understood as a tool for integration verification and guardrail rehearsal, not as a prediction market for strategy success. Developers should use it to confirm that the agent can read data, construct orders, handle errors, and respect limits across stocks, crypto, perps, options, and prediction markets through a single interface. How trading APIs let AI agents trade across markets describes the plumbing, but the discipline is to test the plumbing without claiming to test the ocean.

Developers should create explicit failure scenarios in paper mode. They should feed the agent stale data on purpose, simulate API errors, and trigger the kill switch manually to watch the flattening sequence. If the agent relies on an external signal, the developer should disconnect that signal mid-session and verify that the agent falls back to its default behavior rather than looping on a null value. These drills teach the agent resilience, whereas uninterrupted paper runs only teach optimism.

Another healthy practice is to keep a paper journal. For every simulated trade, the developer should record what the expected fill price was, what the assumed slippage would be in live markets, and what the worst-case drawdown would be if the position moved against the agent immediately. When the agent later moves to live, those estimates can be compared against reality. If the live slippage is consistently wider than the paper journal assumed, the position sizing or signal threshold needs adjustment before scaling up.

Finally, developers should resist the temptation to show paper results to collaborators or backers as evidence of readiness. A paper track record is a record of API connectivity and basic logic, not a record of trading skill. Presenting it as performance data creates organizational pressure to go live prematurely. The honest framing is that paper trading removes the excuse of technical failure, so that when live trading begins, the only remaining risk is market risk, which can lose money, including everything.