How to build an AI trading agent from first principles

An AI trading agent is built by combining a reasoning layer that interprets market data, an execution layer that sends orders through an API, and a risk layer that enforces hard limits on spending and access. The owner defines the strategy in plain language or code, keeps funds in a non-custodial wallet, and grants the agent a scoped key that can trade but cannot withdraw. This separation of reasoning, execution, and custody is the foundation of agentic trading, and it ensures that the agent operates as a controlled automation rather than an autonomous fund manager.

What is an AI trading agent?

At its core, an AI trading agent has three parts: a reasoning layer, an execution layer, and a risk layer. The reasoning layer is typically an LLM or a deterministic script that processes market data, news, or price feeds and decides what action to take. The execution layer translates that decision into an order by calling an API. The risk layer enforces boundaries before any order reaches a market, ensuring the agent cannot spend more than its allowance or access functions outside its scope. This architecture separates decision making from custody, which means the agent can suggest trades but cannot move funds to an address you have not approved. You can think of the agent as an employee with a company card that has daily limits and merchant restrictions, rather than as a co-owner of the account.

It is important to distinguish an AI trading agent from a signal service or a managed fund. A signal service tells you what to trade, but you execute manually. A managed fund takes your capital and pools it with other investors. An agent, by contrast, executes automatically on your behalf while your funds remain in your own wallet. You can inspect its reasoning, modify its prompts, and shut it down at any time. This transparency and control are the defining features of the agentic model.

The agent can operate across stocks, crypto, perpetual futures, options, and prediction markets through a single integration. You do not need separate accounts or different programming models for each market type. The API normalizes the differences between a stock broker, a crypto exchange, a perps venue, an options venue, and a prediction market so that the agent reasons about trades in the same way everywhere. This normalization is important because it lets you write one strategy and deploy it across multiple market types without rewriting the contract math for each venue.

How does an AI trading agent connect to markets?

Agents connect to Felix through either MCP tools or a direct REST API. MCP, or Model Context Protocol, lets an LLM client such as Claude or Cursor discover available trading tools and call them as functions. The LLM does not hold your keys; the MCP server holds the scoped key and validates every request against your configured limits before forwarding it. Alternatively, you can write a script that calls the REST API directly, which is useful when the logic is purely code based and does not need an LLM reasoning step. Both paths use the same underlying key and the same safety controls.

The exact request schema is in the docs; the shape looks like this. You provide your key, the market you want to trade, the direction, and the size in US dollars. The API handles the conversion from dollars into the specific contract size or share count required by the underlying venue. This means your agent can think in terms of a one hundred dollar position rather than in terms of lot sizes, leverage multipliers, or tick values. The abstraction reduces errors, especially when the same strategy runs across instruments with different margin rules.

{
  "key": "YOUR_KEY",
  "market": "example-market",
  "direction": "buy",
  "size_usd": 100
}

Developers who want to understand how a single API can span all five market types should read our overview of how trading APIs let AI agents trade across markets. The article explains how the normalization layer works and why it matters for multi-market strategies.

What controls keep an agent from losing too much?

Safety is not an afterthought in agentic trading; it is the foundation. Felix is non-custodial by construction, meaning your funds sit in a wallet that you control. The agent receives a scoped key that can place orders and query balances, but it cannot withdraw funds to itself or to any address that you have not explicitly approved. Even if the agent is compromised, the attacker cannot steal the underlying capital; they can only trade within the limits you set.

Those limits include budget caps, position limits, and drawdown thresholds. A budget cap is a hard ceiling on how much the agent can deploy in a given period. A position limit prevents the agent from taking oversized exposure in a single instrument. An exit plan, which can include take profit and stop loss rules, is enforced by the API so the agent cannot override it to avoid a loss. Finally, a panic or kill switch flattens all positions and revokes the key immediately. You can read a step by step walkthrough of configuring these in how to configure spend caps and drawdown limits for live agent trading.

