How to run your first trading agent from an AI code editor in 2026

In 2026, running a trading agent from an AI code editor requires only an MCP connection, a scoped API key, and a set of safety limits you define before the first order. You do not need to rent a server, write a custom trading engine, or give custody of your funds to any third party. The agent operates inside your editor, reads market data through the API, and submits dollar-sized orders while your wallet retains sole control of withdrawals. This guide assumes you are starting from zero and want a clear, cautious path to your first live trade.

What do you need before you start?

An AI code editor with MCP support is your control panel. Cursor, Claude, and other MCP clients can discover trading tools and expose them to the agent as plain functions. You will need a Felix API key generated from your dashboard, and a wallet that you control. The funds stay in that wallet. The agent receives scoped permission to trade, but it cannot withdraw funds or send them to an unapproved address. This is non-custodial by construction, not by policy. Even if the agent is compromised or the model hallucinates an instruction, the key permissions prevent it from moving the base capital out of your wallet. You remain the only party who can withdraw.

Before writing any prompt, decide on your budget, the markets you want to access, and the maximum loss you are willing to accept in a single day. One key and one API give you access to stocks, crypto, perps, options, and prediction markets. You do not need separate accounts at a stock broker, a crypto venue, and a prediction market. The API normalizes the differences, so your agent reasons in dollars rather than contract sizes, tick values, or margin requirements. This abstraction matters because it prevents the model from making arithmetic errors when converting between notional value and contract units. You still bear the risk of market moves, but you remove the risk of order-size bugs.

How does the editor connect to markets?

The connection happens through MCP tools. The editor lists available functions such as reading a balance, fetching a price, or placing an order. The agent composes these into a plan, and you can review the plan before it executes. The API translates the plain dollar amount into the correct order size for the underlying venue, whether that is a perps venue, an options venue, or a stock broker. You do not need to maintain code for each market type. The agent simply says, buy one hundred dollars of this market, and the infrastructure handles the rest. This keeps your local codebase small and your reasoning focused on strategy rather than integration details.

The exact request schema is in the docs. The shape looks like this. An MCP tool call passes a plain JSON payload that names the market, the side, and the dollar notional. The API key authenticates the request, and the scoped permissions determine whether the agent is allowed to proceed. If the order violates a budget cap or position limit, the API rejects it before it reaches the market.

{
  "tool": "place_order",
  "parameters": {
    "market": "example-market",
    "side": "buy",
    "dollar_notional": 100,
    "api_key": "YOUR_KEY"
  }
}

Which safety limits should you set first?

Beginners should treat the first week as a safety configuration exercise, not a profit-seeking exercise. Set these constraints in order before the agent places its first order.

• ·Scope the API key to specific markets and order types so the agent cannot access instruments you have not reviewed.
• ·Add a budget cap that the API enforces as a hard ceiling on daily or total spending.
• ·Add a position limit that prevents oversized concentration in a single market.
• ·Configure an exit plan, such as a stop or a time-based close, so the agent does not hold losing positions indefinitely.
• ·Add a panic switch that flattens all positions and revokes the key instantly.

How does risk management work for a first-time trading agent covers the full setup in detail. These limits are not suggestions. They are hard constraints enforced by the API, so the agent cannot override them by prompting or reasoning its way around them.

Because the system is non-custodial, the agent can spend within the limits you set, but it can never withdraw to itself or steal funds. Withdrawal addresses are owner-approved only. This removes the risk of an agent running away with the balance, though it does not remove market risk. You can still lose money, including everything, if the market moves against your positions and your limits are too loose. The scoped key is a contract that says the agent may trade within these boundaries and nothing else. How scoped API keys let an agent trade without taking custody of your funds explains the architecture.

Common mistakes include setting the budget cap too high relative to your total capital, forgetting to test the kill switch, and allowing the agent to trade multiple correlated markets without realizing the combined exposure. Another frequent error is neglecting to define forbidden actions in the prompt, such as doubling down after a loss or trading outside specified hours. How to avoid common mistakes when running a trading agent from an AI code editor lists the errors we see most often. Write these constraints into your prompt and into the API scopes so they are enforced in two independent layers.

How should you test the agent before live trading?

Paper trading exists for exactly this purpose. You can run the agent against live market data with simulated orders and no capital at risk. Use this phase to verify that the agent interprets your prompts correctly, that it respects the dollar-based sizing, and that the kill switch works as expected. Watch for cases where the agent might misread a prompt and plan an order that is larger or more aggressive than you intended. Paper trading reveals model behavior that static code review cannot catch, because the agent is reacting to live prices and its own prior actions.

During paper trading, test the full lifecycle: opening a position, adding to it, reducing it, and closing it entirely. Trigger the panic switch manually at least once to confirm that it flattens positions and revokes access immediately. Only after the agent behaves predictably in simulation should you consider authorizing a live key. Keep the paper trading environment identical to the live environment in terms of prompts and limits. If you relax constraints when moving to live trading, you introduce variables that were never tested. How to take an AI trading agent live in 2026 describes the authorization step and the exact differences between paper and live modes.

What should you watch after going live?

Live trading requires explicit owner authorization of a key. Once authorized, the agent can place real orders, so monitoring shifts from functionality to risk. Watch the budget burn rate relative to the time elapsed. If the agent consumes twenty percent of its daily cap in the first hour, you may need tighter limits or a clearer prompt. Track open exposure across all market types, because a position in a perps venue and a position in an options venue can compound risk even if they are in different asset classes. The dollar-based abstraction helps with sizing, but it does not prevent you from holding too much correlated risk.

Keep the kill switch within reach. Do not bury it behind multiple menus or rely on the agent to stop itself. The best practice is to have a single action that flattens all positions and disables the key. Review the agent's activity regularly, not just its profit and loss. Look for repeated errors, rejected orders, or unusual market selections that suggest the model is misinterpreting your strategy. How beginners can manage multi-market portfolio risk with an AI agent offers a framework for tracking exposure when you trade across stocks, crypto, and derivatives simultaneously.

What is the realistic path from idea to live agent?

Suppose you start on a Monday. You spend the first day defining your strategy in plain language and writing a prompt that includes the budget, allowed markets, and forbidden actions. Be specific about what the agent should not do. For example, tell it not to increase position size after a losing trade, not to trade outside your specified hours, and not to touch markets you have not explicitly approved. Tuesday, you generate a scoped API key, connect the editor through MCP, and run paper trades. Wednesday and Thursday, you refine the prompt based on paper trading behavior, test the kill switch, and adjust your position limits. On Friday, you review the logs, authorize the live key with a small budget, and let the agent run with close supervision.

Over the following weeks, you gradually increase the budget only if the agent remains inside its limits and the strategy performs as expected in varying market conditions. If the agent ever breaches a limit or behaves unexpectedly, revoke the key, fix the prompt, and return to paper trading. There is no deadline to scale. The goal is to build a system that loses slowly enough for you to notice and stop it, not to maximize returns on day one. Remember that trading can lose money, including everything, and no configuration of safety limits can change the underlying volatility of the markets. The limits protect you from the agent, not from the market.

Frequently asked questions