A practical checklist for building your first LLM-powered trading agent

If you have never automated a trade, you can still build an LLM-powered trading agent by starting with scoped access, hard budget caps, and a paper trading environment. The checklist is simple: define what the agent is allowed to trade, how much it can lose, how it will get out of positions, and how you can stop it instantly. Only after these constraints are locked should you connect the agent to live markets with real money.

What do you need before you write any code?

Start with a plain language document, not an editor. The LLM is a reasoning layer that will follow instructions, but it cannot invent a coherent strategy from vague prompts. Pick one market type to begin with. Felix supports stocks, crypto, perpetual futures, options, and prediction markets through one API, but beginners should master one instrument before adding others. Each market has different volatility profiles and session hours. A prediction market might resolve around a single event, while a stock position can drift for weeks. If you mix these before you understand how your agent reacts to one, you multiply your debugging surface. Write down the exact conditions that would trigger a trade. For example, state the data the agent will observe, the threshold that must be crossed, and the action it should take. Be explicit about frequency. Will it check for signals every hour, once a day, or only after specific events? Ambiguity in the prompt leads to unexpected trades, so remove it before the agent sees any market data.

Next, decide how much money you are willing to lose. Write this as a concrete dollar amount, not a percentage of a portfolio you hope to grow. Trading can lose money, including everything, so your documented limit should reflect what you can actually afford to lose in a day or a week. Include a time horizon. If the agent holds a position for longer than your threshold, what should it do? This document becomes your specification. Do not write code or connect APIs until the specification is complete and readable by someone who does not trade. If you cannot explain the logic simply, the LLM will not execute it reliably. Ask a friend to read it. If they cannot tell you what the agent will do when prices drop ten percent, rewrite the instructions until they can.

How should you size positions and set limits?

Felix normalizes orders in plain US dollars, which removes the need to think about contract sizes, lot increments, or margin formulas on your first day. Use this simplicity to set hard numeric ceilings. First, define a total budget cap. This is the maximum amount of capital the agent can deploy across all open positions at any moment. Second, define a per trade limit. No single order should exceed a specific dollar amount you choose. Third, set a maximum number of concurrent positions. If the agent is allowed to hold three trades at once, write that down and enforce it. Fourth, set a daily loss limit. If the agent loses a predefined dollar amount in a single day, it must stop trading until you manually review the strategy. These limits are not suggestions. They are the walls of the sandbox you give the agent.

These numbers should be enforced by the infrastructure, not just mentioned in the prompt. An LLM can misinterpret context or be influenced by unexpected data. If the budget cap lives only in the prompt text, the agent might exceed it during a volatile session. Hard limits in the API layer prevent this. Never let the agent dynamically size positions based on its own confidence score or predicted edge. You set the dollars; the agent executes within them. Remember that trading can lose money, including the entire budget you allocate, so size accordingly. If your total budget cap is five hundred dollars, treat it as five hundred dollars you may lose entirely. Only increase it after weeks of consistent paper and live behavior that matches your specification.

What safety controls should you configure first?

Before the agent touches a live market, configure four layers of safety. The first layer is access control. The second layer is budget and position limits. The third layer is exit rules. The fourth layer is the kill switch. Each layer should be active before any order is placed.

• ·Scoped API keys: permit only the specific markets and actions you documented, and never allow withdrawals.
• ·Budget caps and position limits: enforced at the key level so the agent cannot borrow or margin beyond your intent.
• ·Exit plans: every entry must have a planned exit, including a stop loss, a take profit target, and a time based exit if the trade does not resolve within your window.
• ·Panic or kill switch: a control you can trigger that immediately flattens all positions and revokes the agent's key.

Felix is non-custodial by construction. Your funds sit in a wallet that you control. The agent can spend within the limits you set, but it can never withdraw to itself or steal funds. Withdrawal addresses are owner approved only, meaning you must explicitly whitelist any destination before funds can leave. This architecture removes the risk of an agent draining your account, but it does not remove market risk. You can still lose money on bad trades, so the scoped key, budget cap, and exit plan are essential. You can read more about why scoped API keys matter for real money and how to build your first automated exit plan.

How do you connect an LLM to real markets?

Agents connect to Felix through MCP tools, which work with Claude, Cursor, and other MCP clients, or through the REST API directly. The LLM itself does not hold your private key. Instead, it calls a tool that routes an order to the API using your scoped key. This separation is important. If the LLM session is compromised, the attacker does not receive your raw credentials; they only gain access to the scoped tool, which still respects your budget caps and market restrictions. The same API handles stocks, crypto, perps, options, and prediction markets, so you do not need to learn different authentication schemes for each venue. You simply specify the market type in the request, and the API handles the venue-specific details.

The exact request schema is in the docs; the shape looks like this.

curl -X POST "https://api.felix.trade/..." \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "market": "crypto",
    "side": "buy",
    "usd_amount": "250.00",
    "symbol": "EXAMPLE"
  }'

This example shows the idea of sending a plain dollar amount and a market type. The actual fields and endpoints are documented at /docs, and you should verify the current schema there before writing any production logic. Whether you use MCP or REST, the pattern is the same: the agent generates a signal, the tool validates it against your scoped limits, and the order reaches the venue only if it passes. This validation layer is what keeps the agent from exceeding your budget even if the prompt is ambiguous. For a deeper guide on safe execution, see how to run an AI trading agent with real money, safely.

How do you test without risking money?

Felix offers paper trading for exactly this purpose. Create a paper key, attach your agent, and let it run against live market data without committing real capital. Run the paper session for days or weeks, depending on your strategy frequency. A daily strategy needs at least several weeks across different market conditions to reveal flaws. An hourly strategy needs less calendar time but more trade samples. During paper testing, treat the agent as if it were live. Review every trade and ask why it happened. If the logic does not match your written specification, fix the prompt or the code before proceeding. Paper trading is not a guarantee of future results, but it is a filter for obvious errors.

Use paper trading to test your safety controls. Trigger the panic switch intentionally and verify that positions flatten and the key is revoked. Test what happens when the agent receives stale data. Suppose the price feed lags by thirty seconds. Does the agent still try to trade, or does it check for freshness? Build these checks into your logic. After paper trading succeeds, move to live trading with the smallest possible budget cap. Live trading requires explicit owner authorization of the key. This extra step prevents accidental deployment. Even with authorization, start with a few hundred dollars at most and watch every order. Increase size only after the agent behaves predictably under real slippage and latency.

What should you check before going live?

Before you authorize a live key, audit every guardrail. Confirm that the scoped key cannot withdraw funds. Attempt a withdrawal to an unapproved address and verify that it is rejected. Check that the kill switch actually flattens positions across all five market types you might be using. Review your exit plan one more time. Every open position should have a stop loss, a take profit, or a time based exit rule active. If the agent is supposed to manage exits dynamically, verify that it cannot cancel a stop loss to avoid realizing a loss. Stops should be hard orders, not soft suggestions. Dynamic management is fine for taking profits, but the worst-case exit should be immutable once the trade is open.

Start with minimal capital and manually review the first trades. Compare the live behavior to the paper trading logs. If the agent acts differently, stop immediately and investigate. Sometimes latency or slippage changes the outcome, but sometimes the agent is interpreting the live environment in an unexpected way. Keep a decision log. For each trade, record what the agent saw and why it acted. This log is invaluable for debugging and for refining your prompts. Finally, schedule a regular review of your guardrails. What was safe at one account size may not be safe at another. You can learn more about auditing in how to audit your trading agent guardrails before going live.