Should an AI write the prompts for your trading agent?

Manual prompt design means a developer writes the system instructions, tool descriptions, and safety constraints that govern how the agent interprets market data and places orders. Using an AI to design prompts means feeding a higher-level specification to a second model and asking it to produce the detailed instructions, guardrails, and reasoning steps. The core difference is that manual design keeps the safety logic explicit and human-readable, while AI-generated prompts trade some visibility for speed and variation. When real money is at stake, that trade-off deserves careful examination because a single ambiguous clause can lead to unintended positions or violated limits.

Why do developers still write trading prompts by hand?

Developers who build trading agents usually start with manual prompt engineering because money, once spent, cannot be recovered by a debugging session. A prompt is not just natural language decoration; it is the operational contract between the developer, the agent, and the trading API. When a developer writes the prompt directly, every clause about budget caps, position limits, and market scope is intentional and traceable. The developer knows exactly which tools the agent may call, which parameters are hardcoded, and which decisions require human confirmation. This matters because trading agents operate with financial instruments that can lose value quickly, including the entire allocated budget. The prompt must therefore be treated as a critical piece of infrastructure, not as a casual query to a chat interface.

Manual design also aligns cleanly with non-custodial safety architecture. In Felix, the API enforces scoped keys and owner-approved withdrawal addresses that the agent cannot override, but the prompt still needs to instruct the agent to respect those boundaries. A human-written prompt can reference the scoped API key model directly, reminding the agent that it operates within a specific budget and set of permissions. If the agent tries to reason around a limit, the prompt can contain explicit instructions to halt and wait. That level of precision is difficult to guarantee when an AI generates the prompt from a short summary, because the generator may not know which safety parameters are fixed in the API layer versus which belong in the prompt. A developer who writes the prompt knows the difference and can keep the two layers distinct.

When does using an AI to write prompts make sense?

AI-generated prompts excel during experimentation and paper trading, where speed matters more than final precision. A developer can describe a strategy in broad terms, ask an AI to produce a structured prompt with reasoning steps, and test the result in a simulated environment within minutes. This rapid iteration helps explore how an agent might handle multi-market scenarios, such as moving between a stock broker and a perps venue, without the developer writing every conditional branch by hand. The generated prompt can serve as a first draft that exposes edge cases the developer had not considered, like how to handle weekends when certain markets are closed or how to sequence orders across venues with different settlement timing. For teams building many agent variants, automated prompt generation scales better than hand-writing each one, allowing a small group to test diverse strategies in parallel.

However, the generated draft should remain confined to paper trading mistakes territory until a human reviews it. The generator does not know the developer's risk tolerance, the specific drawdown limits configured in the API, or whether the owner has authorized live trading for a given key. It may produce elegant reasoning chains that assume access to markets or data feeds that are not actually connected. The value of AI generation is therefore in ideation and structure, not in final authorization. Developers who treat generated prompts as production-ready without audit often discover that the agent interprets ambiguous wording in expensive ways. A phrase like aggressive sizing might mean one thing to the generator and something far riskier to the agent when it sees a volatile price move.

What can go wrong with AI-generated trading prompts?

The most immediate risk is that the AI prompt generator hallucinates parameters or omits critical guardrails. Suppose the developer asks for a prompt that trades based on momentum. The generator might include instructions to increase position size after losses, which contradicts sound risk management, or it might fail to mention the hard budget cap that the API enforces. Because the generated text looks coherent and professionally structured, a busy developer might miss the absence of a kill-switch clause or a requirement to flatten positions before a weekend. The prompt becomes a silent liability that sits between the agent and the market, translating good intentions into dangerous actions.

• ·The generator may invent market-specific logic that does not match the API's dollar-based order sizing model, leading the agent to request impossible or misaligned trade sizes.
• ·It can omit instructions about the panic switch or revoke mechanism that the owner relies on, leaving the agent without clear guidance on when to stop.
• ·It may phrase stop-loss rules in ambiguous language that the agent interprets too late or too early, causing unintended exits or excessive losses.
• ·It can produce prompts that assume custodial access, even though the infrastructure is non-custodial by design, confusing the agent about who controls the funds.
• ·It might fail to distinguish between paper trading and live trading authorization, risking accidental real orders before the strategy has been validated.

