How to take an AI trading agent live with real money

Taking an AI trading agent live with real money means connecting a scoped API key to live markets so the agent can execute trades that clear and settle against your capital. The process is not a single toggle but a sequence of configuration, testing, authorization, and monitoring steps. You remain the custodian of your funds throughout, because the agent can trade within limits you define but cannot withdraw to an external address or move capital outside your control. Trading can lose money, including everything, so each step exists to surface risk before it compounds into losses you cannot accept.

What does going live actually mean?

Going live is the transition from simulated orders to orders that execute against real order books and update your balances. In paper trading, the agent practices the full lifecycle of an order, including submission, rejection handling, and position tracking, but no transfer of value occurs. Live trading introduces slippage, partial fills, funding rates on perps venues, and exercise mechanics at options venues. The agent must also handle real market latency and the possibility that a venue is down for maintenance while a signal is generated. Felix normalizes these differences behind a single API, sizing orders in plain US dollars and translating the math for each underlying venue. You still need to understand what the agent is doing, because the API does not eliminate market risk, it only standardizes the interface to it. When you go live, the emotional component also changes. Paper losses are abstract, but live losses are concrete. This psychological shift can cause you to intervene too often or freeze and fail to use the kill switch. Define your intervention rules in advance. Decide whether you will stop the agent after a single day of losses, after a percentage drawdown, or only after a technical failure. Writing these rules down before authorization removes the ambiguity that leads to hesitation. Live trading also means the agent must handle real settlement times. A stock trade settles on a different schedule than a crypto spot trade or a perpetual futures position. The agent should not assume instant availability of proceeds for the next trade unless the API explicitly reports settled buying power.

How do you prepare the agent in paper trading?

Paper trading is the proving ground where you verify that the agent does what you intend before it touches real capital. Run the agent through multiple market conditions, including sideways price action and periods of higher volatility, so you can see how it sizes positions and whether it respects the constraints you set. Watch for off-by-one errors in loop logic, confusion between base and quote currency units, and mishandling of order rejections. Suppose the agent sends a buy order for a stock and receives a rejection because the market is halted; the agent should log the event, retry within reason, or wait for the next signal rather than crash or spam duplicates. Check that the position tracking in your logic matches the reported positions from the API. If the agent thinks it is flat but the API shows an open perp position, the next signal could double your exposure unintentionally. You should also test the agent's response to your exit plan. If you configured automated take profits and stop losses, verify in paper trading that the agent attaches these orders correctly and that they trigger when the price reaches the threshold. Imagine a scenario where the agent enters a long position but fails to place the stop loss because of a conditional logic bug. In paper trading, this bug costs nothing. In live trading, it could cost the full position. Test the kill switch during paper trading. Trigger a manual flatten and revocation, then observe whether the agent stops gracefully or attempts to reconnect and reopen positions. This drill confirms that your safety infrastructure works before you need it under stress. Only after the agent behaves consistently across days or weeks of paper trading, and only after you have observed it handle errors and recoveries, should you consider live deployment.

What safety controls should you set before the first real dollar?

Safety controls are the boundary between an experiment and a live system that can damage your capital. Every control you skip is a hole that lets the agent behave in ways you did not intend. Configure the following before you authorize the first real dollar:

• ·A scoped API key that limits the agent to the specific markets and actions it needs. If the agent is designed to trade prediction markets and stocks, do not grant it permissions for options or perps. The principle of least privilege applies directly to trading infrastructure. A scoped key ensures that if the agent's logic goes wrong, or if the LLM hosting environment is compromised, the blast radius is limited to the markets you chose.
• ·A budget cap that defines the maximum notional value the agent can deploy in a given period, such as a single day or week. This cap should be an amount you are genuinely willing to lose, because trading can lose money, including everything. Consider starting with a cap that represents a small fraction of your total capital.
• ·Position limits so no single trade can exceed a fixed dollar size, and a total exposure limit so the agent cannot accumulate a concentrated book across multiple correlated positions. For example, if the agent trades both a prediction market and a related stock, the combined risk should not exceed your total exposure limit.
• ·An exit plan that automates stop losses and take profits. You should build an exit plan so the agent does not hold losing positions indefinitely while you are away. The exit plan should be part of the order construction, not an afterthought. Test that the exit orders actually attach to the entry in paper trading before you rely on them live.
• ·A panic or kill switch that flattens all positions and revokes the key. This is not a sign of pessimism; it is a standard circuit breaker. You should know how to trigger it without looking up documentation.

