How to write prompts that keep trading agents inside hard limits

A well-designed trading prompt tells the agent what to watch and how to reason, but it does not serve as the final authority on what trades are allowed. Hard limits are enforced by the infrastructure beneath the prompt, not by the language model's interpretation of rules. The goal is to write prompts that describe strategy clearly while leaving safety boundaries to the API and wallet controls that the agent cannot rewrite.

What is the difference between a prompt and a hard limit?

A prompt is natural language instruction that shapes how an agent interprets market data and decides what actions to request. It is guidance. A hard limit is a programmatic constraint checked at the API or wallet level before any order reaches a venue. It is a wall. The prompt might say, look for momentum breakouts on four hour candles, but the hard limit says do not open a position larger than five hundred dollars or do not trade after 4 p.m. Eastern. One shapes intent; the other blocks execution. When you write a prompt, you are essentially designing a reasoning template. The model reads the prompt, ingests market data through its tools, and generates a plan. That plan is then passed to the trading infrastructure. If the plan violates a hard limit, the infrastructure rejects it. The prompt never sees the rejection coming unless you explicitly instruct the agent to expect and interpret API feedback. This means the prompt operates in the realm of probability and preference, while the hard limit operates in the realm of boolean permission. Understanding this distinction is the foundation of safe agent design. If you treat the prompt as both strategy and enforcement, you create a single point of failure. The language model can drift, be jailbroken, or simply misparse a sentence. A hard limit in the API layer has none of those vulnerabilities. It evaluates the same rule every time, regardless of context length or model version. This distinction is why prompts differ from manual rules.

Why should hard limits sit outside the prompt?

Language models can misread, misremember, or creatively reinterpret instructions. A limit written only in the prompt text is a suggestion, not a guarantee. If the context window grows long or the model is swapped, the phrasing might lose weight. By contrast, a hard limit encoded in the API layer is evaluated on every request with the same logic regardless of what the prompt currently says. That consistency is what autonomous systems enforce hard limits is about. Moving limits into infrastructure also makes them auditable. An owner can see that a budget cap or position ceiling is enforced by the system, not by hoping the model stays in character. This separation follows a simple design principle: the prompt handles strategy, the platform handles safety.

There is another reason to keep limits outside the prompt. Prompts are often iterated quickly. A developer might tweak wording to improve signal detection or reduce latency in decision-making. If safety rules are embedded in that same text, they can be accidentally edited, shortened, or moved into a section the model deprioritizes. Hard limits configured in the API or wallet settings are isolated from prompt versioning. They persist across prompt updates, model swaps, and tool changes. This stability matters because trading conditions change fast, but your risk tolerance should not change unless you deliberately update it. The infrastructure layer treats your safety settings as configuration, not conversation.

How do you write a strategy prompt that respects hard limits?

Start by stating the objective in plain language. Describe the market conditions the agent should monitor, the signals it should weigh, and the actions it should consider. Then, explicitly acknowledge the guardrails. For example, the prompt can say, before placing any order, check that the proposed size fits within the owner's configured budget cap and does not exceed the per-asset position limit set in the system. This trains the agent to think about constraints without assuming it can override them.

Avoid writing limits as conditional suggestions the agent can debate. Do not say, try not to spend more than one thousand dollars unless the setup looks exceptional. That introduces ambiguity. Instead, describe the strategy in terms of percentages or relative weights, and let the hard limit infrastructure translate those into absolute dollar caps. The API normalizes order sizing in plain US dollars, so the prompt can speak in intuitive terms while the system enforces the math. The relationship between strategy text and dollar reality is covered in more detail in spend caps and drawdown limits.

Another useful technique is to include a decision checklist inside the prompt. The agent can be instructed to verify signal strength, check correlation with existing positions, and confirm that the proposed action passes the safety layer. This keeps the prompt focused on reasoning while the enforcement stays mechanical. You should also instruct the agent on how to handle rejection. When the API returns an error because a hard limit was hit, the agent needs to know whether to log the event, notify the owner, or simply wait for the next signal. Without this guidance, the agent might loop, retry the same invalid order, or hallucinate a workaround. A good prompt explicitly says, if the platform rejects an order for exceeding a limit, stop and report the reason. Do not attempt to bypass the limit by splitting the order or changing the symbol. This reinforces the hierarchy between strategy and safety. Finally, keep the prompt focused on information gathering and analysis. The more you ask the model to do complex arithmetic or dynamic sizing in the prompt, the more likely it is to make an error that conflicts with your actual limits. Let the infrastructure handle the arithmetic of position sizing and drawdown control. The prompt should answer questions like what is happening in the market and what does the strategy suggest. The platform answers the question is this allowed.

