How to avoid the first-principles mistakes when running a trading agent from Claude

Most people go wrong by assuming that Claude is the trading system. They treat the model as a source of alpha, a risk manager, and an execution engine all at once. In practice, Claude is a reasoning layer that translates natural language intent into structured API calls, while the actual safety, custody, and market access live in a separate infrastructure layer. The first-principles mistake is building the prompt before building the boundary.

What does running a trading agent from first principles actually mean?

Working from first principles means decomposing the system into parts that cannot be reduced further, then assigning each part a single, non-overlapping job. A trading agent has at least four distinct parts: your capital in a wallet you control, the API that normalizes market access, the model that reasons about your intent, and the guardrails that constrain every action. When these parts overlap, confusion follows. People ask Claude to manage risk, choose positions, and execute orders, all within one conversational prompt. That collapses the architecture into a single opaque box where no layer is accountable. First principles demands that you keep the strategy hypothesis separate from the execution plumbing, and both separate from the safety controls. The model does not hold your funds. The API does not guess your intent. The wallet does not reason about market direction. Each layer has a contract with the others, and that contract should be written down and verified before any money is at risk.

Why do people treat Claude as the strategy instead of the interface?

The natural language interface makes it easy to confuse conversation with computation. You can ask Claude what it thinks about a stock or a crypto token, and it will respond with a coherent, well-structured paragraph. That coherence is not a trading edge. It is a language completion trained on public text. The model does not have real-time privileged access to order books unless you feed it through tools, and even then it interprets symbols rather than sensing market microstructure. The strategy is your rule set. It lives in your head, or in a written plan, or in a structured policy document. Claude's job is to map that policy into the JSON or tool calls that the Felix API expects. If you want to rebalance a portfolio when a sector weight drifts above ten percent, you describe the threshold in plain language. Claude translates the description into a dollar-sized order. If you ask Claude to invent the threshold for you, you have outsourced the strategy to a text model. That is the fundamental mistake. How to run your first trading agent from an AI code editor using MCP shows how to keep the model in the translation layer rather than the decision layer.

Suppose you maintain a simple rule: if cash falls below five percent of the portfolio, pause new orders and alert the owner. This is a policy. The agent should check the condition, call the API for a balance, and either proceed or stop. The reasoning is visible and auditable. The model does not need to predict where the market is going. It only needs to follow the policy exactly. When you treat the model as the strategy, you lose auditability. You cannot inspect why a trade happened because the reasoning is buried in a probabilistic text generation. When you treat the model as the interface, every decision traces back to a rule you wrote, and the model's role is to translate that rule into the correct tool call without adding its own market opinion.

Why do paper trading results create false confidence for live agents?

Paper trading on Felix is a useful integration test. It confirms that your MCP connection works, that the model parses your intent correctly, and that the API shapes orders in plain dollars without rounding errors or unit mismatches. What paper trading does not confirm is how the strategy behaves when latency, slippage, and real profit and loss enter the picture. The agent itself may act with the same logic, but the market does not. A limit order that fills cleanly in paper mode may sit unfilled in a live book. A supposed arbitrage between a stock broker and a perps venue may disappear when transfer times and funding rates are considered. People see clean paper results and assume the strategy is validated. In reality, they have only validated the plumbing.

Live trading also changes the authorization model. A paper key can simulate orders, but a live key requires explicit owner approval of withdrawal addresses and budget limits. The psychological difference matters. When real money moves, the owner pays closer attention, and the agent may encounter scenarios that did not appear in simulation. The correct use of paper trading is to test the prompt and the integration. The correct use of the first live session is to test the guardrails under real stress with a trivial budget. You are not trying to generate returns. You are trying to confirm that the boundary between the model and your money holds when the numbers are real.

Why is building guardrails after the strategy a fundamental error?

The most common setup pattern looks like this: write an elaborate prompt, test it in paper mode, observe simulated profits, and then add a safety rule or two before going live. This is backwards. The safety layer is not a feature you bolt onto a strategy. It is the container that defines where the strategy is allowed to run. Felix provides scoped keys, budget caps, position limits, exit plans, and a panic switch that flattens and revokes access. These controls should be configured before the first prompt is written. If you build the strategy first, you implicitly optimize for speed and expressiveness without constraints. The agent learns to act within an open field. When you later add a fence, the agent may already have developed habits that bump against it, causing unexpected rejections or errors that waste time and erode trust.

Think of the guardrails as the shape of the sandbox. The strategy is the game played inside. If the sandbox is too large, the game can wander into dangerous territory. If the sandbox is defined first, the game adapts to the boundaries. A scoped API key for an MCP trading agent should restrict which markets are accessible, how much notional exposure is allowed per day, and which actions are permitted. The panic switch should be tested before live trading, not after. You should know exactly how long it takes to flatten a position and revoke the key. How to audit your trading agent guardrails before going live provides a checklist for verifying that the container is tight before the strategy enters it. How scoped API keys become unsafe for MCP trading agents explains the common misconfigurations that turn a scoped key into a loose one.

How should you think about dollar sizing and API normalization?

Another first-principles mistake is assuming that the agent must think in contracts, ticks, or lot sizes. Felix normalizes venue-specific math into plain US dollars. You tell the agent to buy one hundred and fifty dollars of an asset, and the API handles the conversion to the correct number of shares, coins, or contracts. This seems like a convenience, but it is an architectural separation. The model reasons in human terms. The API reasons in market terms. When you force the model to calculate contract sizes, you give it arithmetic to do. That arithmetic is error-prone and unnecessary. The correct division of labor is that you state the dollar amount, the model confirms the intent, and the API translates the amount into the precise units required by the stock broker, crypto exchange, or perps venue.

This normalization also keeps the agent portable. If you switch from a stock broker to a perps venue, the dollar intent remains the same. The API adapts the sizing. The model does not need to relearn a new contract specification or tick size. You should still set hard caps on the dollar amounts the agent can commit. How to control the risks of dollar-based order sizing through a single API discusses how to keep the sizing layer from becoming an accidental source of leverage. The key point is that the model should never be asked to compute notional value or margin requirements. It should state intent in dollars, and the infrastructure should enforce the cap and handle the venue math.

What is the simplest safe way to go live?

Start with a single scoped key and a narrow window. The exact sequence matters less than the discipline, but the following order reduces risk.

1. 01Create a scoped key with a tiny daily budget and access to one market type only.
2. 02Test the panic switch manually before any orders are placed.
3. 03Connect the agent, watch it for a short window, and then revoke the key to review the logs.
4. 04Do not let the agent run overnight on the first attempt.
5. 05After reviewing logs, expand the budget or add a second market only if the boundary held.

The purpose of the first live session is not to make money. It is to confirm that the boundary holds when real money is at stake. Trading can lose money, including everything, so the first live session should risk the smallest amount that still teaches you something about how the system behaves under real conditions.

After the first session, audit the logs. Check whether the agent stayed within the dollar cap, whether it interpreted your intent correctly, and whether the kill switch would have worked if you had triggered it. Only then expand the budget or add a second market. The first-principles approach is incremental. You validate the boundary, then the translation layer, then the strategy, then the scale. Reversing that order is how most people get hurt. The model is powerful, but it is only one part of a stack that includes your capital, your API, and your discipline. If any of those layers are missing, the agent is not a tool. It is a liability.

Frequently asked questions