How to build an options trading agent: a practical checklist

Options trading with an AI agent requires explicit handling of expiration, leverage, and assignment risk that does not exist in spot markets. A practical checklist starts with defining the agent's strategy, enforcing strict spending and position limits, and testing every control in paper trading before any live capital is deployed. The agent must trade through a non-custodial interface so it can execute orders but cannot withdraw funds or expand its own authority. If any of these foundations are missing, the agent should not be authorized for live options trading.

What makes options different for an AI agent?

Options contracts introduce asymmetric payoff profiles, fixed expiration dates, and sensitivity to variables beyond price direction. An agent trading stocks or crypto spot only needs to manage entry price, quantity, and perhaps a stop level. In contrast, an options agent must reason about strike distance, time to expiration, implied volatility, and the possibility of early assignment on short calls or puts. Multi-leg structures such as spreads, straddles, or iron condors add order complexity because each leg must be filled at a net price that remains profitable after fees and slippage. The agent also needs to handle expiring positions. If a contract is in the money at expiration, the owner may be assigned stock, which changes the portfolio delta and cash requirements overnight. Because of these factors, an options agent cannot treat each trade as an isolated buy or sell. It needs a persistent model of the portfolio Greeks, a calendar of expiration dates, and a rule set that prevents it from opening illiquid far-out-of-the-money positions just because the premium looks small. Paper trading is especially important here because the cost of an error, such as forgetting to roll a short option or miscalculating buying power reduction, can be larger than the initial credit received.

Time decay, or theta, means that an options position loses value as expiration approaches, all else being equal. An agent that opens a long position and holds it without a plan is effectively paying a daily rent on the trade. Short positions collect this rent but accept the risk of large losses if the underlying moves sharply. The agent must therefore include time-based rules: close long spreads before theta accelerates, or roll short positions to later expirations if the thesis has not changed. Volatility skew can also distort the agent's assumptions. Out-of-the-money puts may trade at higher implied volatility than calls, so a delta-neutral agent that sells both without checking skew can end up with lopsided risk. These subtleties mean that the agent's prompt or code must reference Greeks, not just price targets. You should also define how the agent handles corporate events. A short call position is at risk of early assignment before a dividend, which changes the portfolio composition suddenly. If the agent does not monitor ex-dividend dates, it may be surprised by assignment and the resulting stock position. These are not edge cases. They are routine features of options markets that a spot-trading agent may never encounter.

How should you model risk before the first trade?

Before writing any prompt or code, define the maximum percentage of the wallet that can be allocated to options strategies. A common starting point is to limit the agent to a small fraction of total capital, with a hard cap on the premium spent or collateral reserved per day. You should also set a per-strategy concentration limit: for example, no more than a defined amount of buying power in a single underlying or expiration cycle. This prevents the agent from overloading the account on one earnings event or volatility spike. Next, decide whether the agent is allowed to sell naked options or only defined-risk spreads. Naked short options can require large margin reserves and carry assignment risk, so many builders restrict the agent to spreads where maximum loss is known at entry. Document these limits in the agent's instructions and also in the API layer as budget caps and position limits. The wallet owner should review this risk document before authorizing the live key. Remember that options can expire worthless, and short options can be exercised against you. Trading can lose money, including the entire allocated amount, so the capital assigned to the agent should be money you can afford to lose.

Scenario analysis should precede automation. Ask what happens if the underlying gaps down ten percent overnight while the agent holds short puts. Ask what happens if implied volatility doubles after the agent sells a large straddle. The answers determine whether the agent needs portfolio-level hedges, such as long index puts or volatility calls, or whether it should simply reduce position size. You should also define the maximum number of open expirations the agent can manage simultaneously. Tracking many different expiration dates increases operational risk and the chance that one is forgotten. A simpler rule, such as only trading the next two monthly expirations or a set number of weekly cycles, keeps the portfolio manageable. Finally, separate the agent's trading capital from funds reserved for assignment. If the agent sells cash-secured puts, the cash must actually be secured and not double-allocated to another strategy. If it sells naked calls, you must reserve the buying power for a potential margin call. Failure to partition capital this way leads to forced liquidations when multiple positions move against the account at once.

Which controls keep an agent within safe bounds?

An agent with unrestricted access to an options account can quickly violate margin rules or accumulate unintended directional exposure. You should build a layered control system. At the infrastructure level, use scoped API keys that only permit options trading on the intended account and cannot access withdrawal or account settings. Budget caps enforce a maximum daily or weekly premium spend, while position limits block the agent from holding more than a set number of contracts per underlying or across the entire portfolio. An exit plan, or kill switch, should automatically flatten open positions and revoke the key if the account value drops by a predefined percentage or if the owner sends a panic command. How to build guardrails for a trading agent covers these mechanisms in detail. Because Felix is non-custodial by construction, the agent operates from a wallet you control, and withdrawal addresses are owner-approved only. Non-custodial trading for AI agents explains why this matters: even if the agent's logic is compromised, it cannot route funds to itself. These controls are not optional extras. They are the baseline required to automate instruments with convex payouts.

