Building your first agentic trading system

Building an agentic trading system means giving an AI agent limited access to trade real money across multiple market types while you keep full custody of the funds. You define the strategy, the budget, the position limits, and the kill switch. The agent receives a scoped key that can place orders but cannot withdraw funds or change permissions. This walkthrough shows how to move from an idea to a live agent without ever giving up control of your wallet.

What do you need before you start?

You need a clear strategy, a wallet you control, and a budget you are willing to lose. The strategy does not need to be complex, but it must be specific enough that you can write it as a set of rules or prompts. Felix routes orders across stocks, crypto, perpetual futures, options, and prediction markets through a single API, so you do not need separate accounts for each venue. Your wallet holds the funds, and the API key you create will be scoped to trade only, not to withdraw.

• ·A wallet you control where funds will remain at all times
• ·A written strategy with explicit entry, sizing, and exit rules
• ·Predefined risk numbers including maximum daily loss and position size in US dollars
• ·A decision on which markets to trade (stocks, crypto, perps, options, or prediction markets)
• ·A runtime environment such as an AI editor with MCP, a local server, or a background service

You should also decide on your risk tolerance and maximum exposure before you write any code. An agentic system is only as safe as the limits you set around it. Write down your maximum daily loss, your maximum position size in US dollars, and the conditions under which the agent must stop. These numbers will become the hard limits you attach to the API key later. It is easier to set conservative bounds now than to adjust them while the agent is running. Think of these limits as the final authority, not suggestions. The agent may reason about risk, but the API will enforce the boundary regardless of what the model decides.

Finally, prepare your environment. You will need a place to run the agent, whether that is an AI code editor with MCP support, a local server, or a cloud function. You will also need access to the docs to confirm the current request schemas and error codes. Having a plan for logging and monitoring is essential. You cannot supervise an agent if you cannot see what it is doing. Set up a simple log stream or webhook receiver before you go live so you have a record of every decision and every order.

How do you design a strategy and safety rules?

The strategy is the reasoning layer. The safety rules are the execution guardrails. You should separate them so that the LLM decides what to trade, while the API enforces what it cannot do. For example, the agent might prompt the model to rebalance a portfolio when allocation drifts beyond a threshold, but the API key itself carries a hard cap that rejects any order exceeding your preset position size. This split means a prompt injection or model hallucination cannot bypass your financial boundaries because the API refuses the transaction before it reaches a venue. The model may suggest a trade, but the infrastructure decides whether that trade is allowed.

You can express the strategy as a natural language prompt, a state machine, or a combination of both. A simple prompt might instruct the agent to scan for momentum signals and enter positions sized in US dollars, while a state machine handles scheduled rebalancing or stop losses. Whatever you choose, keep the logic deterministic enough that you can audit it. If the agent’s reasoning is too vague, you will not be able to tell whether a bad trade came from the model, the data, or a bug in your own code. Clarity in the prompt reduces debugging time later.

Safety rules belong in both the prompt and the infrastructure. In the prompt, tell the agent to respect the budget and to check prices before sizing. In the infrastructure, attach scoped keys, budget caps, and a kill switch. The infrastructure layer does not trust the agent. It validates every order against the limits you configured when you created the key. How the safety model behind LLM trading works covers the mechanics of this layer in depth. You should read it before you set your first hard limit.

One common mistake is to rely on the LLM alone to manage risk. Models can be persuasive and confident even when they are wrong. A safety rule embedded in a prompt is a request. A safety rule embedded in the API key is a physical barrier. Build both, but trust the barrier. When the two conflict, the barrier wins. That is the correct design.

How does the agent connect to markets?

Agents connect through MCP tools or directly through the REST API. MCP is useful when you want the agent to run inside an AI code editor or a chat interface that already supports tool calling. The REST API is useful when you want to run the agent as a background service on your own server. Both paths use the same scoped key, and both normalize order sizing in plain US dollars so you do not need to manage contract multipliers or decimal precision for each venue. The trading API built for AI agents handles routing and normalization across market types.

When you create a key, you choose which markets it can access, the total budget it can deploy, the maximum size of any single position, and the approved withdrawal addresses. The agent can spend within the budget but cannot withdraw to itself or to any address you have not pre-approved. This is the non-custodial guarantee. Funds stay in your wallet. The agent only has permission to place orders. If the agent is compromised or the host machine is breached, the attacker can only trade within the limits, not steal the wallet.

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

