Why AI agents change trading from first principles

Trading from first principles is a sequence of distinct steps: gathering information, forming beliefs, deciding to act, sizing the position, executing, managing risk while the position is open, and closing. Traditional automation speeds up the execution step but leaves the other steps to a human. AI agents change the structure itself because they can handle ambiguous information, reason about goals, and execute across markets while remaining bound by hard limits that the owner controls.

What does trading look like from first principles?

If you strip away software interfaces and market jargon, trading is a pipeline with distinct stages. Information arrives continuously. Prices, order books, news, and macro data feed into a belief about what an asset might do next. That belief is probabilistic. It turns into a decision only when compared against alternatives, capital constraints, and the cost of being wrong. The decision requires sizing, which depends on available capital and how much loss the account can absorb. Then comes execution, monitoring, and exit, driven either by a target, a stop, or a change in thesis.

Traditional tools handle pieces of this pipeline. Charts and news feeds help with information. Calculators and spreadsheets help with sizing. Brokers and exchanges handle execution. Simple bots can automate execution and monitoring if the conditions are explicit and countable. But the human still sits in the center, forming beliefs, deciding, and often micromanaging the bot. The bot is a faster finger, not a different mind. It does not know why it is trading, only that a condition was met.

An AI agent does not fit neatly into one slot in the pipeline. It can operate across multiple stages because it processes language and numbers together. It can read an order book, summarize a news article, and notice that the two are sending conflicting signals. It can compare a stock position against a prediction market and decide that the prediction market offers a more efficient expression of the same view. This means the agent is not just accelerating a human workflow. It is restructuring who does what, and it can do so across every market type from a single integration point.

Why do rule-based bots struggle with real markets?

Rule-based bots work when the world is countable, static, and fully known. If the price crosses a moving average, then buy. If the RSI exceeds seventy, then sell. This logic is easy to audit and fast to execute. But markets are noisy, non-stationary, and context-dependent. A bot programmed to buy when a technical indicator flashes green will do so even if the company just announced catastrophic news, the broader market is crashing, or the order book shows a massive sell wall. The bot cannot distinguish between a genuine signal and a trap because it has no model of context.

The maintenance burden for rule-based systems is also exponential. Every exception requires a new rule. What about trading halts? What about dividend dates that change options pricing? What about margin adjustments in a perps venue during high volatility? What about a prediction market that resolves early? The human developer must anticipate every state and encode it. In practice, this means bots are either too simple to adapt, which makes them fragile, or too complex to audit, which makes them dangerous. They are brittle by design.

AI agents change this dynamic because they reason over goals rather than enumerating states. They can interpret new information that was never in the training scenario because they understand context and analogy. They can be instructed to maintain a market-neutral book with a bias toward energy exposure, and then decide for themselves which combination of stocks, options, or prediction markets best serves that goal. But this flexibility introduces its own risks. An agent that reasons broadly needs harder boundaries enforced by the infrastructure. Reasoning without guardrails is not autonomy; it is liability.

How does an AI agent change the decision layer?

An AI agent makes decisions by synthesizing observations with a goal, not by matching a condition against a lookup table. Instead of a hardcoded rule like buy below thirty RSI, the agent might have a goal like maintain a market-neutral book with a bias toward energy exposure while keeping single-position risk under two percent of the account. It then observes prices, volatility, cross-asset correlations, and even textual news to decide which positions serve that goal. This is a qualitative difference from a script. The script reacts; the agent plans.

The agent can also operate across market types without separate codebases. It might notice that a stock is expensive but that the same directional view can be expressed more cheaply in an options venue or more precisely in a prediction market. A traditional bot would need separate integrations, separate logic, and separate risk calculations for each. An agent connected to a unified API can reason about the portfolio as a whole. It can ask whether a hedge should live in a perp, an option, or a correlated stock, and it can execute the answer through the same interface.

Importantly, the agent's reasoning is bounded by the infrastructure. The agent can propose, but it cannot spend beyond a cap or hold beyond a position limit. The agent can think about doubling a position, but the API will reject the order if it violates the owner-configured limit. This separation between cognition and permission is what makes autonomous trading viable. The agent is free to think and explore, but the system is the final gatekeeper.

What does a single API change about market access?

When an agent connects through one API and one key to stocks, crypto, perps, options, and prediction markets, the concept of a venue fades into the background. The agent reasons about exposure, not about which exchange supports which contract or which broker requires which margin formula. It can hedge a stock position with an option, or offset risk in a prediction market, without learning five different authentication schemes or five different order formats. The API becomes a translation layer that the agent does not need to understand.