Beyond technical limits, consider semantic controls. The agent should be forbidden from trading instruments it does not understand. If the prompt only describes vertical spreads, the agent should not attempt ratio spreads or unqualified naked positions. You can enforce this by restricting the allowed strategy types in the API parameters, not merely by asking the model politely. Rejection rules are also important. If the agent requests an order with a net credit below the minimum threshold or a leg width that violates the defined risk mandate, the API should reject the order and log the reason. This prevents the model from gradually bending the rules through creative interpretation. You should also set a cooldown period between trades. An agent that reacts to every price tick may overtrade, racking up commissions and slippage that erode the edge of the strategy. A minimum hold period, or a requirement that a new signal must exceed a higher confidence threshold to override an existing position, reduces churn. These controls turn a theoretically profitable strategy into a practically safe one.

How do you connect the agent to an options venue?

Felix exposes options through the same API used for stocks, perps, and prediction markets, normalizing order sizing to plain US dollars. You can connect an agent via MCP tools from Claude, Cursor, or other MCP clients, or through the REST API directly. The MCP path is often faster for prototype agents because the model can invoke trading tools as functions without you writing a full execution wrapper. Trading over MCP from Claude, Cursor, and Codex walks through the setup. When you define the tool schema, include the risk parameters as required fields: max premium, max legs, allowed strategy types, and the underlying ticker. This ensures the model cannot omit a budget cap by accident. The exact request schema is in the docs; the shape looks like this:

curl -X POST https://api.felix.trade/... \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "market": "options",
    "underlying": "EXAMPLE_TICKER",
    "strategy": "vertical_spread",
    "direction": "buy",
    "max_premium_usd": 500.00
  }'

The API abstracts away venue-specific contract multipliers and tick sizes, so the agent reasons in dollars rather than trying to compute notional values for each exchange. Whether you use MCP or REST, test the connection with a single contract paper trade to confirm that the agent parses the response correctly, especially for partially filled multi-leg orders. An options venue may reject an order if the net debit or credit moves outside the agent's limit, so the retry logic should distinguish between a fillable price change and a structural error. You should also verify that the agent handles the full order lifecycle: open, partial fill, fill, expiration, and assignment. If the agent only knows how to open trades, it is not ready for live options trading.

What should you verify before going live?

Moving from paper to live trading requires a deliberate authorization step. You should complete the following before activating a live key.

1. 01Confirm that the agent has executed at least a full expiration cycle in paper mode, including opening trades, managing any rolls or adjustments, and closing or allowing assignment at expiration.
2. 02Verify that every guardrail has been triggered intentionally during testing: hit the budget cap, hit the position limit, and trigger the kill switch to ensure each halts the agent without manual intervention on the venue.
3. 03Review the agent's logs for hallucinated symbols, incorrect legs, or misinterpreted Greeks. If the agent has made logic errors in paper mode, it will make them with real money.
4. 04Ensure the wallet owner has explicitly authorized the live key and that withdrawal addresses are locked to owner-controlled destinations. How to evaluate an autonomous trading system when you have never automated a trade provides a framework for this review.

Only after these checks should the live key be activated, and even then, the initial live allocation should be smaller than the paper testing allocation. Authorization is a deliberate act, not a default setting. In Felix, live trading requires explicit owner approval of a scoped key, and the system will not fall back to live execution if paper mode fails. Confirm that the owner understands the specific options strategies the agent is cleared to run. A mismatch between the owner's expectation and the agent's capability is a common source of catastrophic trust failure. You should also document the escalation path. If the agent breaches a limit or the kill switch fires, who decides whether to restart it, modify the strategy, or leave it halted? Writing this down before launch prevents panic-driven decisions during a fast market. The transition to live should be staged: begin with the smallest position size that still tests the full workflow, then scale gradually if the agent behaves consistently. This is not a sign of doubt; it is standard practice for any automated system that touches convex instruments.

How do you maintain the agent after launch?

Live deployment is not the end of the checklist. The agent needs continuous monitoring because options markets change character around earnings, dividends, and expiration weeks. Set up alerts for unusual Greeks shifts, such as a portfolio vega that doubles overnight because the agent added new positions. Review the agent's orders daily at first, then weekly, looking for drift in strategy or repeated errors like choosing illiquid strikes or opening positions with insufficient time to manage them. Update the agent's prompt or code when market conditions change: a volatility regime shift may require tighter spread widths, shorter durations, or a reduction in overall size. Revisit the kill switch and budget caps monthly to confirm they still match the account size and your risk tolerance. If the agent's performance degrades or its behavior becomes unpredictable, revoke the key and return to paper trading until the cause is identified. Automation does not remove the owner's responsibility for oversight; it merely changes the frequency and format of the decisions.

Market regimes change, and an agent that worked in low volatility may struggle in high volatility. Schedule periodic reviews of the agent's win rate and average profit per trade, but focus on the tail risks. A high win rate with occasional large losses is characteristic of short options strategies, and the agent may hide this pattern until a loss occurs. Review the maximum drawdown and the frequency of margin expansion requests. If the agent consistently needs more buying power than planned, it is likely taking on hidden leverage. Update the prompt or code to reflect new market realities, and retest in paper mode after each significant change. Maintenance also includes rotating API keys on a schedule and reviewing the owner-approved withdrawal addresses to confirm they have not been altered by external wallet software. Security and strategy drift are both ongoing concerns, so the checklist never truly ends. It simply becomes a routine.