Scoped keys are another layer of protection. You can build a key that only permits trading on specific markets, only allows buying and not selling short, or only permits orders below a certain dollar size. This granularity means that a bug in the agent's reasoning layer is contained by the key's permissions before it can cause harm. Audit logs record every decision, every API call, and every fill, so you can reconstruct exactly what happened after the fact.

The panic switch deserves special attention. When triggered, it does not merely pause the agent; it sends flattening orders to close all open positions and then invalidates the API key. Because the key is scoped, even a compromised agent cannot prevent this by trying to generate a new key or change permissions. The flattening orders are market orders, which means they will execute at the prevailing price, not an idealized price. This is by design, because the goal of the switch is to remove exposure instantly, not to optimize the exit.

How should a beginner size the first positions?

Position sizing is the most common place where beginners make mistakes, because the mental math of contracts, leverage, and margin can obscure the actual dollar at risk. Felix sizes every order in plain US dollars. When you tell the agent to allocate one hundred dollars, the API translates that into the correct number of shares, contracts, or units for the underlying venue. This removes ambiguity and lets you reason about risk in intuitive terms. You can read a deeper treatment of this topic in how to size positions for an AI trading agent from first principles.

A beginner should start with an amount that they can afford to lose completely on every single trade. This is not pessimism; it is a realistic acknowledgment that trading can lose money, including everything. A common approach is to fix the agent's budget at a small fraction of total capital, perhaps a few hundred dollars, and to let the agent trade only one or two positions at a time. You should not increase the budget simply because the agent had a few winning trades in paper mode. Live markets involve slippage, liquidity gaps, and tail events that paper accounts do not always replicate perfectly.

Perpetual futures and options carry additional risks because of leverage and time decay. Even though the API presents these as dollar amounts, the underlying instruments may move faster than spot markets. A beginner should avoid leveraged instruments until they have observed the agent's behavior through multiple market cycles in paper trading. The goal of the first live positions is not to generate profit, but to validate that the agent's reasoning, the API's execution, and the risk controls all work together under real market conditions.

How do you test an agent before live trading?

Every agent should spend time in paper trading before it touches live capital. Paper trading uses real market data and real order matching logic, but the funds are simulated. This lets you observe how the agent responds to volatility, news, and gaps without financial loss. You can test the full stack, from the LLM reasoning to the API normalization to the risk controls, in an environment that behaves identically to production.

Before you authorize a live key, review the audit logs from the paper period. Look for unexpected orders, repeated errors, or positions that were held longer than intended. If the agent behaved predictably, you can graduate to live trading by explicitly authorizing a live key. This authorization step is manual; it cannot happen by accident. You can read more about the evaluation criteria in how to evaluate paper trading for an AI agent before live markets.

What does the setup look like in practice?

1. 01Define your strategy in plain language or in code, including entry conditions, maximum holding period, and intended markets.
2. 02Configure the safety controls: set a budget cap, define position limits, write an exit plan, and decide the kill switch trigger.
3. 03Connect the agent via MCP or REST and run it in paper trading.
4. 04Review the logs and refine the strategy.
5. 05Authorize a live key with the same controls, starting with the smallest practical size.

After going live, monitor the agent daily at first. Check that the audit logs match your expectations and that the drawdown limits are not being hit. If you notice behavior you do not understand, revoke the key and return to paper trading. The infrastructure is designed to let you iterate safely, not to encourage a set and forget mindset. Markets change, and an agent that worked last month may need new prompts or new limits next month.

Iteration is a normal part of the process. Most beginners will go through several cycles of paper trading, adjustment, and live testing before they find a strategy that fits their risk tolerance. Each cycle should teach you something about the agent's behavior, the market's liquidity, or the interaction between the two. The infrastructure supports this by letting you revoke and reissue keys quickly, so the cost of a mistake is limited to the time spent debugging rather than a permanent loss of capital.