How an AI agent trades stocks within hard limits it cannot cross

An AI agent can trade stocks through Felix by operating within a safety perimeter that the owner defines before any order is placed. Hard limits are constraints baked into the API keys and smart contract layer that the agent cannot override, modify, or disable. These boundaries include dollar-denominated spend caps, maximum position sizes, and immutable withdrawal addresses. If the agent attempts to exceed any boundary, the order is rejected before it reaches a stock broker.

What counts as a hard limit for a stock trading agent?

A hard limit is a boundary enforced by the Felix infrastructure, not a suggestion inside the agent's prompt or a line in its system instructions. The agent may reason about risk, but it does not decide whether to obey the limit. The limit is encoded in the key itself and checked by the API on every request. There are several categories of hard limit that work together to create a complete safety perimeter.

• ·Budget cap: the total notional value the agent can deploy across all stock positions, denominated in US dollars.
• ·Position limit: the maximum dollar value allowed in any single ticker at one time.
• ·Single-order limit: the largest individual trade the agent can submit in one request.
• ·Withdrawal whitelist: owner-approved addresses that the agent cannot modify or circumvent.
• ·Kill switch: an external control that flattens positions and revokes the agent's key permanently.

These limits are configured by the owner before the agent receives its key. Once active, they persist until the owner explicitly changes them, which requires generating a new scoped key. The agent cannot negotiate, reason around, or socially engineer its way past them. This is the difference between a hard limit and a soft guideline. While Felix provides one key and one API for five market types, this walkthrough focuses on the stock-specific safety workflow.

How do you set the safety perimeter before trading?

Setting the perimeter is a pre-trade task that the owner completes through the Felix dashboard or a direct configuration call. The first step is to decide the total budget cap. This should be an amount you are genuinely willing to lose, because trading can lose money, including everything. Do not use leverage you cannot afford to pay back, and do not size the cap based on hypothetical returns. The cap is a disaster boundary, not a target.

Second, set a per-position limit as a fraction of the total budget. A common starting point is a modest percentage, though the exact number depends on your risk tolerance and the volatility of the stocks involved. Third, define a single-order limit to prevent large individual trades that might move the market against you or expose you to gap risk on the next open. Fourth, configure an exit plan, which may include time-based flattening or drawdown thresholds that trigger a halt. These parameters overlap with spend caps and drawdown limits, which deserve careful calibration separate from the agent's strategy. Fifth, if you are using paper trading, run the agent through varied market conditions to observe how it behaves when it approaches boundaries. Common paper trading mistakes often involve testing only for profit and ignoring how the agent reacts to rejections. Only after the agent consistently respects the perimeter in simulation should you authorize a live key, which is a deliberate, manual action the owner must take.

How does the order flow work inside the boundary?

When the agent decides to trade, it formulates an intent in plain US dollars. For example, it might request to buy five thousand dollars of a particular stock. The Felix API receives this intent, whether through an MCP tool or a direct REST call, and checks it against the active hard limits in a validation layer that the agent cannot bypass. The system looks at the remaining budget cap, the current position size for that ticker, and the single-order limit. It also checks whether the requested action would violate any drawdown halt or exit plan that the owner configured. If the requested trade would breach any of these, the API returns a rejection immediately and the order never reaches a stock broker. The agent receives the error and can log it, adjust its plan, or wait. It does not need to guess why the rejection occurred; the error message states the specific limit that was hit.

If the request passes validation, the API normalizes the dollar amount into the specific contract math required by the connected stock broker. This abstraction removes the need for the agent to understand lot sizes, fractional share rules, or venue-specific order types. The broker executes the trade, and the Felix ledger updates the remaining budget in real time. The exact request schema is in the docs; the shape looks like this.

{
  "intent": "buy",
  "symbol": "AAPL",
  "amount_usd": 5000,
  "api_key": "YOUR_KEY"
}

{
  "status": "rejected",
  "reason": "budget_cap_exceeded",
  "remaining_budget_usd": 1200
}

