Why running a trading agent from an AI code editor changes everything

Running a trading agent from an AI code editor replaces the traditional split between strategy research and execution with a single, continuous environment. The model can see your code, read market data through MCP tools, and place orders within scoped limits without ever taking custody of your funds. This collapses the distance between an idea and a live trade, but it also means the safety controls built into the infrastructure matter more than the model's reasoning alone.

What does it mean to run a trading agent from an AI code editor?

In the usual workflow, a developer writes a strategy in a notebook or script, tests it against historical data, then deploys it to a server with stored API keys and scheduled jobs. The research environment and the execution environment are separated by version control, deployment pipelines, and often by teams. When you run a trading agent from an AI code editor, that wall disappears. The editor becomes the host for an autonomous loop that can read your comments, inspect your functions, query live prices, and submit orders through MCP tools. The model can maintain state across multiple files, understand the dependencies between your data layer and your execution layer, and adjust its plan when you change a single variable. This means the agent is not just executing pre-written rules; it is participating in the development of the strategy itself. The agent does not replace the developer. It acts as a collaborator that operates inside the same context window as the codebase. You might write a comment that says enter a long position if the RSI drops below 30 and the order book shows more bid depth than ask depth, and the agent can interpret that intent, generate the conditional logic, call the relevant MCP tools to verify the market state, and present an order for your approval. Because the Felix API normalizes venue-specific contract math into plain US dollar amounts, the agent does not need to know how a perps venue sizes contracts or how an options venue handles multipliers. It simply requests a notional value, and the infrastructure translates that into the correct native parameters. The developer remains the architect, but the agent becomes the builder, able to lay down bricks and ask for permission to pour concrete. This setup changes the cadence of work. Instead of writing code, stopping to check documentation, writing more code, and then deploying, you iterate in real time. The agent sees compilation errors, suggests fixes, and can immediately paper-trade the revised logic to see if the behavior matches your intent. The editor is not just a text file; it is a control surface for a non-custodial trading system.

Why is MCP the right protocol for agentic trading?

MCP, or Model Context Protocol, is a standard for exposing tools to AI models. Rather than hardcoding API calls into a script, you register Felix's trading functions as MCP resources that the model discovers at runtime. The model then decides when to call a price feed, when to check a balance, and when to place an order. It can choose to query a prediction market for event probability, check a perps venue for funding rates, and then size an options hedge, all within the same reasoning chain. This is fundamentally different from a traditional bot, which follows a rigid if-then loop written by a human. An agentic approach lets the model adapt its tool use to the conversation and the code context. The key advantage for trading is that MCP decouples reasoning from execution mechanics. The model does not need to memorize exchange idiosyncrasies or maintain authentication logic for every venue. Felix presents one API and one key for stocks, crypto, perps, options, and prediction markets. The MCP layer exposes these as intuitive actions: read the order book, get account summary, place order, flatten positions. Because the tools are typed and schema-bound, the model knows what inputs are valid and what outputs to expect, reducing the chance of malformed requests. The model composes these actions into a plan, and the infrastructure enforces the plan against your safety controls. Many developers misunderstand this layer. They assume MCP is just a wrapper around HTTP calls, or that it introduces unnecessary complexity. In practice, it is an abstraction that lets the agent treat trading as a native capability rather than an external integration. You can read more about the mechanics in how MCP trading tools connect AI agents to markets in 2026 and about common misconceptions in what most people get wrong about MCP trading tools through a single API. The protocol does not make the model infallible, but it does make the boundary between reasoning and action explicit, which is critical when real money is involved.

How does local context change the agent's behavior?

An AI agent running inside your editor has access to a depth of context that a remote server or a webhook listener cannot replicate. It can see the docstring you wrote three files ago, the error traceback from the last backtest, and the todo comment reminding you to add a stop-loss. This local context means the agent's decisions are grounded in the full history of your strategy development, not just the current market state. For example, suppose you are building a pairs trading strategy. You write a function to calculate the z-score of the spread, but you forget to handle the case where the denominator is zero. The agent sees the function, sees the error when you run it, and can propose a fix before you ever ask. More importantly, it can connect that fix to the trading logic. It understands that the z-score feeds into a position-sizing module, so it checks whether the sizing logic also needs a guardrail. That kind of cross-file reasoning is hard to achieve with a traditional bot that only sees the inputs you explicitly feed it. It also means the agent can maintain a running narrative of your strategy. It retains the context of why you chose a specific threshold last week, and it can warn you if a new change contradicts that original intent. The trade-off is that the agent's suggestions are only as safe as the environment allows. A model with full context might suggest increasing leverage to recover a paper-trading loss, or it might propose a logic change that inadvertently removes a risk check. Because the model is operating inside your creative workspace, it can feel collaborative rather than mechanical, and that familiarity can lead to overtrust. You must treat every suggestion as you would treat code from a junior engineer: review it, test it, and enforce hard limits that prevent any single line of code from putting your capital at risk. This is why hard limits are not optional accessories. They are the guardrails that allow you to benefit from the agent's speed without being exposed to its occasional overconfidence.