Each of these errors is recoverable if the developer treats the output as raw material, but dangerous if deployed directly. Trading can lose money, including everything, and a poorly worded prompt is one path to that outcome. The AI generator has no financial stake and no awareness of the API's safety controls. It produces text that is statistically likely to follow the developer's request, not text that is financially safe. That gap between linguistic coherence and financial safety is the central danger. A prompt that reads well to a human reviewer may still contain logical gaps that an agent exploits when it encounters fast market conditions.

How do teams combine manual review with AI generation?

The most reliable workflows treat AI generation as a drafting tool and manual review as a mandatory gate. A developer might ask an AI to generate three variations of a prompt for a cross-market strategy, then select the most promising draft and manually inject the safety layer. That safety layer includes explicit references to the spend caps and drawdown limits configured in the API, clear instructions about the maximum single order size, and a restatement that the agent cannot approve new withdrawal addresses. The developer keeps the structural reasoning that the AI provided but replaces any vague financial language with exact parameters. This process is slower than fully automated generation, but it preserves the non-custodial guarantees that make agentic trading viable.

This hybrid approach also helps with position sizing from first principles. An AI might generate a prompt that says allocate a reasonable portion of the portfolio to each trade. A developer reviewing that draft would replace the vague phrase with a concrete rule tied to the API's dollar-based sizing, such as each order must be between fifty and five hundred dollars, and total exposure across all positions must not exceed two thousand dollars. The API normalizes venue-specific contract math, but the prompt must still express the human owner's intent in terms the agent can follow consistently. Only the developer knows what reasonable means for their specific account, and only a manual review can turn that subjective concept into an objective constraint that the agent understands.

What does a hybrid workflow look like in practice?

In practice, a developer might maintain a template that separates strategy reasoning from safety constants. The strategy section, which describes how to evaluate signals across stocks and prediction markets, can be generated or refined by an AI. The safety section, which contains budget references, kill-switch triggers, and authorization checks, is maintained manually and never overwritten by the generator. When the developer wants to test a new idea, they update the strategy section, run the prompt through paper trading, and only promote it to live trading after verifying that the safety section remains intact. This separation of concerns mirrors good software engineering: business logic can evolve quickly, while security policy stays stable.

{
  "strategy_prompt": "GENERATED_BY_AI: evaluate momentum across available markets...",
  "safety_prompt": "MANUAL_REVIEW: max_spend_usd 1000, kill_switch true, allowed_markets only...",
  "api_key": "YOUR_KEY"
}

The exact request schema is in the docs; the shape looks like this. The key point is that the safety constants live in a separate, human-controlled field that the AI generator does not touch. If the generated strategy prompt drifts or contradicts the safety prompt, the API's underlying controls still enforce the hard limits. The prompt helps the agent make good decisions, but the API prevents catastrophic ones. This redundancy matters because no prompt, however carefully written, is a substitute for non-custodial enforcement. Even a hybrid workflow can fail if the developer becomes lazy and lets the AI gradually creep into the safety section over successive iterations.

How does the underlying API safety model fit in?

Whether prompts are written by hand or generated by an AI, the Felix safety model operates underneath them as a fixed boundary. Scoped keys limit what the agent can do, budget caps prevent runaway spending, and the panic switch flattens positions and revokes access regardless of what the prompt says. The prompt is the agent's instruction manual; the API is the building's fire door. Developers who rely solely on prompt-based safety are trusting a language model to self-regulate, which is not a sound financial strategy. The most robust deployments use manual or hybrid prompt design to align the agent's behavior with the API's immutable constraints. Trading can lose money, including everything, but clear separation between generated strategy and hardcoded safety reduces the chance that a wording error becomes a balance error. The API does not care how elegant the prompt is; it cares about the signed request and the owner-approved limits.