How designing prompts for trading agents differs from writing manual rules

Designing prompts for trading agents is not a matter of writing down what you would do manually. A human trader implicitly manages timing, context, and failure modes through judgment and hesitation, but an agent executes exactly what the prompt contains and nothing more. This difference means that prompt design must reconstruct first principles from the ground up, encoding state, safety boundaries, and error handling that manual trading rarely puts into words. The transition from manual rules to agent prompts requires abandoning the assumption that common sense will fill the gaps.

Why do manual trading rules fail when copied into an agent prompt?

Manual traders often write rules like 'buy the dip' or 'sell if the trend reverses.' These instructions rely on shared context. A human knows what counts as a dip, which timeframe matters, and when to ignore noise. An agent does not share this context. If the prompt says 'buy when the price drops,' the agent may buy on a one-second wick, a data feed glitch, or a symbol it misidentified. The gap is not intelligence. It is specificity. Manual rules assume a human will pause, verify, and adapt. Agent prompts must treat every condition as a logical gate. You must define the data source, the time interval, the confirmation threshold, and the exact order size in dollars. You must also define what happens when the condition is not met, because the agent will not wait.

This is where dollar-based order sizing becomes critical. A prompt that says 'invest $100' sounds precise, but the agent needs to know whether that means notional value, margin required, or maximum loss. Manual traders adjust sizing instinctively after seeing the order book. Agents cannot. They need the prompt to state the calculation in plain US dollars and to specify whether that amount is per trade, per symbol, or per strategy. Without this, the agent may size orders based on a misunderstanding of the venue's contract structure, even though the API normalizes the math.

What does an agent need to know that a human trader already knows?

A human trader sitting at a screen holds a vast amount of implicit state. They know whether they are already in a position, how much capital is available, what the broader market is doing, and whether a news event is unfolding. They feel hesitation. An agent prompt must externalize all of this.

First, the prompt must track position state explicitly. It cannot assume the agent remembers the last trade. The prompt should instruct the agent to read the current position before deciding, or the system should provide that state in the context window. Second, the prompt must define the market environment. A human knows that a stock broker behaves differently than a perps venue. The agent must be told which market type it is trading, because order syntax, settlement, and risk differ across stocks, crypto, perps, options, and prediction markets. The prompt should also specify whether the agent is allowed to hold positions overnight, because settlement rules differ between a stock broker and a perps venue.

Third, the prompt must encode time and sequence. A human knows that 'wait five minutes' means watching the chart. An agent needs a clock or a polling rule. If the prompt does not specify when to re-evaluate, the agent may act immediately, or not at all. Time is not self-evident to a system that processes each request independently. Fourth, the prompt must handle ambiguity. Humans ask clarifying questions. Agents either guess or halt. The prompt should specify a default action for ambiguous signals, such as doing nothing and logging the event. This default action prevents the agent from taking a random trade when the data is unclear.

How should you structure a trading prompt to handle real-time constraints?

Real-time markets do not pause for reasoning. A prompt must be structured so that the agent can make decisions within the constraints of latency and API rate limits. This means separating strategy logic from execution logic.

The strategy layer should define what the agent is looking for. For example, suppose the agent monitors a moving average crossover. The prompt should state the exact calculation, the candle interval, and the confirmation count. It should also define what happens when the moving averages touch but do not cross, or when the signal appears during a known low-liquidity window. The execution layer should define what happens when the condition is met. This includes order size, order type, and what to do if the first attempt fails.

The prompt should also include a failure branch. If the API returns an error, if the price moves beyond a slippage threshold, or if the venue rejects the order, the agent needs a rule. Manual traders curse and retry. Agents need explicit instructions: retry once, log the error, and alert the owner. Without this, the agent may loop, spam, or give up silently. The failure branch is not an exception. It is a core part of the trading logic.

The exact request schema is in the docs; the shape looks like this:

{
  "key": "YOUR_KEY",
  "market_type": "perps",
  "intent": "open_long",
  "max_spend_usd": 500,
  "slippage_threshold": 0.005,
  "on_reject": "log_and_halt"
}

