A practical checklist for running autonomous trading systems with real money

An autonomous trading system with real money requires more than a profitable strategy. It needs enforceable spending limits, non-custodial access, a clear exit plan, and a mechanism to revoke permissions instantly. Without these safeguards, the agent is simply an automated script that can lose funds faster than a human can react. This checklist covers the components that keep agentic trading safe, inspectable, and bounded by hard constraints rather than good intentions.

What should every autonomous trading checklist include?

A checklist for autonomous trading is not a list of desired features. It is a set of constraints that must remain true at all times. The first constraint is capital preservation. The second is scope enforcement. The third is recoverability. Capital preservation means the agent cannot spend more than a predefined amount, even if its internal logic demands larger size. Scope enforcement means the agent is allowed to trade only specific market types, such as stocks, crypto, perps, options, or prediction markets, and only within defined position limits. Recoverability means the owner can flatten all positions and revoke the agent's access without needing the agent's cooperation. Many builders focus on signal generation and neglect these boundaries. That is a mistake. A signal without a boundary is merely an opinion attached to an API key. You should treat the checklist as a contract between you and the agent. If the agent violates any item, the system must halt. This is not about optimization. It is about survival. Before you deploy, write down the maximum dollar loss you are willing to accept in a single day, a single week, and a single month. Write down the maximum position size per instrument and the total gross exposure across all markets. Define which markets are in scope and which are permanently out of scope. Decide who can alter these parameters and under what conditions. If you cannot answer these questions in plain language, you are not ready to authorize live trading. The checklist is not a technical specification for the agent alone. It is a human readable agreement that the system enforces automatically. For example, suppose you allocate five thousand dollars to a new agent. The checklist should state that the agent cannot exceed that allocation, cannot open more than three concurrent positions, and cannot trade outside of regular equity market hours. These are not suggestions. They are hard limits encoded into the API keys and budget caps. Many people assume that a large language model will respect implicit boundaries because it sounds reasonable during a chat session. That assumption is dangerous, and it is one of the things what most people get wrong about LLM trading with real money.

How do you keep an agent within its budget?

Budget caps and scoped keys are the primary tools for enforcement. A scoped key carries permissions that describe exactly what the agent can do and how much it can spend. The owner sets these parameters before the key is created, and the infrastructure enforces them at the API level. This means the agent cannot override its own budget by asking for more capacity or by generating a new rationale. The limit is external and cryptographic. You should also set position limits that cap the notional size of any single trade. Because orders are sized in plain US dollars, you do not need to translate contract multipliers, lot sizes, or margin formulas in your own code. The API normalizes venue-specific contract math. This reduces the chance of a size miscalculation that leads to unintended leverage or notional exposure. Suppose you set a per-position limit of one thousand dollars. Even if the agent sends an order for two thousand dollars, the system rejects it. The rejection happens before the order reaches a venue. This is a hard boundary, not a prompt suggestion. In addition to per-trade limits, you should set a daily or weekly drawdown limit. If the account loses a defined percentage of its allocated budget, the system should pause and require manual reauthorization before it can trade again. This prevents a losing strategy from compounding errors through automated repetition. You should review whether the agent has access to withdrawal functions. In a non-custodial system, it should not. The agent can trade within the scoped permissions, but it cannot move funds off the account to an external address that you have not pre-approved. This separation is critical. If the agent could withdraw, a single compromised key or a single hallucinated action could result in a total loss. Scoped keys eliminate that path by construction.

How do you design a safe exit plan?

An exit plan is not a vague intention to sell if things go badly. It is an automated set of instructions that fire when specific conditions are met. Every autonomous system should define its exit criteria before it enters any position. These criteria include a stop level, a time limit, and a target. The stop level limits the loss on a single position. The time limit prevents the agent from holding a position indefinitely while waiting for a thesis that may never resolve. The target defines when to take profit so that the agent does not give back gains while waiting for perfection. You should encode these rules into the agent's behavior and into the API constraints, not just into its prompt. A prompt is text that can be misinterpreted or ignored under pressure. A rule enforced by the API is a structural constraint. The combination of both is stronger than either alone. For example, imagine an agent that buys a stock with a plan to hold until a price target is reached. If the target is reached, the agent should exit. If the price drops ten percent, the agent should exit. If three days pass without either event, the agent should exit. These three rules remove discretion and emotion from the decision. The agent does not debate the exit. It executes. You can build your first automated exit plan using the framework described in How to build your first automated exit plan and take-profit strategy. The key is to make the plan automatic and irreversible from the agent's perspective. Once the trigger fires, the order is sent. There is no second thought. You should also test the exit plan in paper trading. Verify that the agent actually submits the exit order when the condition is hit, and verify that the exit order is sized correctly. An exit plan that exists only in the prompt but not in the executed behavior is the same as having no exit plan at all.

