How to design prompts that keep trading agents within bounds

A well-designed trading agent prompt does not describe a strategy in loose terms. It defines permitted actions, forbidden actions, decision boundaries, and the exact format of outputs so that the model cannot accidentally interpret ambiguity as an instruction to trade. Prompt design for agents is a safety layer, not a stylistic exercise. The following checklist covers the constraints, context, and verification steps that should be present before an agent connects to a live market.

What should a trading agent prompt always include?

A trading agent prompt is a specification, not a conversation starter. It must begin with an explicit scope: the asset classes the agent may touch, the venues it can access, and the directionality it is allowed to use. If the agent is only permitted to trade stocks and prediction markets, the prompt must say so directly. If it is forbidden from short selling or from using leverage above a specific threshold, that prohibition must be stated in plain language and repeated in the output requirements. The prompt must also fix the unit of account. Because Felix normalizes order sizing into plain US dollars across stocks, crypto, perps, options, and prediction markets, the prompt should instruct the agent to specify every order size in USD and leave contract calculations to the API. This removes an entire category of error where a model confuses notional value, margin, or token count. Next, define the output schema. The agent should emit a structured object, not free text. The structure should separate reasoning from action. A reasoning block forces the model to articulate why it believes the trade fits the strategy, while the action block contains the ticker, direction, size in USD, and order type. If the reasoning fails any constraint, the action block must be empty or contain an explicit no-trade flag. Finally, list the hard stops. These are non-negotiable conditions that override the strategy. Examples include: do not trade if daily losses exceed a defined USD threshold, do not trade if price data is older than a defined number of seconds, and do not trade if the total exposure across all positions would exceed a defined cap. These stops belong in the prompt itself, not in a separate document, because the model must evaluate them on every iteration. For a deeper look at structuring these rules, see how to design prompts for a trading agent.

How do you prevent prompt ambiguity from becoming an order?

Natural language is porous. A phrase like 'add exposure on weakness' can be interpreted as a market order, a limit order, a scaled entry, or a full position. A phrase like 'reduce risk' could mean flatten everything, trim half, or hedge. The prompt must replace interpretive language with conditional logic. Instead of 'buy the dip,' write: 'If the price of an tracked asset drops by at least five percent within a one-hour window and the daily loss budget has not been exceeded, submit a buy order sized at the minimum of five hundred US dollars or the remaining hourly budget.' To enforce this precision, require the model to restate the condition it detected before it proposes the action. If the model cannot identify the exact trigger, the instruction set should default to no action. This pattern is sometimes called a guard clause in software engineering, and it belongs in prompt engineering just as much as it belongs in code. Ambiguity also hides in time references. 'End of day' means different things in different markets. 'Soon' has no meaning to an API. The prompt must specify timestamps, lookback windows, and session boundaries in concrete numbers. If the model is meant to close positions before a weekend, state the exact hour and minute in UTC. Another source of ambiguity is the treatment of partial fills and open orders. The prompt should tell the agent whether it may layer orders, whether it should cancel and replace, or whether it must wait for a fill before sending another instruction. Without this, an agent might spam the API or double its intended exposure. Remember that trading can lose money, including everything, and ambiguous prompts raise the probability of unintended losses. For common misconceptions about how agents behave, read what most people get wrong about LLM trading with real money.

Why do scoped keys and budget caps belong in the prompt context?

API-level safety controls are essential, but they are not enough. If the agent does not know its own limits, it will generate plans that the API must reject, wasting cycles and creating noisy error loops. Worse, a model that is unaware of a depleted budget might reason its way into a larger position by splitting orders across multiple calls, not out of malice but because the prompt gave it no financial guardrails to consider. The prompt should include a dynamic context block that is refreshed before each inference. This block states the current daily budget consumed, the remaining daily budget, the per-trade maximum, the current number of open positions, and the total notional exposure. It should also note the scope of the key: which markets are reachable and which order types are permitted. When the agent sees that it has only two hundred dollars left in a daily cap, it can choose to size down or skip the trade rather than emit an order that the API will block. This transparency also improves debugging. When a trade log shows an unexpected no-trade decision, the prompt context reveals whether the model was aware of the budget state at that moment. If the context was missing, the model may have acted on stale assumptions. The context block should be formatted as a simple key-value list, not buried in narrative text, so the model can scan it quickly. Including safety parameters in the prompt does not replace the non-custodial architecture of the system. Funds remain in a wallet the owner controls, scoped keys enforce the actual limits, and the panic switch can flatten and revoke access. But the prompt is the first line of defense. It shapes the model's intent before any bytes reach the API. For the broader safety model behind these controls, see how safety is built into AI portfolio rebalancing from first principles.