This example illustrates how the prompt must connect the agent's reasoning to concrete fields. The agent does not negotiate. It fills the template and sends it. The prompt must therefore tell the agent which fields are mandatory, which are optional, and what each field represents in the language of the strategy.

Where do safety limits belong in the prompt design?

Safety limits are not an afterthought. They are part of the first principles of the prompt. The prompt must treat the agent as a system that can fail fast and lose money. Every prompt should include at least three types of boundaries.

• ·Budget caps: the maximum dollar exposure per trade, per day, and per strategy.
• ·Position limits: the maximum percentage of allocated capital in a single asset or market, and whether the agent may add to a losing position.
• ·Temporal limits: the hours or conditions under which the agent may trade, preventing activity during illiquid or high-volatility windows unless explicitly allowed.

These limits are enforced by the Felix infrastructure, but the prompt must align with them. If the prompt tells the agent to trade aggressively while the API enforces a spend cap, the agent will hit a wall and may behave unpredictably. It is better to embed the limits into the agent's reasoning so that it plans within them. You can learn more about this alignment in how to set guardrails for a trading agent. The prompt should also state whether the agent is allowed to increase position size during a drawdown, or whether it must reduce risk as losses accumulate.

The panic or kill switch is another first principle. The prompt should tell the agent what to do when the owner triggers a halt. Ideally, the infrastructure flattens positions and revokes the key, but the prompt should also instruct the agent to stop initiating new orders and to log its final state. This prevents race conditions between the human and the agent. The prompt should also specify what the agent does if it detects that its key has been revoked mid-session, because the agent may otherwise continue to evaluate signals and attempt actions that cannot complete.

How do you test a prompt before it touches live markets?

A prompt that has never been executed is a hypothesis. Testing it requires paper trading, but paper trading only reveals logical errors, not market impact or liquidity gaps. Still, it is the essential first step.

Run the prompt against paper markets for several days. Watch for drift. Does the agent interpret the instructions consistently? Does it trade at the expected frequency? Does it respect the boundaries? Common errors include misreading timestamps, confusing open and close prices, and ignoring the distinction between limit and market orders. Paper trading lets you catch these errors without cost.

You should also simulate failures. Disconnect the data feed briefly. Submit a prompt that references a nonexistent symbol. See if the agent halts or panics. These tests reveal whether the prompt contains adequate error handling. If the agent assumes every API call succeeds, it will compound errors in live trading. You want the agent to stop, log, and wait for human input when the world does not match its assumptions.

After paper testing, move to live trading with a small authorization key and strict limits. The prompt should be identical to the paper version, only the key and the budget change. This reduces the risk that the agent behaves differently in production. You can read more about the safety model in how a single API changes safety for trading agents versus bots.

What changes when you move from paper to live trading?

Paper trading assumes perfect fills and no slippage. Live trading involves real order books, latency, and partial executions. The prompt must account for this transition.

In live trading, the agent may not get the full size it wants. The prompt must specify whether to take a partial fill, cancel the remainder, or wait. It must also specify what to do if the price moves against the position immediately after entry. Manual traders often manage this by feel. The agent needs a rule. The rule should be based on the dollar value of the position and the remaining budget, not on vague emotional thresholds.

Live trading also introduces emotional feedback for the owner. The agent does not feel fear, but the owner does. The prompt should be designed so that the owner can read the agent's intent and verify its actions. This means including clear logging instructions in the prompt, and using exit plans and take-profit automation that are defined in advance rather than improvised. The owner should be able to review the agent's reasoning chain and verify that each action matched the prompt's stated logic, which creates accountability that manual trading often lacks.

Finally, live trading means real money can be lost, including everything. The prompt must not promise returns or assume edge. It must state the conditions under which it will stop itself. A manual trader might decide to quit for the day after three losses. The agent needs that rule written out. The prompt should define a daily loss limit, a maximum number of trades, or a volatility threshold that triggers a halt. Without this, the agent will continue to execute because it does not know when to stop.