How does non-custodial access reduce systemic risk?

Non-custodial design means that funds remain in a wallet that the owner controls. The agent receives an API key that lets it trade within defined limits, but it cannot withdraw funds to itself or to any address that the owner has not explicitly approved. This changes the risk model significantly. In a custodial setup, you must trust that the operator of the infrastructure will not misuse pooled funds or freeze access. In a non-custodial setup, the infrastructure never holds your assets. The worst case is not a total loss of the wallet; it is a loss limited to the trading budget you intentionally exposed. Even if the agent behaves erratically or its logic is compromised, it cannot drain the underlying account. It can only lose what it is allowed to trade. This is why withdrawal addresses are owner-approved only. You should verify this property before you attach real money. If the system allows the agent to change withdrawal addresses or to move funds off the trading account without manual owner approval, it is not truly non-custodial. You can read more about this architecture in How AI agents trade across markets without taking custody of your funds. The boundary between trading capital and long-term savings capital should be physical and cryptographic, not just conceptual. By keeping the majority of your funds in a wallet that the agent cannot touch, you ensure that a trading mistake does not become a life-altering loss. This is not a feature to be grateful for after the fact. It is a prerequisite to deploying any autonomous system with real money.

How do you test and connect an agent before going live?

Paper trading is the correct environment for early testing. It lets you verify that the agent interprets signals correctly, sizes orders as intended, and respects the scoped key boundaries without risking capital. You should run paper trading for long enough to observe multiple market conditions, including normal volatility, gaps, and after-hours behavior if your strategy covers those periods. A single day of paper profits is not validation. You are looking for behavioral correctness, not luck. During this phase, test the kill switch. Trigger a revocation manually and confirm that the agent loses access immediately and that any open positions can be flattened. Test the drawdown limit by simulating a losing streak or by inspecting the system's response when a paper budget is exhausted. Verify that the system halts when the budget cap is reached. Once behavior is correct, you can authorize live trading. This authorization should be explicit and conscious. The owner must deliberately approve the key for live use. There is no automatic graduation from paper to live. The exact request schema is in the docs; the shape looks like this:

curl -X POST https://api.felix.trade/v1/orders \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{\n    "market": "example-market",\n    "side": "buy",\n    "notional_usd": 100,\n    "dry_run": true\n  }'

Agents connect through MCP tools (Claude, Cursor, and other MCP clients) or the REST API. If you are using an MCP client, the tool definitions handle the mapping between the agent's intent and the API. You should still verify that the budget and scope parameters are active in the tool configuration. Do not assume that the MCP layer inherits limits automatically. Check the parameters explicitly. After you authorize live trading, start with a small budget. The goal of the first live session is to confirm that real order routing, latency, and slippage match your expectations. You are not trying to generate returns on day one. You are trying to prove that the system behaves as it did in paper mode. Trading can lose money, including everything, so the initial live budget should be an amount you are prepared to lose entirely without changing your financial position.

What do you do when the system diverges from its plan?

Every autonomous system will eventually encounter a scenario that its designer did not anticipate. The question is not if this happens, but whether you have a mechanism to contain the damage. The panic or kill switch is that mechanism. It should flatten positions, cancel open orders, and revoke the agent's key. You should be able to trigger it manually, and you should consider whether to automate it based on health checks. For example, if the agent has not sent a heartbeat in a defined interval, the system could assume a failure and halt. You should also maintain audit logs that record every order, every rejection, and every permission change. These logs are not for debugging alone. They are for accountability. If the agent acts outside its scope, the log proves what happened and when. Review the logs regularly, not just after a loss. Patterns of near-miss rejections can reveal that the agent is repeatedly bumping against its limits, which may indicate a logic error or a prompt that is too vague. Some of the most common failures come from misconfigured scopes or prompts that do not map cleanly to API constraints. You can avoid many of these by reviewing Common mistakes running Claude trading agents with self custody. When something goes wrong, the checklist is your recovery guide. Follow it in order: halt, assess, flatten, revoke, then debug. Do not debug while the agent is still trading. The temptation to let it run while you investigate is strong, especially if the position is currently profitable. Resist it. A divergent system is a dangerous system. Stop it first. Ask questions later. Trading can lose money, including everything, and a running agent that has left its plan is simply a faster way to reach that outcome.