What happens when a prompt contradicts a hard limit?

The hard limit always wins. If the prompt asks for a ten thousand dollar position but the owner's budget cap is set to one thousand, the API rejects the order. The agent may receive an error message explaining the violation, and a well-written prompt will instruct it to log the conflict and adjust rather than retry aggressively.

This behavior is intentional. It prevents prompt injection or creative reinterpretation from bypassing safety controls. The model might hallucinate a reason to exceed a limit, but the noncustodial wallet and scoped API key do not execute the request. The panic or kill switch remains available to the owner regardless of what the prompt currently contains. You can read more about how to layer these controls in build guardrails for a trading agent. It is worth testing these contradictions deliberately in paper trading. Suppose you temporarily set a very low cap and then instruct the agent to trade aggressively. You want to see two things: first, that the API blocks every oversized request, and second, that the agent does not spiral into an error loop. The prompt should contain a clear instruction that API rejections are final. When the agent learns that the platform's no is absolute, it behaves more predictably. This also protects against subtle prompt attacks. If someone else gains access to the agent's input channel and tries to override your safety instructions, the hard limits in the infrastructure remain untouched. The attacker can write any prompt they want, but they cannot move funds beyond the scoped permissions encoded in the key.

How do you test prompts without risking real capital?

Paper trading exists for this exact purpose. An owner can connect the agent to the API in paper mode, send the same prompts they intend to use in live trading, and watch how the agent behaves when it hits synthetic limits. This reveals whether the prompt causes the agent to argue with the system, loop on errors, or gracefully accept boundary feedback.

During testing, deliberately send prompts that edge against limits. Ask the agent to size up aggressively or trade near cutoff times. Observe whether the API blocks the requests and whether the agent's retry logic is safe. If the prompt contains instructions to flatten on certain conditions, confirm that the agent issues the exit request and that the kill switch can still override it. Testing should also cover model behavior on ambiguous phrasing. For instance, if your prompt says reduce exposure when volatility spikes, does the agent interpret that as a suggestion to close half the position or the entire position? In paper mode, you can watch the specific orders it generates and refine the prompt accordingly. This is also the right time to validate your exit plan. A prompt that says take profit at ten percent is different from one that says begin scaling out at ten percent and fully exit by fifteen percent. The former is a hard rule embedded in the prompt, the latter is a strategy. If you want a true hard exit, it belongs in the API exit plan, not just the prompt text. Use paper trading to confirm that the agent's interpretation matches your intent before any real money is involved. Remember that even a well-tested prompt can fail in live markets because liquidity, slippage, and latency differ from simulation. Paper trading validates logic and limit compliance, not profitability. Never assume that passing a paper test means the strategy will make money. It only means the agent follows instructions and respects the hard limits you set.

How does the safety stack fit together?

The prompt is the top layer. It gives the agent its worldview. Below it sits the API layer, which translates requests into normalized orders and checks them against scoped permissions. Below that sits the wallet layer, which holds funds in an address the owner controls and only allows withdrawals to pre-approved addresses. The agent can spend within limits but can never withdraw to itself.

Each layer has a distinct role. The prompt optimizes for strategy. The API optimizes for enforcement. The wallet optimizes for custody. When these layers blur, risk increases. A prompt should never be asked to do the work of a kill switch or a budget cap. Think of the stack as a series of gates. The prompt generates intent. The API gate checks that intent against budget caps, position limits, and allowed markets. The wallet gate checks that the resulting settlement does not move funds to an unauthorized address. Only if all three gates open does a trade execute. If any gate closes, the flow stops. This means the owner has multiple independent chances to catch a mistake. The agent might misinterpret a signal at the prompt layer, but the API layer catches the bad order. The API might have a bug, but the wallet layer still controls the final movement of funds. This redundancy is why noncustodial architecture matters. The agent is a reasoning tool, not a trusted owner of capital. The human owner retains ultimate control through scoped keys, withdrawal whitelists, and the kill switch. The prompt is just one component in this larger system. Treating it as such keeps expectations realistic and capital safe.