How to design prompts for a trading agent

A trading agent prompt is a set of instructions that tells an autonomous system what to trade, when to act, and what it is forbidden to do. A good prompt separates goals from hard constraints, defines how to handle uncertainty, and requires explicit confirmation before any irreversible action. Without these boundaries, the agent may interpret vague language as permission to take risks you did not intend.

What should a trading agent prompt include?

Begin by stating the objective in plain language. The agent does not need a motivational preamble; it needs a precise description of the desired outcome. For example, you might instruct the agent to maintain a target allocation across stocks and crypto, or to reduce delta exposure when a portfolio drifts beyond a threshold. The objective should be measurable so that the agent can evaluate its own success against a clear benchmark. If the goal is to harvest volatility, specify the exact metric, such as the annualized standard deviation of returns, and the target range. If the goal is to hedge, define the beta or dollar exposure the agent should neutralize. Without a number, the agent has no way to know when it has succeeded or failed. Next, define the universe of instruments the agent may touch. Specify which asset classes are permitted, such as stocks, crypto, perps, options, or prediction markets, and whether the agent may cross between them. If you want the agent to ignore certain markets entirely, say so explicitly. Ambiguity here leads to unwanted exposure in instruments you never intended to trade. You should also state whether the agent is allowed to hold cash, stablecoins, or margin positions, and whether it may use leverage. If leverage is permitted, cap it with a specific multiplier and tie it to a maximum loss limit. After scope, list the allowed actions. An agent connected to a trading API can typically place orders, cancel orders, query balances, and read market data. Your prompt should state which of these it may use and under what conditions. If the agent is only allowed to rebalance once per day, write that as a rule rather than a suggestion. State which order types are permitted, such as market orders, limit orders, or stop losses, and under what conditions each may be used. If stop losses are forbidden because they can be hunted, say so. Agents interpret literal instructions more reliably than implied etiquette. Finally, tell the agent what to report and when. A prompt should require a structured summary after each decision cycle that includes the intended action, the rationale, the estimated risk, and any constraint checks that were performed. This creates an audit trail and lets you verify that the agent is reasoning the way you expect. Specify the format of this report, whether it is a JSON object, a bullet list, or a natural language paragraph with required headings. If the agent cannot generate the report because of a system error, it should halt rather than trade blindly. You can read more about the underlying infrastructure in what is agentic trading and a trading API built for AI agents.

How do you separate goals from constraints?

Goals describe what you want to achieve, while constraints define what the agent is never allowed to do. Mixing the two in a single sentence is a common source of errors. Write goals as preferences and constraints as absolute rules. For instance, a goal might be to keep cash reserves above twenty percent of portfolio value. A constraint would be that the agent must not open any new position if cash reserves fall below ten percent. The goal is aspirational; the constraint is a hard floor. Use unambiguous language to distinguish between these categories. Reserve phrases like "you should" or "it is preferable" for goals. Use "you must" or "it is forbidden" for constraints. When an agent faces a conflict between a goal and a constraint, it should always satisfy the constraint and pause for human review rather than optimize around the boundary. You can reinforce this hierarchy by adding a meta-instruction at the top of the prompt: "If any instruction conflicts with a constraint, the constraint wins and you must ask for clarification." It helps to assign numeric values wherever possible. A constraint like "do not take too much risk" is impossible to evaluate consistently. A constraint like "no single position may exceed five thousand dollars notional" is machine readable. If you use percentages, specify whether they are calculated against total net worth, liquid portfolio value, or available buying power. Each interpretation yields a different outcome, so the prompt must fix the denominator. Similarly, time-based constraints need exact windows. "Trade only during market hours" is vague if you operate across time zones. Specify the exchange time zone, the exact open and close times, and whether pre-market or after-hours sessions are included. Another useful technique is to rank your goals. If the agent cannot satisfy every goal simultaneously, tell it which one to prioritize. For example, you might rank capital preservation above return optimization, or liquidity above concentration. This prevents the agent from silently making trade-offs you would not approve. Without a ranking, the agent may default to whatever its training data suggests, which may not match your risk profile.

Why should you define failure modes explicitly?

