Common mistakes with agentic trading from first principles

Most failures in agentic trading come from treating an AI agent as a faster version of the human trader rather than as an autonomous system with distinct failure modes. From first principles, an agent is a loop that observes data, makes decisions within a context window, and executes actions through tools it does not fully understand. The mistakes that destroy capital are architectural errors in how the owner defines boundaries, communicates intent, and handles failure. If you do not design constraints as rigorously as you design the strategy, the agent will interpret silence as permission and ambiguity as flexibility.

What is agentic trading from first principles?

From first principles, agentic trading means an autonomous system that connects to markets through an API, evaluates structured and unstructured data, and submits orders without requiring a human to confirm each individual trade. The agent has a goal, a set of tools, and a context window. It does not have intuition, fear, or an internal model of your personal financial situation. It only has what you write in the prompt and the guardrails you encode in the infrastructure. The most common mistake is anthropomorphizing the agent. You assume it understands context that is not explicitly written, or that it will self-correct when it sees losses mounting. In reality, an agent executes the policy you gave it, literally and mechanically. If the prompt is ambiguous, the agent fills the gap with pattern completion, not reasoning. If the guardrails are missing, the agent continues operating because it has no concept of enough or stop. First principles thinking requires separating the market strategy from the agent control plane. The strategy is what the agent should do in ideal conditions. The control plane is what the agent is allowed to do when conditions are not ideal. Confusing these two layers leads to agents that pursue theoretical alpha while ignoring real budget limits, liquidity constraints, and correlation risks. The agent does not know what you meant. It only knows what you said.

Why do agents trade the wrong size?

Position sizing is where most first-principles mistakes become expensive. A human trader might feel emotional resistance to risking too much on a single position. An agent feels nothing. If you tell an agent to buy when it detects a signal, and you do not specify the maximum dollar amount, it may interpret the instruction as a percentage of available buying power, a fixed number of contracts, or a relative weight. The result is often a position that is either trivially small or dangerously large. The error is leaving size implicit. On Felix, orders are sized in plain US dollars, which removes venue-specific contract math, but the agent still needs an explicit ceiling. You must tell it, in the prompt or in the scoped key configuration, that a single order cannot exceed a specific dollar amount. Better yet, you set the budget cap in the key itself so the agent cannot physically exceed it, regardless of how creatively it parses the prompt. Another sizing mistake is ignoring correlation. An agent running on multiple markets might take five positions that look different but share the same underlying risk. From first principles, the agent does not know that a long stock position and a long perp position in the same underlying asset are correlated exposures. You must either give it an explicit portfolio view or constrain the total delta exposure across all markets. The manage risk article covers how to structure these limits so the agent respects your total capital, not just per-order limits.

How does poor prompt design break execution?

Prompt design for trading agents is not creative writing. It is the specification of a decision function with zero ambiguity. The most common mistake is mixing strategy with operational instructions in one unstructured block of prose. When the agent must parse intent from a conversational paragraph, it may prioritize the most recent sentence, the most statistically common phrase in its training data, or a literal keyword match rather than the most important constraint. A second error is failing to specify what the agent should do when data is missing, when a venue is unreachable, or when a signal conflicts with a budget limit. If the prompt only describes the happy path, the agent will hallucinate a path forward. It might retry an order indefinitely, switch to a different market without authorization, or interpret a timeout as a successful fill. These are not malicious actions. They are the logical result of an incomplete specification. The prompt design checklist outlines how to separate goals from constraints, define fallback behaviors, and version your prompts so you can trace why an agent acted a certain way. Prompts are infrastructure. Treating them as casual instructions is a first-principles error that turns a deterministic system into a random number generator with market access.

What happens when safety controls are an afterthought?

Safety is not a layer you add after the agent works. It is the foundation that makes live deployment possible. The mistake is building the agent, testing it in paper mode, and then flipping it to live trading with the same key permissions and no kill switch configured. From first principles, a live agent should have the minimum viable permissions at every stage of its lifecycle. Paper trading should use a key scoped to read-only and paper endpoints. Live trading should require explicit owner authorization of a new key with budget caps, position limits, and an exit plan already configured. If you reuse the same unrestricted key for both phases, you have not tested the safety architecture. You have only tested the strategy logic in a sandbox that does not represent the real control plane. The single API safety article explains how noncustodial design and scoped keys work together. The funds sit in a wallet you control. The agent can spend within limits but can never withdraw to itself. Withdrawal addresses are owner-approved only. Even with these guarantees, you still need a panic switch that flattens positions and revokes access. An agent without a kill switch is an accident waiting for a market event that moves faster than your ability to react.

Why do agents fail across multiple markets?

Trading across stocks, crypto, perps, options, and prediction markets from one API is powerful, but it multiplies the ways an agent can misunderstand context. A common mistake is assuming that because the API normalizes order sizing into plain US dollars, the agent understands the risk characteristics of each market. It does not. Normalization removes contract math, not economic behavior. An options position has nonlinear payoff and time decay. A perp position has funding rate risk and potential liquidation. A prediction market position resolves at a specific time and becomes binary. The agent sees these as different endpoints, but unless you explicitly tell it that an option delta is not the same as a stock share, it may treat them as fungible exposure. The error is sending a single generic prompt to a multi-market agent without market-specific guardrails. You should scope keys by market type when possible, or at minimum include explicit instructions about how each market affects total portfolio risk. A perp on one asset and a stock on another might create a hidden correlation through a macro factor. The agent does not understand macro. It understands the prompt. The multi-market portfolio article discusses how to manage this complexity without giving the agent unlimited cross-market discretion.

How does neglecting the kill switch create ruin risk?

The kill switch is not a sign of distrust in the agent. It is a recognition that markets change and your initial assumptions can become wrong quickly. The first-principles mistake is thinking that because the agent performed well in backtests or paper trading, it will behave predictably during a flash crash, a liquidity freeze, or a model degradation event where the LLM starts confabulating signals. A kill switch should flatten positions and revoke the agent's key. It is not enough to pause the script on your local machine. The agent might be running on a remote server, or the MCP client might be executing a queued plan. You need an infrastructure-level revocation that takes effect regardless of what the agent is currently thinking. On Felix, the panic switch is part of the control plane, not the agent code, so it works even if the agent is stuck in a loop. You should also define exit plans before the agent starts. An exit plan is a pre-authorized set of conditions under which the agent must close positions and stop. Without this, the agent may hold a losing position because the prompt says buy the dip, and the dip keeps dipping. The agent does not know when the dip becomes a collapse. You must tell it, in advance, what constitutes enough pain.