How to automate exit plans and take profits while keeping custody

Automated exit plans and take-profit rules let an agent close positions or lock in gains without the agent ever holding your funds. Because Felix is non-custodial by construction, your money stays in a wallet you control, the agent can only trade within scoped limits, and withdrawal addresses require your explicit approval. The API normalizes order sizing in plain US dollars, so an agent can express a stop or a target in familiar terms while the infrastructure enforces the boundary between trading and custody. This does not remove trading risk, but it does remove the risk that the agent itself can steal the funds.

What does non-custodial exit automation actually mean?

In many automated trading setups, you must deposit funds into an account controlled by a bot, a third party, or an exchange API key that permits withdrawals. That is custody. It means the operator can move your money elsewhere, and your exit orders are only as safe as their infrastructure. Felix takes a different approach. The wallet is yours. The wallet can be a standard externally owned account or a smart contract wallet, but in either case the owner retains the final signing authority over withdrawals. The agent receives a scoped key that can place trades and close positions, but it cannot withdraw to an external address unless you have explicitly approved that address in advance. The agent can spend within limits, but it can never take the money for itself. Exit automation under this model means the agent is authorized to send orders that reduce or close your positions when certain conditions are met. A take-profit rule might say: if the unrealized gain on a position exceeds a dollar amount you defined, submit a reducing order. A stop-loss rule might say: if the unrealized loss crosses a threshold, submit a flattening order. When the order fills, the proceeds settle back into your wallet. The agent facilitated the exit, but it never held the underlying capital. The infrastructure sits between the agent and the venue, normalizing the order so the agent does not need to learn venue-specific contract math, margin formulas, or settlement procedures. This distinction matters because an exit plan is only as trustworthy as the system that enforces it. If the same entity that places trades also controls the wallet, then an exit is merely a request that the custodian may or may not honor. In a non-custodial model, the exit order is a direct instruction to the market, and the proceeds return to an address only you control. This separation of trading authority from custody is the core of the safety model.

How do take-profit and stop-loss rules work without giving up custody?

The agent monitors market data and its own position state through the API. When a condition triggers, it builds an order in plain US dollars. For example, it might request to close a specific dollar amount of a perp position, or sell a specific dollar amount of a stock position, or reduce exposure in an options position by a dollar value. Partial exits are supported in the same way. The agent can request to close half of a position by dollar value, and the API will compute the correct unit size for the remaining exposure. The API translates that into the correct size for the specific venue, handling lot sizes, tick sizes, contract multipliers, and minimum notional values internally. The order is then sent to the venue. If it fills, the resulting cash or collateral remains in your wallet. This works because the API is the only path the agent has to the market. It cannot log into a venue directly, create a sub-account, or redirect settlement to a different wallet. The scoped key is bound to your wallet and your budget. Even if the agent decides to ignore its own take-profit prompt and hold a winner too long, the position limit and budget cap are enforced at the API layer. You can think of the exit plan as the agent's intent, and the API limits as the hard floor and ceiling. The normalization is especially important for exits. An agent that manages both stocks and perps does not need to know that one venue measures size in shares and another in contracts. It simply says: close a specific dollar amount. The API handles the conversion. This reduces the chance that an agent makes a decimal error or uses the wrong unit when trying to exit quickly. If you want to understand how the normalization and safety layers fit together, read how a single API keeps AI trading safe by design.

Why can agents still lose money even with automated exits?

Automation reduces certain risks, but it does not eliminate market risk. Trading can lose money, including the entire budget allocated to the agent, and exit plans do not change that fact. Several failure modes remain. First, stop-loss orders are not guarantees. In fast markets, or in instruments with low liquidity, the fill price can be far worse than the trigger price. A stop on an options position or a perp may experience slippage that exceeds the planned loss. A prediction market with a wide spread can fill a market order at a price that looks nothing like the last trade. A stock broker may experience opening gaps that bypass a stop placed the night before. Second, gaps can jump past the trigger entirely. If a market moves from one price to another without trading in between, a stop-loss order placed at the intermediate level may fill at the worse price. This is common around news events, settlement periods, or market opens. Third, the agent or the network may be offline when the condition occurs. If the agent cannot reach the API, it cannot send the exit order. A power outage, a rate limit, or a software crash on the agent's host can all delay execution. During that delay, the market can move further against you. Fourth, the agent might misjudge the size of the position or the state of the market, especially if it is acting on stale data. It might think it has already exited half the position when it has not, or it might calculate the wrong average entry price and set its stop too loose. Finally, take-profit rules can leave money on the table, but that is a missed opportunity rather than a loss. The more important point is that a poorly set stop can lock in a loss that a human might have avoided, while a poorly set take-profit can cap gains prematurely. Both outcomes are real trading outcomes, not bugs in the system. The exit plan is a risk management tool, not a profit guarantee.

