A practical checklist for prediction market trading with AI agents

Letting an AI agent trade prediction markets means handing execution to a system that cannot intuit binary settlement risk. A practical checklist must cover position sizing, safety controls, backtesting assumptions, prompt boundaries, and a staged path from paper to live trading. Without these checks, an agent can exhaust its budget on contracts that expire worthless before the owner notices. The following sections walk through each item in order.

What makes prediction markets different for an AI agent?

Prediction markets are not continuous instruments. They resolve to a discrete outcome, often zero or one, which means the price represents a probability that collapses when the underlying event is settled. An AI agent that is trained or prompted on continuous market logic may misinterpret a price chart as a trend when it is actually a countdown to resolution. This confusion is dangerous because a binary contract on the wrong side can expire completely worthless. Unlike a stock that can be sold at a loss, or a perpetual future that can be held indefinitely, a prediction market contract has a terminal point.

Some prediction markets use share structures where a yes share pays one dollar if the event occurs and zero otherwise. An agent that does not understand this structure might treat the share price like a stock price and attempt to buy low and sell high without recognizing that the only exit before resolution is a sale to another participant, and the final exit is the resolution itself. This means there is no fundamental value to hold onto if the market moves against the position. The contract does not represent a company with future earnings or a commodity with storage value. It is a bet on a single event.

Time in these markets is not just another axis on a graph. It is the decay of uncertainty itself. As the resolution date approaches, prices often drift toward the correct outcome or become more volatile if new information arrives. An agent without time bounds might enter a market hours before resolution and suffer from wide spreads or sudden liquidity withdrawal. Liquidity can be concentrated near the midpoint and almost nonexistent at the extremes. Because these markets are binary, trading can lose money, including the entire amount allocated to a single position.

How should you size positions when outcomes are binary?

Position sizing in prediction markets must start from the assumption of total loss. When an agent buys a binary contract at 0.60, the upside is capped and the downside can be the full notional if the market resolves against the position. This is structurally different from a stock where the floor is rarely zero in the same timeframe, or a perp where the position can be deleveraged. The agent should therefore treat every dollar deployed as potentially lost.

Felix sizes orders in plain US dollars, which removes the need for the agent to compute share counts, contract multipliers, or decimals. This is helpful, but it does not remove the owner’s responsibility to set caps. A weekly or monthly budget cap should be enforced at the API level, not just mentioned in the prompt. Per-market caps are equally important. If an agent has a $500 budget, allocating $200 to a single binary market is an unrecoverable risk if the market resolves incorrectly. A safer default is to limit any single position to a small fraction of the total budget.

The reasoning behind this is covered in detail in our guide on position sizing for AI agents from first principles. The core idea is that an agent does not feel risk. It will not flinch when a position moves against it. Only the infrastructure limits prevent it from doubling into a losing trade. Budget caps, position limits, and scoped keys are the owner’s replacement for the agent’s missing sense of caution.

Suppose an agent is authorized to trade $20 per market with a $100 total budget. Even if it loses five times in a row, the damage is bounded. Without those limits, the same agent could deploy the entire budget on one high-conviction signal and lose everything on a single resolution. Dollar-based sizing through the API normalizes the math, but the owner must still decide how many dollars are at stake.

Which safety controls matter most before going live?

Before any capital is deployed, the owner should verify that the safety model is built into the infrastructure, not just the agent’s logic. A script-level check can fail if the model hallucinates or if the editor state resets. Felix enforces controls at the API and key level. Scoped keys restrict which market types and actions the agent can access. Budget caps enforce a hard ceiling on spend. Position limits prevent any single trade from exceeding a dollar threshold. Exit plans can be configured to close positions under defined conditions.

The most critical control is the kill switch. It must do two things: flatten all open positions and revoke API access. A pause button that merely stops new orders is not enough. If the agent holds a binary market that resolves in an hour, a pause does not solve the problem. The kill switch must close the position and disable the key. We have written about common mistakes in our article on what beginners get wrong about kill switches. The short version is that the kill switch should be treated as a circuit breaker for the infrastructure, not a polite request to the agent.

The safety model for agents also differs from traditional trading bots. Bots often run on a server with a single owner key and broad permissions. Agents connect through MCP tools or REST APIs and may be prompted by an LLM. The LLM can generate unexpected interpretations of a signal. Therefore, the safety layer must be stricter. This distinction is explained in how the safety model for trading agents differs from bots. Withdrawal addresses are owner-approved only, and the agent can never move funds to itself. Even if the agent is compromised or the model is jailbroken, the non-custodial design prevents theft.

Finally, review the audit logs before and after every trading session. The logs show which constraints were triggered, how close the agent came to its limits, and whether any errors caused retries or duplicate orders. An agent that repeatedly hits API limits is a signal that the prompt or the strategy is too aggressive. It is better to discover this in the logs while the budget is small than to discover it when the account is empty.

