How running a trading agent from an AI editor differs from doing it manually

Running a trading agent from an AI code editor shifts the work from writing and deploying infrastructure to describing intent and reviewing generated actions. The editor can write code, interpret market data, and send orders through an MCP tool or the REST API, but it does not remove the need for safety limits, explicit authorization, and continuous human oversight. The difference is not simply speed or convenience. It is a structural change in who maintains the logic, how errors propagate from a vague description into live positions, and where the boundary between human judgment and automation sits.

What does manual implementation look like?

When you build a trading system manually, you own every layer of the stack. You write the data ingestion, the signal logic, the order construction, the retry logic, and the risk checks. You choose the programming language, manage the dependencies, and handle authentication flows with each venue. This gives you complete control, but it also means you must maintain every integration point and normalize differences between a stock broker, a perps venue, an options venue, and a prediction market.

The manual path requires you to think in venue-specific terms. A stock order might be sized in shares, a perp in contract units with notional calculations, and an option in contracts with multiplier adjustments. You must track decimals, tick sizes, margin requirements, and fee structures yourself. If you want to trade across all five market types, you build five separate connectors or abstract them into a library you maintain.

• ·Writing custom clients for each venue's API and handling rate limits
• ·Translating strategy intent into precise order parameters yourself
• ·Building your own safety rails like position limits, daily loss limits, and kill switches
• ·Deploying and monitoring the infrastructure on your own servers or containers
• ·Managing secret rotation and key storage without leaking credentials in logs

The cognitive load is high because you are both the strategist and the systems engineer. Every bug is your bug, and every edge case is one you must have anticipated. The upside is that the behavior is deterministic. The code does exactly what it says, and it does not change unless you deploy a new version.

What changes when an AI editor runs the agent?

When you use an AI code editor to run a trading agent, the interaction model changes. You describe what you want in natural language, and the editor generates or executes code that calls trading tools through MCP. The editor becomes the interpreter between your intent and the API, generating logic on the fly rather than running a static script you wrote last month.

This means the agent can suggest order sizing, entry conditions, and exit plans in response to prompts. The logic is generated dynamically and may vary between sessions unless you pin it explicitly in a file. The editor has access to your codebase and can read files, fetch data, and call tools in a single turn. You review and approve actions before they execute, unless you explicitly configure auto-execution.

The key difference is that the AI editor is not just an IDE. It is an active participant in generating the trading logic. It may refactor your strategy, suggest a different data source, or reinterpret your instructions based on context window limits. This dynamism is useful for exploration, but it introduces non-determinism. The same prompt can yield slightly different code on Tuesday than it did on Monday, especially if the underlying model has been updated or if the conversation history differs.

There is also a change in the debugging model. When a manual system fails, you trace the code. When an AI editor workflow fails, you trace the prompt, the generated code, and the model's reasoning. The surface area for errors expands from pure syntax to semantic interpretation. You must now verify that the agent understood your intent correctly, not just that the code compiles. What changes when you let an agent trade every market through one API

How does the API normalize things in both cases?

Whether you write code manually or generate it with an AI editor, the Felix API presents the same interface. Orders are sized in plain US dollars, and the system handles venue-specific contract math behind the scenes. This normalization matters more with an AI editor because the agent does not need to learn per-venue conventions. It can reason about a fifty-dollar position in a prediction market the same way it reasons about a fifty-dollar stock order.

However, the trust model differs. In a manual system, you embed the API key in code you wrote and you control the execution path. In an AI editor workflow, the key is exposed to the agent through an MCP tool or environment variable, so the scope of that key becomes critical. The agent can read the key, construct requests, and send them. You should use a scoped key with budget caps and position limits regardless of who wrote the surrounding code. The API is the same, but the path the credentials travel is not.

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

mcp tool call place_order \
  --api-key "YOUR_KEY" \
  --market "prediction" \
  --side "buy" \
  --notional "50.00"

In a manual system, you might batch orders or manage a complex event loop. In an AI editor workflow, the agent typically acts in discrete turns, generating one or a few calls at a time. This turn-based execution can be an advantage for oversight, but it may be slower for high-frequency decisions. The API does not care who constructed the payload, but you should care about how quickly the agent can act and whether it waits for your approval at each step.