Orders are sized in plain US dollars. The API normalizes venue-specific contract math, tick sizes, and margin requirements. The agent thinks in terms of dollar exposure, which is a much more natural unit for risk management. A $500 position in a stock and a $500 position in a perp carry the same notional sizing language, even if the underlying mechanics differ. The agent does not need to know that a perp contract might represent a fraction of the underlying, or that an option contract controls one hundred shares. It simply states the dollar amount. How developers size orders in dollars walks through the practical details, but the architectural shift is that the agent no longer needs to encode venue logic into its reasoning.

This unification means the agent can focus on higher-level strategy. It can compare opportunities across asset classes without being a domain expert in each. It can rebalance between a crypto perp and a tech stock as easily as it can trade two stocks. The infrastructure handles translation, while the agent handles allocation.

How does non-custodial design change the trust model?

Most trading automation requires trusting a third party or the software itself with custody of funds. You deposit money into an account, generate an API key, and hope the key is not leaked or misused. If the bot is compromised, or if the developer made a mistake, the software can withdraw everything to an unknown address. The trust model is binary: either the software has full access or it does not.

Non-custodial architecture inverts this. The owner retains the wallet. The agent receives a scoped key that can place trades within defined limits but cannot withdraw funds to arbitrary addresses. Withdrawal addresses are owner-approved only, and the agent cannot add new ones. This is not a policy preference or a terms-of-service promise. It is a structural guarantee enforced by the wallet and the API.

The agent can lose money within the budget cap through bad trades or unexpected volatility, but it cannot steal the capital. If behavior becomes erratic, a panic switch flattens positions and revokes the key. How autonomous trading systems enforce hard limits explains how these constraints are built below the agent layer so they cannot be overridden by prompt engineering, reasoning, or a compromised model. This trust model is essential for autonomous systems. An agent that reasons about complex strategies will sometimes be wrong. You want it to be able to act quickly, but you do not want it to be able to exit with your funds. Non-custodial design makes that distinction concrete.

Where do safety controls sit in an agentic loop?

Safety cannot be implemented as a suggestion or a system prompt. It must be enforced by the infrastructure that sits between the agent and the market. Hard limits include spend caps, drawdown limits, position limits, exit plans, and a kill switch. These are not polite instructions. They are API constraints that reject orders or trigger closes regardless of what the agent is trying to do.

For example, a developer might configure a daily spend cap of one thousand dollars. The agent can distribute that across ten trades or one trade, but it cannot place an order that would exceed the cap. The API simply returns an error. Similarly, a drawdown limit might trigger an automatic flattening of all positions when the account loses five percent. The agent is aware of these limits, can plan around them, and can optimize within them, but it cannot disable them. The infrastructure owns the final decision.

Developers sometimes make the mistake of trusting the agent to respect soft limits described in a system prompt. This fails because large language models can hallucinate, loop, or misinterpret instructions under pressure. Common mistakes with spend caps and drawdown limits covers how soft limits fail in practice when the agent faces ambiguous or urgent signals. The correct architecture is to treat the agent as a capable operator inside a locked room. It can move furniture and organize the space, but it cannot open the door or break the windows.

How should developers build their first agent?

Start with paper trading. Define the goal, the markets, and the hard limits before writing a single prompt. The agent needs a clear objective, but the infrastructure needs a hard boundary. Many developers make the mistake of spending hours crafting the perfect system prompt while leaving the API caps unset. The prompt controls behavior, but the API controls damage. Both matter, but the limit is what protects you when the prompt fails.

Once the behavior is acceptable in simulation, authorize a live key with conservative caps. Live trading requires explicit owner authorization, so there is no accidental deployment. Increase the budget slowly. Watch how the agent behaves when it hits a limit. Does it gracefully adjust, or does it retry aggressively? This tells you more about its robustness than its performance.

Agents connect through MCP tools or the REST API. MCP is useful for developers building inside Claude, Cursor, or other MCP clients. The REST API is useful for headless systems that run on a server. In either case, the agent sends intent in dollars, and the system enforces the guardrails. The exact request schema is in the docs; the shape looks like this:

curl -X POST "$FELIX_API_URL/orders" \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "market_type": "crypto",
    "side": "buy",
    "dollar_amount": 250
  }'

Test the panic switch during paper trading. Verify that the kill switch flattens positions and revokes access. Simulate a drawdown limit breach and confirm that the exit plan triggers. Only then increase the budget caps gradually. Remember that trading can lose money, including everything, and that an agent is only as safe as the hard limits you configure. The goal is not to remove human judgment entirely, but to place it in the architecture, not in the loop.