The practical checklist for non-custodial MCP setups covers these steps in more detail. Remember that withdrawal addresses are owner-approved only, so even if the agent is compromised, it cannot send funds to itself. Review the audit log settings before going live. You want a complete record of every request, response, and position change so that if something goes wrong, you can reconstruct the sequence without guessing.

How do you authorize the key for live trading?

Authorization is the deliberate step where you convert a paper trading key into a live trading key. In Felix, this requires explicit owner approval; the agent cannot escalate its own permissions. Before you approve, review the scope one more time. Confirm the budget cap, the allowed markets, and the maximum position size. If you connect through MCP from Claude or another client, verify that the tool definitions the model sees match the scoped permissions. You can run a trading agent from Claude using these same constraints, but the model is only as safe as the boundaries you give it. After authorization, send a single small test order to confirm the pipeline. Do not let the agent run unsupervised on the first day. Watch the first order from submission to fill to position update. If the test order behaves as expected, you can allow the agent to continue, but keep the initial capital small. You can increase the budget cap later if the system proves stable. Authorization is reversible in the sense that you can revoke the key, but you cannot un-fill a live trade. Treat the moment of authorization as the point where preparation ends and risk management begins.

The exact request schema is in the docs; the shape looks like this when submitting an order via the REST API. You would send a payload that includes the market identifier, the side, the notional amount in US dollars, and any trigger conditions for your exit plan. The response will contain an order identifier and a status field indicating whether the order is open, filled, or rejected.

{
  "market": "example-market",
  "side": "buy",
  "notional_amount": 100,
  "take_profit": 110,
  "stop_loss": 95
}

What should you monitor after the first order?

The first live order is a test of the entire pipeline, not just the strategy. Monitor the audit log for the exact request the agent sent, the venue response, and the fill details. Compare the intended notional in US dollars with the actual executed notional, because slippage or minimum size rules can cause deviations. A request to buy one hundred dollars worth of an asset might fill at ninety-eight or one hundred two dollars depending on the order book. The agent should handle this variance without breaking its position tracking. Track the budget cap burn rate from the first hour. If the agent is supposed to trade slowly but burns ten percent of its weekly budget in the first morning, either the logic is too aggressive or the cap is misconfigured. Watch for repeated error patterns, such as multiple rejected orders for the same reason. A rejection because of insufficient margin at a perps venue is different from a rejection because of invalid symbol formatting, but both indicate a mismatch between your assumptions and reality. In the first case, you may need to post more collateral or reduce leverage. In the second case, you may need to fix the market identifier mapping in your code. Check that the agent is actually following the exit plan. If you set automated stop losses and take profits, verify that the agent placed the associated orders and that they are still open in the market. Some agents place the entry order successfully but fail to attach the exit orders due to a race condition or a logic branch that only executes on paper. Monitor the connection health if you use MCP. A dropped connection might cause the agent to miss a signal or duplicate an order when it reconnects. The first few days of live trading are primarily about validating infrastructure, not about maximizing returns.

When should you stop or revise the agent?

You should stop the agent when it hits a predefined boundary, not when you feel nervous. If the drawdown reaches the limit you set during preparation, invoke the kill switch, flatten positions, and revoke the key. This is a planned termination, not a failure. You should also stop if the agent exhibits a systematic error, such as buying every time a specific MCP tool is called because the prompt parsing is flawed. If the market regime changes and your strategy has no edge in the new environment, the safest move is to stop and return to paper trading. The kill switches article explains how flattening and revocation work from first principles. After stopping, diagnose the issue in paper trading, adjust the prompts or the code, and only then generate a new scoped key if you choose to continue. Trading can lose money, including everything, and stopping early is often the cheapest form of risk management. Do not fall into the trap of letting the agent run because you hope it will recover. A strategy that is broken or misaligned with current conditions tends to compound losses faster than it compounds gains. Revise the agent based on evidence from the logs, not from optimism. When you restart, treat it as a new launch: small test order, close monitoring, and gradual expansion of capital only after stability is confirmed.