How do safety controls differ between manual and agentic execution?

In a manual system, safety is code you wrote and tested. You trust your own unit tests and your own kill switch implementation. In an AI editor workflow, safety is partially enforced by the platform and partially enforced by your prompt design. Felix provides scoped keys, budget caps, position limits, exit plans, and a panic switch that flattens positions and revokes access. These controls exist in the API layer, so they apply no matter who generated the order.

But the AI editor introduces a new class of risk: prompt-level ambiguity. If you tell the editor to scale into a position gradually, the agent must interpret what gradual means. Without explicit constraints, it might choose a pace that breaches your intended risk profile. It might also interpret a vague instruction as permission to trade multiple markets when you only intended one. The controls are the same, but the source of instructions is now an LLM that reasons over natural language.

You should set hard limits before you connect the editor. Budget caps prevent the agent from exceeding a daily loss limit. Position limits prevent oversized concentration. A kill switch gives you a mechanical way to stop everything without relying on the agent to cooperate. These are not optional extras. They are the boundary between an experiment and a live system that can lose money, including everything. How to secure an AI trading agent without giving up custody

The difference in execution is subtle but important. In a manual system, your kill switch is software you control. In an AI editor workflow, the kill switch is a platform feature that operates independently of the agent. Even if the editor is confused or stuck in a loop, the panic switch can flatten and revoke. This separation of concerns is a safety win, but it only works if you configured the limits before trading began.

What should you verify before letting the editor trade?

Before you allow an AI editor to send orders, you need to inspect the generated logic just as you would review a colleague's pull request. The editor can make reasonable-sounding mistakes. It might misunderstand the direction of a perp funding rate, confuse notional sizing with share count, or generate an exit plan that never triggers because of a logic error.

1. 01Read the generated code or tool call sequence before approving execution
2. 02Confirm that the API key is scoped to the minimum markets and budgets needed
3. 03Verify that the agent is not requesting withdrawal permissions or unapproved addresses
4. 04Test the strategy in paper trading mode to see how the editor behaves across multiple sessions
5. 05Document the prompt you used so you can reproduce or audit the agent's behavior later

Paper trading is especially important because the editor may generate different logic each time you restart the conversation. A strategy that behaved safely yesterday can drift today if the prompt context changes. You should run the agent through a few market scenarios in paper mode and inspect the orders it constructs. Look for off-by-one errors, incorrect side assumptions, and sizing that exceeds your comfort level.

You should also consider the operational rhythm. A manual system can run unattended if you trust your code. An AI editor workflow usually requires you to be present to approve or deny actions, unless you have explicitly built an autonomous loop. Do not assume that the editor will wait for your nod. Check the MCP client settings to confirm whether tool calls require human approval or execute automatically. What to check before running a trading agent from Claude

How does prompt design affect the gap between manual and agentic trading?

When you trade manually, your intent is expressed in code. When you trade through an AI editor, your intent is expressed in prompts. This translation layer is where subtle errors enter. The editor may assume default behaviors that you never specified, or it may prioritize brevity over safety because it was not explicitly told to check limits.

Good prompt design treats the agent as an executor, not a strategist. You provide the strategy, the risk parameters, and the constraints. The editor's job is to map those into API calls, not to invent a thesis. If you ask it to find opportunities, it will invent criteria. If you ask it to execute a specific set of rules, it will stay closer to your intent.

Suppose you want a simple momentum scan. In a manual system, you write the scan logic, the entry filter, and the position sizing formula. In an AI editor workflow, you write a prompt that describes the same logic. The difference is that the editor might choose a different filter implementation if your description is vague. The output is only as precise as the prompt, and the stakes are real money.

This means you should version your prompts and treat them as configuration files. Store them in your repository, diff them, and review them before live runs. The editor can help you iterate faster, but the responsibility for clarity remains with you. A manual system fails when your code is wrong. An agentic system fails when your prompt is ambiguous and your review is rushed. What most people get wrong about prompt design for non-custodial trading agents