What goes wrong when you run a trading agent from Claude step by step

Running a trading agent from Claude step by step seems straightforward, but most problems start before the first order. Operators often assume the model understands finance, skip safety scaffolding, and move to live capital too quickly. The result is usually unintended positions, exceeded budgets, or trades that do not match the intended strategy. Fixing these errors requires treating the agent as a remote worker with strict instructions and hard limits, not as a trusted advisor with discretion. The following sections cover the mistakes we see most often and how to avoid them.

Why do vague prompts cause the most damage?

The biggest mistake is writing prompts the way you would explain a strategy to a human trader. Claude processes text literally and has no intuition about market context. A phrase like "buy when the market looks weak" means nothing specific to the model. It may interpret a one percent drop as weakness, or it may wait for a twenty percent crash, depending on how the training data weights the word. Neither outcome is predictable.

To prevent this, every prompt must contain explicit thresholds, exact asset identifiers, and unambiguous time frames. Instead of saying "add exposure on a pullback," write "if the price of the tracked asset falls five percent from the prior daily close, submit a buy order for no more than one hundred dollars notional." That removes interpretation. Prompt design for trading agents differs sharply from writing manual rules because the audience is a language model with no memory of your intent between sessions unless you restate it.

Another common error is overloading the prompt with multiple conflicting instructions. When you give the agent five different entry conditions and three exit heuristics in a single message, the model may prioritize the last sentence or ignore the middle constraints. Step-by-step reasoning helps only when each step is atomic and verifiable. If one step is fuzzy, the entire chain becomes unreliable. Some users also assume that because Claude asks clarifying questions, it will resolve ambiguity before trading. In practice, the model may not pause for clarification when connected to an MCP tool. It may simply execute the most probable interpretation of your instruction. That is why you must treat every prompt as a program that will run without further human review. If the instruction is unclear, the trade will still go through, and the explanation you receive afterward will be a rationalization rather than a justification.

How do unsafe API keys expose your capital?

Even a carefully written prompt is dangerous if the key underneath it is too permissive. Felix allows scoped keys, budget caps, position limits, and a panic switch, but beginners often generate a single key and grant broad access because it feels faster. That defeats the non-custodial architecture. While the agent can never withdraw funds to an external address it controls, it can still spend the entire approved budget on losing positions within minutes if the scope is too wide.

You should treat the API key as a credit line with a hard ceiling. Set the budget cap to an amount you are genuinely willing to lose. Set position limits so the agent cannot concentrate more than a small percentage of that budget in a single instrument. Enable the panic switch before you authorize live trading. These steps are covered in detail in the practical checklist for scoped API keys for beginner trading agents. A common mistake is assuming that because Felix is non-custodial, the funds are safe from loss. Non-custodial means safe from theft, not safe from bad trades.

Another oversight is failing to rotate or revoke keys after a test. If you created a key during a paper trading session and later decided to go live, do not reuse the same key with broader permissions without reviewing every scope parameter. Live trading requires explicit owner authorization, and that authorization should be a deliberate checkpoint where you re-verify caps, allowed markets, and withdrawal addresses. If the key was created in haste, the authorization step is your last chance to correct the scope. Do not treat it as a formality.

Why is paper trading skipped too often?

Paper trading exists so you can watch the agent execute against market data without committing real capital. Yet many operators skip it because Claude's reasoning sounds convincing. The model produces confident step-by-step explanations, which creates a false sense of validation. Confidence in language does not correlate with accuracy in market timing.

When you do run paper tests, run them for long enough to encounter edge cases. A single session of normal market conditions tells you almost nothing. You need to see how the agent behaves when an order is rejected, when a partial fill occurs, or when price gaps move faster than the reasoning loop. Live trading requires explicit owner authorization of a key, but that authorization should happen only after repeated paper sessions show consistent, explainable behavior. Remember that paper results include no slippage or liquidity impact, so real fills will differ. Skipping this stage means discovering those differences with actual money.

Operators also make the mistake of testing only one market type and assuming the behavior transfers. An agent that behaves well in spot crypto may act very differently in options or perps because of leverage, delta, or expiration logic. Paper trading should cover every market you intend to use, even if the API abstracts the contract math. The agent still needs to reason about volatility and time, and its step-by-step logic may not account for those variables unless explicitly told. If you skip paper testing for even one market, you are flying blind in that venue.

