How to set up your first autonomous trading system

An autonomous trading system is software that decides when to enter and exit positions on your behalf. Before you let it handle real money, you need a clear checklist that defines what it can trade, how much it can lose, and how you can stop it. Starting with these controls in place protects your capital and lets you evaluate the system calmly.

What is an autonomous trading system?

An autonomous trading system, often called an agent, is a program that evaluates market data and places orders without requiring you to confirm each individual trade. It is not a simple alert service that sends you a text message when a price looks interesting. It is a closed loop that reads prices, runs a strategy, and submits buy or sell instructions directly to a market venue. This means it can act faster than a human, but it can also make mistakes faster if the strategy or the infrastructure is flawed. With Felix, the agent connects through one API and one key to trade across stocks, crypto, perpetual futures, options, and prediction markets. Despite this broad access, the system remains non-custodial. Your funds sit in a wallet you control, and the agent can only spend within the budget and position limits you set. It cannot withdraw funds to itself, and it cannot send money to any address that you have not explicitly approved. This architecture matters because trading can lose money, including the entire amount you allocate, and an autonomous system does not get tired, emotional, or distracted. It will keep executing its logic exactly as written until you stop it or a hard limit stops it for you. Understanding this distinction between speed and control is the first step in building something safe. An agent is not a replacement for judgment. It is a tool that magnifies both discipline and errors.

What should you define before your agent sees a market?

Before you write any code or generate an API key, write down the rules in plain language. The following constraints should be treated as hard infrastructure limits, not polite suggestions.

• ·Set a total budget cap in US dollars. This is the maximum amount the agent is allowed to have deployed across all positions at any given moment. It is not a target. It is a ceiling.
• ·Define the market scope. Decide exactly which market types the agent may access. A strategy tested on a perps venue may fail on a stock broker due to different margin rules, trading hours, or settlement mechanics.
• ·Set a per trade position limit. This prevents a single order from consuming the entire budget during a moment of faulty logic.
• ·Define the exit plan. Specify under what conditions the agent must close a position, including stop rules, take profit levels, and time based exits.
• ·Write down the kill switch criteria. Decide what drawdown percentage or anomalous behavior triggers an immediate halt.
• ·Plan for manual overrides. Know exactly how you will pause the agent without needing to reboot a server or edit configuration files.

You should also define how many positions the agent can hold at once. Holding twenty correlated positions is not diversification. It is leverage. Write down the maximum number of open positions and the maximum exposure to any single sector or asset class. Define the trading schedule. An agent that is supposed to trade only during equity market hours should not be sending orders at midnight to a stock broker. Define the data source. If the agent reads from a specific feed, what happens when that feed lags or goes stale? Imagine a simple rule that halts trading if data is older than five minutes. That single rule can prevent bad trades. Define how the agent handles cash. Does it hold cash between signals, or does it stay fully invested? Define the rebalancing frequency if it manages multiple positions. All of these rules should be written in a document you can review, not buried in code comments. If you are starting with a small amount of capital, the same principles apply, but the margin for error is tighter and the impact of fees is larger. See how to manage risk before your first automated trade for a deeper look at planning before your first automated trade.

How do you test without risking real money?

Every autonomous system should spend meaningful time in paper trading mode before it touches live capital. Paper trading simulates the full order lifecycle, including fills, rejections, partial executions, and fee accrual, without moving real money. Use this phase to test more than just the strategy logic. Test the integration. Verify that the agent correctly handles API errors, network timeouts, and stale market data. Simulate what happens when a stock broker is closed for the day or when a prediction market resolves. Test the budget cap enforcement by intentionally trying to exceed the limit. Test the position limit by submitting an order that is too large. Observe whether the infrastructure rejects it or whether the agent relies on its own internal math, which could be buggy. Test the kill switch while positions are open. The switch should flatten everything and revoke access. Run the agent for multiple days to catch memory leaks, clock drift, or slow budget leaks caused by fees or rounding. Keep a journal of every unexpected behavior. Paper trading should also account for fees. Many strategies look profitable until you subtract trading costs. Even if the paper mode does not charge real fees, calculate them manually and subtract from the virtual P&L. If the strategy is barely green without fees, it will be red in live trading. Test the reconnection logic. If the API drops for thirty seconds, does the agent resume safely or does it duplicate orders? Test the shutdown sequence. If you stop the program mid-trade, does it leave orphaned orders on the book? Orphaned limit orders can fill hours later when you are no longer watching. A clean shutdown procedure is part of the checklist. If the agent breaks a hard limit during paper trading, treat it as a critical bug. Fix it before you authorize live keys. A paper environment is only realistic if the hard limits are active and the latency is similar to live. See how to paper trade an AI agent with hard limits it cannot cross for guidance on setting up a proper test environment.