This is an illustrative shape. The actual field names and endpoint paths are documented at /docs. The key point is that the rejection happens inside the Felix layer, not at the broker. The agent does not need to reason about the limit; it is physically blocked.

What happens when the agent tries to cross a limit?

If the agent sends an order that violates a hard limit, the API returns a structured error and the order dies inside the infrastructure. The agent may retry with a smaller size, or it may pause and alert the owner, depending on how you have written its error-handling logic. Importantly, the limit is not a polite request. Even if the agent is prompted poorly, jailbroken, or experiences a reasoning failure, the infrastructure enforces the boundary. There is no sequence of words that can convince the API to release more budget. The limit is not part of the language model's context window; it is part of the key's permissions.

In addition to these passive limits, the owner retains an active kill switch. Triggering it immediately places flatten orders for all open stock positions and revokes the scoped API key. The agent cannot disable the kill switch, delay it, or hide positions from it. Once the key is revoked, the agent loses all trading authority until the owner explicitly issues a new one. This is a permanent revocation, not a temporary pause. If the agent has gone off course, or if markets are moving too fast for comfort, the kill switch is the final hard limit. It ensures that the owner, not the algorithm, retains ultimate control over the capital.

Why does non-custodial architecture matter for hard limits?

Hard limits are only as strong as the custody model beneath them. In a custodial setup, the agent or the platform holds the funds, and limits are essentially policy promises enforced by the same party that manages the money. In Felix, the funds remain in a wallet or brokerage account that the owner controls. The agent receives a scoped key that permits spending within the pre-defined cap, but the key cannot withdraw assets to an arbitrary address. The owner approves withdrawal destinations during setup, and the agent cannot modify that list. This means that even if the agent's key is compromised, the attacker's power is bounded by the remaining budget cap and the position limits. They cannot drain the account. They cannot alter the safety perimeter. They can only trade within the narrow window the owner already allowed.

This design matters because it removes the temptation to trust the agent. You do not need to believe that the agent is well behaved. You only need to verify that the key permissions are correct. The architecture is described in more detail in our overview of how an agent executes orders while you keep full custody. The combination of scoped keys and owner-controlled custody turns a theoretical safety policy into a physical guarantee. The owner holds the assets, the agent holds a limited spending authorization, and the infrastructure sits between them as an immutable referee.

How should you test and maintain the perimeter over time?

Testing should begin in paper trading, but the goal is not simply to see if the agent makes hypothetical profits. The goal is to verify that it handles rejection gracefully, that it does not spiral into repeated failed orders, and that it respects drawdown halts. Deliberately try to exceed a limit during testing to confirm the rejection is immediate and firm. Watch how the agent responds to a budget cap that is only slightly larger than its intended trade size. If it becomes stuck in a loop of retrying the same oversized order, you have a logic bug to fix before going live. Once you move to live trading, start with a budget cap you can afford to lose entirely, and keep the per-position limit tight. Monitor the first few trades closely to ensure the dollar-based sizing matches your intent.

Over time, review the agent's logs to see how often it bumps against boundaries. Frequent rejections may mean the strategy is too aggressive for the cap, or that the position limit is forcing awkward partial fills. You may also discover that you need to adjust sizing based on the volatility of individual stocks. Common position sizing mistakes often stem from setting limits too loose after a short winning streak. Limits should be tightened, not loosened, when markets become more volatile. Any increase in the budget cap or position limit requires explicit owner authorization of a new or updated key. This friction is intentional. It prevents emotional decisions to restore access after a small bounce.

Review the perimeter at regular intervals, not just when something goes wrong. A weekly or monthly audit of the agent's trading activity against its remaining budget is a reasonable baseline. Look for drift. Has the agent found a way to concentrate risk through multiple correlated positions that technically respect the per-position limit but effectively add up to a single large bet? If so, tighten the scope or add a correlation check. Also review after any major market event. If the agent hit its drawdown limit, analyze whether the limit was set appropriately or whether the strategy was flawed. If you lose confidence in the agent, use the kill switch immediately. Revocation is free and instant.