Real trading involves gaps, delays, and rejected orders. Your prompt must describe what the agent should do when the market does not cooperate. If a limit order fails to fill within a specified window, does the agent retry, widen the price, or cancel and notify you? If price data is stale, does it trade anyway or halt? These decisions should not be left to improvisation. Specify the maximum age of data the agent may act upon, and define the fallback when freshness checks fail. If the agent relies on multiple data sources, describe how to handle disagreements between them. Define how the agent responds to adverse moves. Suppose a position loses ten percent of its entry value. The prompt might require the agent to reduce size by half, or to hold only if the fundamental thesis remains valid, or simply to alert you and wait. Without this instruction, an agent may do nothing, or it may double down, depending on how its underlying model interprets silence. Neither outcome is acceptable if you have a specific risk tolerance. Be equally specific about favorable moves. If a position gains twenty percent, does the agent take profit, trail a stop, or let it run? The absence of a rule becomes a rule of its own. Include a kill condition. State the exact point at which the agent must flatten all positions, revoke its own access, and return control to you. This is your panic clause. It should be triggered by a drawdown limit, a manual command, or an anomaly such as a missing heartbeat from your monitoring system. The prompt should describe the exact sequence: cancel open orders, close positions at market or limit, verify the flat state, and then disable the key. Building these safeguards into the prompt is complementary to the technical controls described in how to build guardrails for a trading agent and how to set spend caps and drawdown limits for trading agents.

How do you test a prompt before live trading?

Never deploy a new prompt directly to a live market. Begin with paper trading so the agent can execute its logic against real price feeds without committing capital. Watch for three things during this phase: whether the agent follows the prompt literally, whether it invents actions you did not authorize, and whether its reasoning trace matches the logic you intended. Paper trading reveals prompt ambiguities that are invisible during static review. An agent that consistently misreads a single word can demonstrate the error within hours rather than days. Run adversarial reviews. Read the prompt as if you were trying to exploit it. Look for weasel words like "reasonable" or "appropriate" that an agent could interpret broadly. Check for gaps where the prompt is silent. If you have not explicitly forbidden short selling, for example, an agent that sees an opportunity might assume it is permitted. Add explicit prohibitions for anything outside your intended strategy. It helps to have a second person review the prompt, because fresh eyes catch assumptions the author missed. Ask them to list three ways they would break the rules without technically violating the text. If they succeed, your prompt needs tightening. Iterate based on log analysis. After each paper session, review the agent's decision logs. Did it state the constraint before acting? Did it verify the budget cap? Did it explain why it skipped a trade? If the logs are vague, the prompt probably is too. Tighten the language and run another cycle. Change one variable at a time so you know which edit fixed the problem. If you rewrite the entire prompt between sessions, you cannot tell which clause caused the improvement or the regression. Paper trading costs time, but it is far cheaper than funding an error. Only when the agent behaves predictably across multiple market conditions, including volatile and quiet sessions, should you consider live authorization. Even then, start with a small capital allocation and monitor the logs daily for the first week.

What does a good verification step look like?

Before any live trade, the agent should be required to quote the relevant constraint back to you. This is a simple but effective verification technique. For example, the agent might output: "I intend to buy two thousand dollars of X. My single-position limit is five thousand dollars. This order complies." If the constraint check is missing or incorrect, you know the prompt is not being followed. You can automate this validation by parsing the agent's output and refusing to submit any order that fails the self-check. You can also require the agent to wait for your explicit reply before it proceeds to execution, creating a human-in-the-loop gate for the first few live trades. Use structured outputs where possible. Ask the agent to return its intended action in a fixed format that includes fields for symbol, direction, size in dollars, risk check result, and confidence level. A structured response is easier to validate programmatically than a freeform paragraph. You can write a small validator that refuses to submit any order missing a required field. Structured output also makes it easier to replay decisions later for debugging or auditing. Remember that non-custodial architecture changes what verification means. Because the agent trades through an API key with scoped permissions and budget caps, it cannot withdraw funds to an external address even if the prompt fails. The owner retains the only withdrawal authority. This means verification is about preventing unwanted trades, not theft. Still, unwanted trades can lose money, including everything, so the verification step remains essential. Treat the prompt as the first layer of defense and the permission layer as the second. Both must be correct, but the prompt is where your intent is encoded.

Frequently asked questions