curl -X POST https://api.felix.trade/v1/order \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "market": "crypto",
    "side": "buy",
    "size_usd": 250,
    "symbol": "ETH-USD"
  }'

After the agent sends an order, the API translates the US dollar size into the contract terms required by the underlying venue. You do not need to know the lot size, tick size, or margin formula for each market. The API returns a unified status so your agent can reason about fills, rejections, or errors with a single data model. This abstraction matters because it lets you change the underlying venue or market mix without rewriting your agent.

Connection reliability is part of the safety story. If the agent loses its connection to the API, it should stop trading, not guess. Design your agent to fail closed. If a heartbeat or status check fails, pause and alert. Do not let the agent retry blindly in a loop, because market conditions may have changed while the connection was down. A silent failure is safer than an unmonitored retry.

How do you test without risking real money?

Paper trading lets you run the full agent loop against live market data without committing real capital. You create a paper key, attach the same strategy prompts and safety limits you plan to use in production, and watch how the agent behaves. This is the point where you discover whether your prompt is ambiguous, whether your sizing logic is correct, and whether the agent respects the kill switch. Expect to find errors. It is better to find them in paper mode than after you authorize a live key. Paper trading uses the same data feeds and the same API responses, so the behavior you see is representative.

Use the testing phase to calibrate your budget caps and position limits. If the agent consistently tries to place orders larger than you intended, tighten the key-level size limit rather than rewriting the prompt. If the agent trades too frequently, add a cooldown rule or a maximum order count per hour. The goal is to make the safety layer so reliable that you can trust the agent to run unattended. Paper trading is also a good time to practice using the panic switch. Trigger it manually, verify that the agent flattens positions and that the key is revoked, then reissue a new key and resume testing. Repeat this until you are confident the switch works.

Keep a log of every paper trade and every decision the agent made. Review the log to see if the agent’s reasoning matches your intent. If the LLM justifies a trade with logic that sounds convincing but contradicts your rules, you have a prompt clarity issue, not a market problem. Fix the prompt and test again. Only move to live trading when the behavior is predictable and the safety limits have been triggered correctly at least once. How to run your first trading agent from an AI code editor includes a sample workflow for this testing phase.

Testing should also include edge cases. Suppose the market moves sharply against a position. Does the agent try to average down? Does it hit a daily loss limit? Does it send multiple orders in panic? Simulate these scenarios by reviewing historical volatile periods or by manually injecting extreme prices into your test data if your setup allows it. The agent should handle stress by stopping, not by accelerating. If it does not, your limits are too loose or your prompt is missing a clear emergency instruction.

How do you go live and stay safe?

Live trading requires explicit owner authorization of a live key. The system will not let an agent spend real money with a paper key, and it will not let a paper key graduate to live status automatically. You must create a new key, set the live budget, confirm the withdrawal addresses, and explicitly enable it. This friction is intentional. It ensures you have reviewed the limits one more time before capital is at risk. There is no shortcut.

Once live, start with a small budget. The agent should prove itself under real slippage, real latency, and real fill uncertainty before you scale up. Monitor the first trades closely. Check that the US dollar sizing matches your intent and that the API is enforcing the caps. If the agent breaches a limit, the API rejects the order and logs the reason. You can review these logs to adjust the prompt or the limits. Remember that trading can lose money, including everything, so the initial budget should be an amount you can afford to lose entirely.

Keep the kill switch accessible. The panic button flattens positions and revokes the key immediately. It exists because no agent is perfect. Markets can gap, models can hallucinate, and code can contain edge cases. If you ever feel uncertain, use the switch. You can always create a new key and restart. The funds remain in your wallet throughout. How to take an AI trading agent live in 2026 offers a longer checklist for this transition.

As the agent runs, schedule regular reviews. Read the logs, compare the agent’s decisions against your original strategy, and adjust the limits if your risk tolerance changes. Do not increase the budget just because the agent has performed well for a few days. Good short-term results can be luck. Increase capital only after you have verified that the safety layer, the prompt, and the market logic are all working together consistently. Patience is a safety feature.