What safety controls matter when the agent lives in your editor?

Proximity to capital demands stricter controls, not looser ones. When the agent is one click away from a live market, the infrastructure must be the final authority, not the model. Felix is non-custodial by construction, which means your funds remain in a wallet you control. The agent receives a scoped key that can trade within limits but cannot withdraw to itself or to any address you have not explicitly approved. This is the first line of defense. The second line is a set of configurable hard limits. You should set a budget cap that defines the maximum notional exposure the agent can open in a single session. You should set position limits that prevent concentration beyond a threshold you define. You should configure an exit plan that flattens positions if the account drawdown reaches a level you specify. And you should configure a panic or kill switch that revokes the key and cancels open orders immediately. You should test this switch in paper mode so that muscle memory, not panic, guides your response if the market moves against you faster than the agent can react. You can learn more about configuring these boundaries in how to set hard limits that stock trading agents cannot cross. Because the agent operates inside an editor, there is also a human layer of risk. You might accidentally approve a tool call while iterating. You might confuse a paper trading session with a live one. For this reason, Felix requires explicit owner authorization before any key can access live markets. Paper trading is the default mode for new integrations. The model can call all the same tools, but the orders route to a simulation layer. Only after you review the agent's behavior and set your safety controls should you authorize live trading. Remember that trading can lose money, including everything, and no safety control can eliminate that possibility. The controls exist to contain the speed and scope of loss, not to guarantee profit. Profit is never guaranteed, and the presence of an intelligent agent does not change the underlying mathematics of risk and reward.

How do you move from prototype to live trading?

Moving from a prototype to live trading should be a deliberate sequence, not a sudden switch. The exact request schema is in the docs; the shape looks like this:

POST /... HTTP/1.1
Authorization: Bearer YOUR_KEY
Content-Type: application/json

{
  "market": "btc",
  "side": "buy",
  "notional": 500.00
}

Use this illustrative structure to understand how the agent communicates intent, but always verify the current fields against the official documentation before sending real orders. The transition process itself follows a clear order:

1. 01Prototype in paper trading. Let the agent use the full MCP toolkit against simulated markets. Watch how it handles errors, missing data, and edge cases.
2. 02Audit every tool call. Inspect the parameters the agent generates. Check that notional values are in plain US dollars and that the market identifiers match your expectations.
3. 03Set hard limits before authorizing a live key. Define budget caps, position limits, and drawdown thresholds. Connect a kill switch and test it.
4. 04Authorize a scoped key explicitly. Do not reuse a general-purpose key. The key should have the minimum permissions required for the strategy.
5. 05Run a short live session with tight limits. Monitor fills, slippage, and behavior. Keep the editor session active and the kill switch within reach.

During this process, the agent remains non-custodial. You can read more about how execution works while you retain full custody in how an AI agent executes orders while you keep full custody. The goal is to verify that the agent's reasoning, the MCP tool calls, and the infrastructure safety controls all align before you scale up exposure.

What are the risks of keeping the agent this close to your capital?

The main risk is speed without friction. In a traditional setup, deploying to production involves enough steps that you have time to reconsider. In an AI code editor, the agent can generate, justify, and execute a trade in seconds. That speed is useful for capturing fleeting opportunities, but it also means that a misinterpreted comment or a hallucinated parameter can turn into a real position before you have fully processed the suggestion. Another risk is context bleed. The model might carry over reasoning from a previous conversation about a different strategy, or it might apply a parameter value from a paper test to a live order. Because the editor retains conversation history, the agent's state is not isolated per strategy. You should start fresh sessions for distinct strategies and explicitly reset context when switching between paper and live modes. Finally, local environment risks matter. Your editor runs on your laptop or workstation. If that machine is compromised, an attacker could potentially interact with the MCP layer. While Felix's non-custodial design prevents direct theft of funds, since the agent cannot withdraw, an attacker could still cause harmful trades. Scoped keys, short expiration times, and the kill switch mitigate this, but you should also secure your local machine with standard practices like disk encryption and key storage in a dedicated vault. You should treat your trading workstation with the same care you would treat a hardware wallet: minimal installed software, encrypted storage, and no casual browsing.