What most people get wrong about prompt design for non-custodial trading agents

Most developers assume that designing prompts for trading agents is primarily about encoding strategy, but the harder problem is encoding constraints. When your funds remain in a wallet you control and the agent acts through scoped keys, the prompt must describe the guardrails that the API enforces, not just the trading goals. The common mistake is writing prompts that treat the agent as a trusted employee who understands implicit boundaries, rather than as a literal tool that can only follow what is explicitly written. This misunderstanding leads to overtrading, scope violations, and unintended positions that the owner must manually unwind. The result is often a portfolio that drifts far from the intended risk profile before the human operator notices.

Why do prompts need to mention safety controls explicitly?

The API layer enforces spend caps, position limits, and kill switches, but the language model has no native awareness of these boundaries. If the prompt only describes a strategy, the agent may generate orders that violate its own key scope and then receive errors it does not understand. This creates a loop of failed requests or, worse, partial executions that leave the portfolio in an unintended state. You should state the safety model directly in the system prompt. Include the maximum daily budget in US dollars, the specific markets the agent may access, the fact that withdrawal addresses are owner-approved only, and the existence of a panic switch that flattens positions and revokes access. By making the constraints visible to the agent, you turn API rejections into intentional behavior rather than surprises. The agent should know that a hard limit is a feature of its environment, not a bug. You should also tell the agent what to do when it hits a limit. Without this, the agent may simply pause and wait, or it may attempt to route the same order through a different market type in the hope that the limit is per venue. Clarify that the budget is global across stocks, crypto, perps, options, and prediction markets. This alignment between prompt language and infrastructure is the core of non-custodial design. How scoped API keys let an agent trade without taking custody of your funds explains the underlying mechanics in detail.

How should you scope instructions to avoid overtrading?

Ambiguity in a prompt is read as permission. An instruction like 'trade when you see volatility' gives no ceiling on frequency, size, or total exposure. The agent may attempt to open dozens of positions across multiple venues because the prompt did not specify a maximum count. You should include hard numeric boundaries in the system prompt: a maximum number of open positions, a maximum order frequency per minute, and a total notional budget expressed in US dollars. These numbers should mirror the hard limits set on the key itself. If the API allows three open positions but the prompt says five, the agent will hit the wall and stall. You should also define what constitutes a complete trading cycle. Does the agent wait for a position to close before opening another? Can it hold overlapping hedges? Without this clarity, an agent with access to a perps venue and an options venue might accidentally stack correlated exposures that amplify risk. You should also specify whether the agent is allowed to average into a position or if each signal gets only one entry attempt. Many developers forget to state that the agent must not double down on a losing trade unless the prompt explicitly authorizes it. Averaging in without a rule is a common source of unexpected drawdowns. The A practical checklist for non-custodial AI trading offers a framework for matching prompt language to key configuration.

What makes dollar-based sizing harder to prompt than it looks?

Felix normalizes order sizing to plain US dollars across stocks, crypto, perps, options, and prediction markets. This abstraction is helpful for developers, but it is not intuitive for a language model trained on natural descriptions of trading. An agent prompted to 'buy one Bitcoin' may literally request one dollar's worth, or it may attempt to interpret 'one' as a contract unit on a perps venue and request a notional amount that mismatches your intent. You must explicitly instruct the agent to size every order in US dollars and to use the exact dollar amount provided by its strategy logic. For derivatives, you should also clarify that the dollar value refers to notional exposure, not margin posted, because the agent cannot compute venue-specific margin formulas on its own. For options, a prompt that says 'buy two hundred dollars of calls' is clearer than 'buy two calls,' since contract multipliers vary. You should also instruct the agent to verify the total portfolio notional after each proposed order, because a prompt that only checks individual order size can still exceed the total budget through accumulation. How to size orders in dollars when building a trading agent covers the technical details.

Why does treating the agent like a human trader backfire?

Human traders understand context, ask for clarification, and interpret vague instructions through a lens of risk awareness. An agent does none of this. If you tell a human to 'reduce exposure,' they know to ask which positions, by how much, and in what order. An agent will simply do something, and that something may be closing the wrong leg of a hedge or selling into a thin order book. Suppose you hold a spread across a stock and an options venue. A prompt that says 'trim the riskier side' gives the agent no objective criteria for deciding which side is riskier. It might close the hedge and leave the directional exposure. Instead, you should write conditional rules: if the delta of the options position exceeds X, sell Y dollars of the underlying stock. Every instruction needs a measurable trigger and a precise action. You should also avoid relative language like 'a small position' or 'lighten up.' The agent has no internal sense of proportion. Specify percentages of the total budget or exact dollar amounts. Remember that trading can lose money, including everything, and a literal agent will execute losing strategies exactly as written if the prompt does not contain explicit loss limits.

How do you test prompts without risking real capital?

Paper trading exists for exactly this purpose, but testing only the happy path is itself a common mistake. You should test what happens when the prompt contradicts the key scope. Imagine your prompt instructs the agent to allocate five hundred dollars to a prediction market, but the scoped key caps that market at one hundred dollars. The agent will receive a rejection from the API. If the prompt did not mention the cap, the agent may interpret the rejection as a temporary error and retry indefinitely. Good prompt design includes an instruction like 'if an order is rejected for exceeding scope, stop and report instead of retrying.' You should also test the kill switch language. If you tell the agent to 'flatten everything when I say stop,' you need to verify that the agent understands 'flatten' means close all positions across all five market types and then stop generating orders. Test what happens when market data is delayed or stale. An agent that assumes prices are real-time may calculate sizes based on old numbers and submit orders that no longer fit the intended risk profile. You should include an instruction that requires the agent to check the timestamp of the data before acting. 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 '{
    "market": "perps",
    "side": "sell",
    "size_usd": 1000,
    "symbol": "ETH"
  }'

Run this against the paper endpoint first. Observe whether the agent respects the size_usd field or tries to override it with its own logic. If the agent invents its own sizing, your prompt lacks sufficient constraint. You should also simulate a panic event during paper trading to confirm the agent flattens and does not attempt to reenter immediately.

What belongs in the system prompt versus the user prompt?

The system prompt should contain everything that does not change during a session: the agent's role as a constrained trader, the list of permitted markets, the mandate to size in US dollars, the hard numeric limits, and instructions on how to handle errors and the kill switch. The user prompt should contain the dynamic context: current prices, recent fills, news snippets, or specific questions you want the agent to answer. Mixing these layers causes constraint drift. If you embed a budget limit in the user prompt and then later send a user message that omits it, the agent may act as if the limit no longer exists. Similarly, if you place market data in the system prompt and update it frequently, the agent may start to treat the constraints as variable. Keep the system prompt stable. If you must change the guardrails, start a new session rather than appending an instruction mid-conversation. This separation is especially important when using MCP tools, because the tool definitions themselves are static and should be accompanied by a static system prompt that defines how aggressively the agent may invoke them. When the agent connects through an MCP client, the client may feed tool schemas automatically, but the behavioral boundaries still need to live in the system prompt so they persist across every tool call.