How should you structure an exit plan before authorizing a live key?

Paper trading exists for testing exactly this. You should never authorize a live key until the agent has demonstrated that it respects the exit plan repeatedly in simulation. The simulation uses real market data and real latency, but it does not move your capital. Use it to observe whether the agent triggers too early, too late, or not at all. Pay attention to whether the agent cancels an exit order to place a new entry order, or whether it modifies the exit price without permission. You should test the panic switch in paper trading before you rely on it. Observe how quickly positions flatten, how open orders are canceled, and whether any market-specific delays apply. The docs live at /docs on the site. When you move toward live trading, write the plan in deterministic terms. Ambiguous instructions are easy for a language model to misinterpret. Instead, use dollar thresholds, percentage thresholds, or time boundaries. Suppose you instruct the agent: if unrealized profit exceeds a specific dollar amount, close a defined percentage of the position. If the position is held for more than a set number of hours, reduce exposure by a predetermined fraction. If drawdown from peak equity crosses a stated limit, flatten all positions and await manual review. These numbers are hypothetical and should be sized to your own budget and risk tolerance. It is also useful to layer your exits. A single all-or-nothing take-profit can be difficult for an agent to execute cleanly, and it can leave you with no exposure if the trend continues. A staggered approach, where the agent trims the position at multiple thresholds, keeps some capital working while locking in gains. Similarly, a stop-loss should be paired with a daily or weekly loss limit that shuts down trading entirely if the agent is having a bad run. You can read more about coordinating these limits in how to set spend caps and drawdown limits for trading agents.

1. 01Define the maximum capital the agent can deploy before any exit is considered. This is the spend cap, and it should be set independently of the exit plan.
2. 02Set per-position size limits so that no single trade can dominate the portfolio.
3. 03Write take-profit levels in plain US dollars with explicit percentages of the position to close at each level.
4. 04Write stop-loss or drawdown levels that trigger a full flatten, not just a reduction.
5. 05Test the complete flow in paper trading, including the panic switch, before you authorize the live key.

What happens when an agent ignores or misinterprets its own rules?

Language models do not always follow instructions precisely. An agent might hallucinate a price, confuse a take-profit with a stop-loss, or decide that the current market context justifies holding through a predefined exit. It might see a sudden dip and reason that the price will recover, so it delays the stop. It might see a rally and decide to move the take-profit higher without asking. These are not edge cases. They are well-documented behaviors of LLM agents under uncertainty. This is why the exit plan cannot rely on the agent's good behavior alone. The safety controls must live outside the prompt. Felix enforces this through scoped keys and budget caps. If the agent tries to open a new position after hitting its drawdown limit, the API rejects the order. If it tries to increase risk beyond the position limit, the request fails. If it attempts to withdraw funds to an unapproved address, the transaction is blocked by construction. These are not prompt suggestions. They are protocol-level rules that apply regardless of what the agent believes. That said, if the budget cap is too high, or the position limit is too loose, the agent can still do significant damage before the hard ceiling kicks in. The exit plan is your first line of defense, but the scope of the key is the second. For a deeper look at how these layers interact, and common errors in configuring them, see common mistakes with spend caps and drawdown limits for trading agents.

How do panic switches and revocation limit the damage?

Every live key should have a kill switch. The panic switch is a single action that flattens all positions, cancels all open orders, and revokes the agent's access. It is the final backstop when you believe the agent is acting against your intent, or when the market is moving too fast for the exit plan to keep up. The flattening order is sent by the infrastructure, not by the agent, so it executes even if the agent is unresponsive. Once the positions are closed, the key is revoked. The agent cannot reconnect, and no new orders can be placed. You remain in full control of the wallet, and the funds are already back under your direct custody because they never left it. You can re-authorize a new key later if you want to resume, but the old key is permanently dead. You should also set up an exit plan for the agent itself. Define conditions under which the agent should stop trading for the day. For example, a sequence of failed exits, a string of losses exceeding a daily threshold, or a sudden spike in volatility might all be reasons to halt. These halts are not failures. They are risk controls. The goal is to keep the agent from trading its way into a deeper hole. Remember that trading can lose money, and a paused agent is preferable to one that compounds losses while trying to recover them. If you are evaluating whether your agent is ready to trade real money, you may also find value in why AI agents force developers to rethink trading risk management.