How should you structure multi-step reasoning in prompts?

Trading decisions benefit from sequential checks, but unconstrained chain-of-thought can drift. The prompt should impose a rigid checklist order that the model must follow before emitting any action. A sensible sequence is: one, verify that market data is fresh and within the allowed lookback window; two, confirm that the strategy signal is present and meets the minimum confidence threshold; three, check the current portfolio state against the exposure and budget limits; four, calculate the order size in US dollars using the formula provided; five, format the output according to the required schema. Each step must have a clear pass-fail condition. If market data is stale, the process stops and the output is a no-trade with the reason code DATA_STALE. If the signal is present but the daily budget is exhausted, the process stops with the reason code BUDGET_EXHAUSTED. This creates an audit trail inside the model's reasoning that developers can read in the logs without having to guess why a trade did or did not happen. To prevent the model from collapsing the checklist into a vague summary, require it to label each step explicitly in the reasoning block. The output should contain lines like 'Step 1: Price data timestamp is 2026-08-08T14:32:00Z, within 60 seconds. Pass.' This verbosity is not wasted tokens. It is evidence that the model executed the plan rather than hallucinating a conclusion. You can also add a final review instruction: 'Before finalizing, re-read the hard stops. If any stop is violated, discard the planned trade and output NO_TRADE.' This meta-cognitive step nudges the model to verify its own work. It is not foolproof, but it increases the chance that an overlooked constraint is caught before the structured action block is produced.

What is the role of paper trading in prompt validation?

Every change to a prompt, no matter how small, should be tested in paper trading before it touches a live market. Paper trading on Felix lets the agent execute against real market data without risking capital, and it is the only reliable way to observe how a model interprets new instructions under live conditions. A prompt that looks precise in a text editor may behave differently when the model is processing a volatile price stream. Deliberately test edge cases. Feed the prompt a scenario where the budget is ninety-nine percent consumed and verify that the agent sizes down or stops. Introduce stale market data and confirm that the hard stop triggers. Present an ambiguous signal that sits just below the stated threshold and check that the agent does not force a trade. These tests reveal whether the prompt's conditional language is tight enough or whether the model is reading between the lines. Paper trading also catches formatting errors. If the output schema changes in the prompt but the downstream parser expects the old field names, paper trades will fail to validate before any real money is at risk. This is especially important when iterating on multi-step reasoning structures, because the parser may need to extract new reason codes. Keep a log of prompt versions alongside paper trading results. When a live anomaly occurs, you will want to know exactly which prompt version was active and whether the anomaly appeared in testing. Many developers skip this discipline and lose the ability to rollback cleanly. For a guide on common testing errors, see common mistakes developers make with paper trading for AI agents.

How do you maintain prompts as markets and strategies change?

Prompts are live documents. A prompt written for a low-volatility regime may encourage position sizes that are dangerous when volatility spikes. A prompt that assumes a specific market structure may break when the asset list changes. Treat prompts with the same rigor as code: version control, peer review, and regression testing. Store each prompt in a repository with a semantic version number. When you update a threshold, a wording, or a reasoning step, increment the version and write a one-line rationale. The trade log should record the prompt version ID for every decision. This correlation lets you distinguish between a model failure and a prompt failure when reviewing historical performance. Schedule periodic reviews even if nothing appears broken. Markets shift, model behavior shifts, and API capabilities expand. A quarterly review of the prompt against recent paper trading logs will reveal drift. You may find that the model has started interpreting a phrase differently, or that a new asset class on the API is being ignored because the whitelist is too narrow. When retiring a prompt, do not delete it. Archive it with a note explaining why it was replaced. This archive becomes a training resource for the team and a defense against repeating past mistakes. Prompt maintenance is not overhead; it is part of the risk management system.