Where does dollar-based order sizing go wrong?

Felix normalizes order sizing to plain US dollars across stocks, crypto, perps, options, and prediction markets. This abstraction removes venue-specific contract math, but it introduces a different risk. The agent may not understand whether the dollar amount you specified refers to notional exposure, margin required, or maximum risk.

Suppose you tell the agent to open a position of one thousand dollars in a perpetual future with ten times leverage. The notional exposure is one thousand dollars, but only roughly one hundred dollars of margin is reserved. If the agent tracks budget usage by notional value, it believes it has spent one thousand dollars. If it tracks by margin, it believes it has spent one hundred. That confusion can lead to accidental overexposure when the agent opens additional positions elsewhere. The risks of dollar-based order sizing for trading agents are easy to overlook because the API handles the conversion, but the semantic layer remains your responsibility. Always state in the prompt whether the dollar figure is notional, margin, or maximum loss, and enforce a total exposure limit at the key level.

The same confusion appears in options and prediction markets. In options, a one thousand dollar order might refer to the premium paid or the notional value of the underlying contract. In prediction markets, it might refer to the amount risked on a binary outcome or the payout if the outcome resolves in your favor. If the agent conflates these, it can size positions that are far larger than your intended risk. The step-by-step reasoning will still look correct because the model is following your numeric instruction, but the economic meaning of that number is wrong. Before going live, state explicitly in your prompt what each dollar figure represents and confirm that the agent's reasoning trace reflects that definition.

What happens when you trade without exit plans?

Step-by-step reasoning is naturally optimized for entry decisions. The model evaluates conditions, checks signals, and generates a buy or sell order. Exits are harder because they require the model to remember a prior state, compare it to a current state, and overcome the sunk-cost bias embedded in its reasoning trace. An agent told to "hold until the trend reverses" may never sell because it can always construct a narrative that the trend is still intact.

You should not rely on the model to manage exits. Instead, define hard take-profit and stop-loss levels in the prompt, or better, use the platform's built-in exit plan features. Automating exit plans and take profits with MCP removes the burden from the reasoning loop and enforces discipline. A frequent mistake is giving the agent an exit condition that is subjective, such as "sell when momentum fades." That is just as vague as a bad entry prompt. Convert every exit rule into a price level, a time limit, or a percentage drawdown. If the agent has no external exit plan, a winning trade can become a losing trade simply because the model kept reasoning.

Another subtle error is allowing the agent to manage exits across multiple positions simultaneously without priority rules. When Claude reasons step by step, it may evaluate one position, decide to hold, then evaluate another, and decide to sell. The order of evaluation can change the outcome. If you have ten positions and a shrinking budget, the agent may sell the wrong ones first because they appeared earlier in the context window. Hard exit plans with explicit priorities prevent this. You should also set a maximum time limit for any trade. An agent without a deadline can rationalize waiting indefinitely, and every additional reasoning step increases the chance of drift.

How should you monitor an agent after it goes live?

Going live is not the end of the setup process. Many operators treat an authorized agent as a finished product and check it only when they remember. That is a mistake. The first live session should be watched in real time, comparing the agent's stated reasoning with the actual positions in the wallet. Discrepancies between what Claude says it did and what the exchange records show are often the first sign of a prompt or tool interpretation error.

You need two layers of monitoring. First, review the reasoning trace to see if the model is interpreting market data correctly. Second, review the actual portfolio state to see if the trades landed as intended. Logs show intent, but the portfolio shows outcome. If the agent begins to drift, use the panic switch to flatten positions and revoke access immediately. Do not wait for the model to correct itself. Trading can lose money, including everything, and speed matters more than politeness when behavior diverges from the plan. After any panic event, inspect the audit trail to determine whether the root cause was a bad prompt, a tool misread, or a market condition you failed to constrain.

A related mistake is monitoring only the profit and loss rather than the agent's decision process. A profitable day can hide bad reasoning, and a losing day can be the result of correct execution in a bad market. If you only watch the bottom line, you will not catch the agent when it begins to deviate from your strategy but happens to get lucky. Instead, watch for changes in the structure of the reasoning trace. If the agent starts using new justifications, referencing data points you did not authorize, or ignoring previously stated constraints, those are early warnings. The panic switch is there to protect you from both losses and strategy drift.