How to trade options with an AI agent: a developer checklist

Options trading with an AI agent is possible through a single API that normalizes contract math into plain dollar amounts, but it requires explicit safeguards because options can expire worthless and multi-leg structures amplify complexity. A developer should treat the agent as a scoped execution layer, not a source of judgment, and enforce hard limits before any live capital is deployed. Trading can lose money, including the entire premium and more in short or complex positions, so every step below should be completed in paper trading first. The following checklist covers the practical steps to connect, constrain, and test an options trading agent without surrendering custody of funds.

What makes options different for an AI agent?

Options are not linear instruments. A stock or crypto spot position moves one for one with the underlying, but an option's value depends on time remaining, implied volatility, and the greeks that measure sensitivity to those inputs. An AI agent does not intuit these dynamics. It processes text and executes commands, so it can easily open a position that seems logical under one set of assumptions but bleeds value as theta decays or vega shifts. Multi-leg structures such as spreads, straddles, or iron condors add coordination risk. If the agent places one leg and fails to place the other due to a price change or a venue-side rejection, the intended risk profile collapses into an exposed directional bet. Developers must therefore encode the specifics of strategy, maximum acceptable premium, and time horizon directly into the agent's instructions rather than letting the model infer them from market context.

Another distinction is expiration. A spot position can be held indefinitely, but an option has a fixed maturity. If the agent does not have a clear rule for closing or rolling before expiration, the position can convert into an unwanted assignment, a cash settlement, or a total loss of premium. The API expresses order sizes in plain US dollars, which removes manual contract multiplier math, but it does not remove the obligation to manage time decay. The developer remains responsible for teaching the agent when to exit based on days to expiration, profit targets, or stop criteria.

How do you scope the agent's keys and budgets?

Non-custodial design means the agent can spend within limits but can never move funds to an address you have not pre-approved. Before the agent touches an options market, create a scoped key with a hard budget cap that represents the maximum capital the agent can deploy at any moment. This is not a suggestion; it is a ceiling enforced by the infrastructure. You should also set a position limit on the number of contracts or the maximum dollar premium per trade, so a misinterpreted prompt cannot allocate the entire budget into a single far out-of-the-money contract. If you run multiple agents or strategies, use separate scoped keys for each so a failure in one does not compromise the others.

Withdrawal addresses should be locked to wallets you control. The agent can trade, but it cannot withdraw to itself or to any new address. This is a structural guarantee, not a policy setting. If you are unsure how to set these boundaries, the guide on how to start an AI trading agent with hard limits walks through the setup, including budget caps and position limits.

How do you design prompts for options strategies?

A trading prompt is not a conversation. It is a specification. For options, the prompt must state the allowed strategy types in plain language and ban any structure not explicitly listed. Open-ended instructions like find a good options trade invite the model to hallucinate criteria. Instead, encode the selection rules directly.

• ·Allowed strategy types, such as single leg calls, cash-secured puts, or defined-risk vertical spreads.
• ·Maximum premium or minimum credit per trade, expressed in plain US dollars.
• ·Acceptable expiration range, for example twenty-one to sixty days.
• ·Greek thresholds if you use them, such as delta between zero point two and zero point four.
• ·Exit rules for profit, loss, and time decay, including behavior around wide bid-ask spreads.

If the agent is allowed to sell premium, the prompt must define the maximum margin requirement and require that the agent check buying power before entry. For detailed guidance on writing these constraints, refer to how to design prompts for a trading agent.

How should position sizing and expiration work?

The API normalizes venue-specific contract math into plain US dollars, which simplifies the agent's job. You can tell the agent to risk two hundred dollars on a trade, and the system translates that into the appropriate number of contracts at the current price. This is helpful, but it does not eliminate the need for human-defined sizing rules. Decide in advance what percentage of the total agent budget can go into a single trade, a single underlying, and a single expiration cycle. Concentration in one expiration date creates calendar risk; a volatility event that day can wipe out multiple positions at once.

Expiration management requires a clear policy. Many developers allow the agent to open positions with thirty to sixty days to expiration and require closure or rolling by twenty-one days. This avoids the gamma risk and assignment risk that accelerate in the final week. If your strategy intentionally trades weeklies or zero-day options, that is a valid approach, but you must state it explicitly in the prompt and accept that the time decay curve is steep and losses can be total. Never let the agent hold short options into expiration without a rule for assignment handling, because an unexpected assignment can convert an options account into a stock or perp position that exceeds the original budget.

How do you build a kill switch and exit plan?

Every options trading agent needs a panic button that flattens open positions and revokes the scoped key. This is not a graceful shutdown; it is an emergency brake. The kill switch should be hosted outside the agent's own logic, on infrastructure the agent cannot modify, because a compromised or confused agent could otherwise disable its own off switch. When triggered, it should cancel all open orders, submit market orders to close any open long options, and if the venue permits, submit buy-to-close orders for short options. For complex multi-leg positions, the switch may need to flatten the entire structure rather than individual legs to avoid leaving a naked directional exposure.

Short options carry assignment risk that long options do not. If the agent sells a call and the underlying price rises above the strike, the counterparty may exercise early, especially before a dividend. The agent must have a rule for this scenario, either maintaining enough buying power to take delivery or closing the short before the ex-dividend date. Without this rule, a single assignment can convert a limited-risk options account into a leveraged spot position that violates the original budget cap.

An exit plan is the calmer counterpart to the kill switch. It is the set of rules that governs normal closures. Define whether the agent should take profit at fifty percent of maximum profit, cut losses at two hundred percent of premium for debit spreads, or roll the untested side of a strangle when the underlying moves. The exit plan should also specify behavior around earnings events, dividend dates, or macro announcements, because implied volatility can collapse or spike around these catalysts. You can read more about constructing an irreversible stop mechanism in how to build a kill switch your trading agent cannot override.

How do you test and connect the agent safely?

Before live capital is deployed, run the agent in paper trading mode for a full expiration cycle. This means opening positions, watching how the agent handles theta decay, testing the exit logic, and triggering the kill switch under simulated conditions. Paper trading on Felix uses the same API shape as live trading, so the transition from test to production is a matter of key authorization, not code rewriting. Live trading requires an explicit owner authorization step for the scoped key. Until you complete that step, the key cannot place orders that touch real money.

Developers can connect agents through MCP tools or the REST API. The exact request schema is in the docs; the shape looks like this. You will need to include the market type, the underlying symbol, the dollar amount, and any constraints that mirror the prompt rules.

# Exact paths and fields are defined in the docs
curl -X POST https://api.felix.trade/... \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "market_type": "options",
    "symbol": "UNDERLYING",
    "direction": "long",
    "dollar_amount": 500,
    "max_days_to_expiration": 45
  }'

If you connect through MCP, the agent receives tool definitions that describe available actions such as checking buying power, placing an order, or querying open positions. You should scope these tools so the agent cannot request unauthorized data or place order types you have not approved. The MCP layer does not replace the API-level budget caps; it adds a second layer of intent validation. This dual-layer approach means the agent's own reasoning must pass through both its prompt constraints and the infrastructure's hard limits before any options contract is traded. If you are connecting through MCP, the practical checklist for non-custodial MCP trading covers environment setup, tool scoping, and session isolation in more detail.