What it takes to move an AI trading agent to live trading in 2026

Moving an AI trading agent from simulation to live capital in 2026 replaces optimistic assumptions with enforced boundaries. The architecture is built around non-custodial wallets, scoped API keys, and hard limits that the infrastructure enforces independently of the agent's reasoning. Before the first order reaches a venue, the system must already know how much it can lose, where it can trade, and how to stop entirely. Without these mechanical constraints, the agent is simply a prompt with a payment method, which is not a deployable system.

How does the custody model stay intact when the agent goes live?

The first layer of the architecture is the custody boundary. Funds sit in a wallet the owner controls, and the agent receives only trading permissions within that wallet. The agent can spend within predefined limits but can never withdraw to itself or to an address the owner has not approved. This is non-custodial by construction, not by policy. The infrastructure enforces this at the wallet and key level, so even if the agent's logic is compromised, it cannot restructure ownership of the funds. The owner maintains full control over the seed or private key material, and the trading key is derived separately with a narrow scope. Withdrawal addresses are owner-approved only, and any attempt to change them requires a separate authorization path that the agent does not possess. When you connect an agent through MCP tools or the REST API, the credentials it carries are scoped to trading actions alone. The agent may run on your local machine, a remote server, or inside an MCP client, but wherever it runs, it only holds a key that can place orders, not a key that can move the wallet's underlying assets. This separation between trading and custody is what makes the system deployable with real money. You can read more about the mechanics in How an AI agent executes orders while you keep full custody and the practical setup steps in A practical checklist for non-custodial AI trading. The architecture assumes that the agent is an untrusted actor that must be caged by permissions, not a trusted actor that happens to be automated. That assumption changes how you build every other layer.

What permissions does an agent actually receive?

An agent does not receive open access to capital. It receives a scoped key with a specific mandate. The owner sets budget caps, position limits, and allowed market types before the agent connects. These constraints are not suggestions in a system prompt. They are hard limits encoded in the key and enforced by the API. If the agent attempts to exceed a cap, the API rejects the order before it reaches a venue. The permission model also distinguishes between paper trading and live trading. Paper trading exists for testing strategy logic, latency assumptions, and data handling without capital at risk. It uses the same API paths and market data, but settlement is simulated. Live trading requires explicit owner authorization of a key, which is a deliberate state change in the system. You cannot accidentally move from paper to live because the authorization step is a separate, owner-initiated action that upgrades the key material. This design prevents drift between testing and production. The scope can be as narrow as a single market type and a five hundred dollar cap, or it can be broader, but it is always finite and always set by the owner. You can configure these boundaries using the approaches described in How to set spend caps and drawdown limits for trading agents. The principle is that the agent should be able to do less than you expect, never more.

How does the API normalize risk across five market types?

One of the architectural challenges in 2026 is that an agent might trade stocks, crypto, perpetual futures, options, and prediction markets within a single strategy. Each venue has its own contract specifications, margin requirements, tick sizes, and settlement cycles. The Felix API handles this normalization so the agent does not need to understand venue-specific math. Orders are sized in plain US dollars, and the API translates that into the correct contract quantities, margin checks, and notional adjustments for each market type. The agent submits a dollar amount, and the infrastructure calculates how many shares, contracts, or units that represents at the current price and venue rules. This reduces the attack surface: the agent cannot miscalculate a leverage ratio, misread a contract multiplier, or confuse a tick size because it never sees them. The infrastructure handles the mapping and the rounding. The exact request schema is in the docs; the shape looks like this:

{
  "market_type": "perpetual_futures",
  "symbol": "BTC-PERP",
  "side": "buy",
  "dollar_notional": "500.00",
  "scoped_key": "YOUR_KEY"
}

By standardizing on dollar-based instructions, the architecture prevents a class of errors where an agent confuses units across markets. A five hundred dollar order is the same instruction whether it targets a stock broker, a crypto exchange, or a perps venue. The API also enforces the owner-defined hard limits during translation. If the dollar notional exceeds the scoped key's remaining budget, the request fails before normalization completes. The agent does not need to track its own running PnL or remaining budget because the API maintains that state and rejects violations automatically. This means the agent can express intent in simple terms, but the infrastructure retains full control over whether that intent becomes a live order. The abstraction layer is what allows one integration to cover five market types without requiring the agent to manage five different contract formats.

Why is the kill switch part of the infrastructure rather than the agent?

A kill switch that lives inside the agent's prompt or reasoning loop is not a kill switch. It is a suggestion that the agent may ignore, misinterpret, or be jailbroken into disabling. The architecture places the kill switch at the infrastructure level, where it can flatten positions and revoke access without the agent's cooperation. When triggered, the system sends exit orders to close open positions and then disables the scoped key. The agent cannot stop this because the revocation happens outside its scope. The key is deactivated at the API gateway, so any subsequent request from the agent is rejected before it reaches a venue. This is paired with an exit plan that the owner defines before going live. The exit plan specifies how to unwind positions, in what sequence, and with what urgency. Because the plan is infrastructure-level, it executes even if the agent is in an unresponsive state or producing malformed requests. The panic switch is the final layer of defense, but it depends on all the earlier layers being correct. If the custody model is wrong, the kill switch cannot recover funds that were already withdrawn. If the permission scope is too broad, the kill switch has too much to unwind. Therefore, the architecture treats the kill switch as a circuit breaker, not a repair tool. You install it to stop the bleeding, not to fix the strategy.

How should position limits translate into hard boundaries?

Position sizing is where many live deployments fail, not because the math is wrong, but because the boundary is soft. The architecture requires that position limits be enforced by the API, not by the agent's internal logic. The owner defines a maximum position size in dollars, and the infrastructure rejects any order that would breach it. This applies across all five market types simultaneously. The agent might request a new position in a prediction market while already holding exposure in a perps venue, and the API aggregates that exposure against the single cap. This prevents the agent from fragmenting risk across markets to evade limits. It also prevents the agent from accidentally doubling exposure through a miscalculation. The sizing logic is described in detail in How to size positions for an AI trading agent from first principles. Trading can lose money, including everything, and hard boundaries do not guarantee profitability. They only guarantee that the agent cannot exceed the owner's predefined maximum pain. That distinction is important. The architecture does not promise returns. It promises containment.

What is the proper sequence from paper trading to live authorization?

The deployment sequence matters as much as the architecture. Paper trading exists for testing the agent's behavior under real market data and latency without capital at risk. During this phase, the owner validates that the agent respects limits, handles errors, and does not generate unexpected order patterns. Paper trading reveals whether the agent misinterprets normalized market data or attempts to trade outside its allowed symbols. Live trading requires explicit owner authorization of a key. This is not a configuration change; it is a cryptographic upgrade that links the scoped key to real settlement paths. The owner should start with the smallest viable budget cap and expand only after observing stable behavior over a meaningful period. The architecture does not allow an agent to self-authorize or to escalate its own permissions. Each increase in budget or market access requires a new owner action, which creates an audit trail. This graduated exposure model reduces the damage from undiscovered bugs. Even in 2026, the most reliable agent is one that has proven it can do nothing unexpected before it is allowed to do anything with real money. Paper trading is not a guarantee of future behavior, but it is a filter that catches obvious failures before they become expensive.