How do you backtest an agent on binary markets?

Backtesting a prediction market strategy is not the same as backtesting a stock or crypto strategy. In a continuous market, the backtest might assume that a position can be closed at the next available price. In a binary market, the position may be held until resolution, at which point the payout is either the full value or zero. A backtest that ignores resolution mechanics will overstate performance.

To backtest properly, the developer must simulate the binary payoff. If the agent buys at 0.40 and the strategy says hold, the backtest needs to know the resolution value. If the market resolves to 1, the profit is 0.60 per dollar. If it resolves to 0, the loss is the entire 0.40. There is no intermediate exit unless the backtest explicitly models a secondary market where the agent sells early. The backtest must also include fees, which may be charged on entry, exit, or resolution depending on the venue.

Our guide on how developers can backtest AI trading strategies covers the general framework. For prediction markets specifically, the developer should add a resolution oracle to the simulation. Suppose the agent is tested on a market that resolves in 30 days. The backtest should not assume the agent can exit at day 15 at a small loss unless the strategy explicitly includes a stop-loss rule and the simulation models available liquidity at that time.

Another common mistake is to backtest on historical data without accounting for market creation bias. Markets that are created because an event is already in the news may have prices that already reflect the consensus. An agent backtested on these markets may appear to have edge when it is simply trading on information that was already priced in. The backtest should also model the agent’s latency. If the strategy depends on reacting to news within seconds, but the agent’s inference loop takes minutes, the backtest results will be unrealistic. Paper trading is the next filter. After the backtest looks reasonable, run the agent in paper mode to observe how it handles real order books, spreads, and resolution announcements without risking capital.

What should the prompt and API constraints include?

The agent’s prompt is its instruction set, but it is not a safety mechanism. The prompt can be misinterpreted or ignored by a model update. The real safety comes from API constraints that are enforced by the infrastructure. That said, the prompt should still be precise. It should list the allowed market types, the maximum dollar amount per trade, the maximum number of open positions, and any disallowed behaviors. For example, the prompt should state that the agent is not allowed to trade within 24 hours of a known resolution, or that it cannot increase a losing position.

The exact request schema is in the docs; the shape looks like this:

{
  "api_key": "YOUR_KEY",
  "constraints": {
    "max_budget_usd": 500,
    "max_position_usd": 25,
    "allowed_market_types": ["prediction_market"],
    "kill_switch_enabled": true,
    "panic_flatten_and_revoke": true
  }
}

This example is illustrative. The actual fields and endpoints are documented at /docs. The key point is that the prompt and the API constraints must align. If the prompt says 'trade up to $20 per market' but the API constraint allows $200, the prompt is merely a suggestion. The API constraint is the law. Developers should also bind the agent to specific prediction markets or categories rather than giving it open access to every market type. Felix supports one key across stocks, crypto, perps, options, and prediction markets, but a prediction market agent should have its key scoped to only that market type.

How do you move from paper trading to live trading?

Felix provides paper trading so that agents can be tested against real market data without owner capital at risk. This is where many errors are caught. An agent that backtests well may still behave poorly when it sees live spreads, resolution delays, or news events. Paper trading should be treated as a mandatory stage, not an optional extra.

Live trading requires explicit owner authorization of the key. The owner must consciously enable the key for real money. When moving to live, start with a budget that is small enough to lose entirely without hardship. The point of the first live week is not to generate returns. It is to verify that the agent, the API constraints, and the kill switch all behave as expected under real conditions. Monitor audit logs and webhook events closely. If the agent breaches a limit or the kill switch fires, review the logs before reactivating.

Owners should also define clear criteria for promoting the agent from paper to live. This criteria should include a minimum number of paper trades, a maximum drawdown threshold during the paper period, and a manual review of every trade that hit a limit or triggered an anomaly. Do not authorize live trading simply because the agent had a profitable paper week. A short paper window may capture a lucky streak. The goal is to verify behavior, not to prove profitability. Once live, keep the budget small for at least two resolution cycles so the agent experiences both wins and losses under real conditions.

After the first live trades, compare the actual execution prices to the paper trading results. Slippage and fees may differ in ways that affect the strategy more than the backtest suggested. If the live results diverge sharply from paper, return to paper mode until the cause is identified. Do not increase the budget to recover losses. The budget should only increase after the behavior has been stable across multiple resolution cycles. Trading can lose money, including the entire budget allocated to the agent. Prediction markets amplify this risk because of binary outcomes. A single wrong position can expire worthless. The staged path from paper to live, combined with hard dollar limits, is the most practical way to discover model errors before they become expensive.