What safety controls must be in place before live trading?

Live trading requires explicit owner authorization of the API key, and that key should be scoped to the minimum permissions required. If the agent only needs to place and cancel orders, the key should not have withdrawal rights. Budget caps and drawdown limits should be enforced by the trading infrastructure, not by the agent's internal logic, because the agent could be compromised, buggy, or operating on hallucinated data. Position limits prevent a single oversized trade from wiping out the budget. Approved withdrawal addresses should be configured by you and locked so the agent can never send funds to an unapproved destination. A panic switch, or kill switch, must be tested and reachable without relying on the agent itself. It should flatten all positions and revoke the agent's access in seconds. Drawdown limits deserve special attention. Suppose you set a daily drawdown limit of two percent. That might seem conservative, but it prevents a single bad day from destroying weeks of capital. The exit plan should also include what happens when the agent cannot exit. Suppose the agent holds an option that becomes illiquid. Does it hold to expiration, exercise, or attempt a market order that fills at a terrible price? The exit plan should address liquidity. The panic switch should be tested under load. If the agent has ten open positions across five venues, can the switch close them all? You do not want to discover that it only handles one venue at a time when you are in a crisis. These controls are structural. They do not depend on the agent behaving correctly. They exist precisely for the case when the agent does not behave correctly. Audit logs and observability are also essential. You need a record of every order, every API call, and every limit check. See why AI agents need scoped API keys when trading real money for a breakdown of key permissions. See how to set up audit logs and observability for trading agents with hard limits for monitoring recommendations.

How do you connect the agent to markets safely?

Felix exposes one API and one key that normalizes access to five market types. You can connect through MCP tools in AI editors such as Claude or Cursor, or through the REST API directly if you are running a headless program. The API translates plain US dollar amounts into venue specific contract math. This means the agent sends an order for one hundred dollars, and the infrastructure handles the conversion to shares, contracts, or lots. The agent does not need to manage tick sizes, margin multipliers, or notional value calculations. This removes a common source of errors for beginners who might otherwise confuse contract size with notional exposure. It also prevents mistakes where an agent submits an order in base units instead of quote units, a bug that can cost a beginner their budget in a single click. The exact request schema is in the docs; the shape looks like this.

{
  "symbol": "EXAMPLE_USD",
  "side": "buy",
  "dollar_amount": 100,
  "api_key": "YOUR_KEY"
}

Because the system is non-custodial, the agent sends orders from a wallet you control. It can spend the budget you allow, but it can never withdraw funds to itself. Before you move from paper to live, authorize the key explicitly and double check that the approved withdrawal addresses are still correct. If you are using MCP tools, remember that the AI assistant is generating the trade logic, but the hard limits are enforced by the infrastructure beneath it. The assistant cannot bypass the budget cap or the position limit even if its reasoning changes during the session. This separation of logic and enforcement is what makes the system safe for beginners. You are not relying on the AI to be cautious. You are relying on the infrastructure to enforce caution.

What should you monitor after the first trade?

Going live is not the end of the checklist. It is the beginning of a continuous monitoring routine. Review audit logs daily to confirm the agent is placing the trades it claims to be placing. Watch the budget burn rate to ensure the cap is not drifting upward due to fees, partial fills, or rounding errors. Check for failed orders, stale market data, and unexpected positions that do not match the strategy. If the agent trades across multiple market types, verify that the routing and dollar sizing are behaving correctly for each venue. A stock broker and a perps venue have different settlement and margin mechanics, and the API should normalize these, but you should verify it. Compare the live execution to the paper trading results. If the live fills are consistently worse, investigate slippage and latency. Check whether the agent is accidentally front running its own orders. Review the API call logs for retry loops. A retry loop that does not check for prior fills can double or triple the intended position. Monitor the wallet balance independently. Do not trust the agent's internal accounting. Reconcile the onchain statements against the agent's reported trades. Discrepancies mean bugs or unauthorized access. Test the kill switch again in the live environment to confirm it still flattens positions and revokes access within the expected time. Monitor for concentration risk. An agent that is supposed to hold five small positions might slowly drift into one large bet if its logic contains a subtle bug or if it interprets correlated assets as independent opportunities. Review the scoped key permissions and approved withdrawal addresses weekly. Automation does not remove risk. Markets can move against you, and software can behave in ways you did not anticipate during design. You should be prepared to lose the entire budget you allocated, which is why the budget cap exists. The checklist is not a guarantee of profit. It is a framework for controlled experimentation that keeps losses bounded.