In week one, the agent should generate orders in shadow mode while a person checks its decisions against market data and risk limits. By week six, it may place small live orders without a person watching, but only if the team has measured its failure modes and can stop, reconcile and restart it safely. The calendar is not the control. Evidence is.
Consider a small team building an intraday strategy for liquid shares, with a $100,000 account and a broker API. The figures below describe a working example, not a tested result or a universal prescription.
A different asset, holding period or venue can require very different limits. The useful question is whether each boundary is explicit, enforceable and observable.
Week one: define what the agent is allowed to do
Start by writing a permission envelope before connecting an order endpoint. Specify instruments, sessions, order types, maximum position, maximum gross exposure and whether the agent may hold overnight.
Define what it must do when a required input is missing. If the answer is not in the specification, the default should be to stop opening risk.
For the example account, the first live envelope might allow a maximum $2,000 order notional, $10,000 gross exposure and no short positions. A strategy may have a target risk of 0.25% of equity per trade, or $250, but that is not the same as allowing $250 of notional.
Define whether risk means stop-loss exposure, estimated volatility or another measurable quantity. A stop order does not guarantee the loss will be capped at that level during a gap or fast market.
Set limits at more than one layer. Strategy code can calculate a proposed size, but an independent risk service should check the order before submission.
The broker's own buying-power and order validations are a further boundary, not a replacement for local controls. Keep the configuration versioned and record the values applied to each decision.
- Reject instruments outside an explicit allowlist, including symbols that differ by venue or contract month.
- Cap order quantity and notional separately, and round quantities to the instrument's permitted increment.
- Prevent new orders if the account position, cash balance or open-order state cannot be reconciled.
- Make session, currency and overnight permissions explicit rather than relying on strategy defaults.
Write down who can change each limit and how the change is reviewed. A limit edited in a running process is difficult to audit. Prefer a versioned configuration loaded at startup, with a recorded checksum and a restart or controlled reload procedure.
Weeks one and two: build checks around live failure modes
Risk limits need to apply to the order as it will be sent, not only to a strategy's intended trade. Before submission, validate symbol, side, quantity, order type, price bands and time-in-force. Then reserve exposure for working orders. If an account holds 40 shares and has a buy order for another 20, sizing the next order as if only 40 shares exist can exceed the position cap.
Use a durable order state machine. Assign a client order ID before sending, persist the request, and treat a timeout as an unknown outcome until broker state has been queried. Retrying a timed-out request with a new ID can create duplicate exposure. Reconcile open orders, executions, positions and cash after connection recovery. A cancel request is not proof that an order is cancelled, and a partial fill can arrive while the cancellation is in flight.
Data checks should be independent of strategy logic. Reject a signal if its timestamp is too old, the market is closed, the quote is crossed unexpectedly, or required fields are absent.
Record exchange time and receipt time so that feed delay is visible. For a liquid intraday strategy, a stale threshold might be one or two seconds; a fast futures strategy may need a much tighter limit. These are starting points, not venue guarantees.
A safe default is not "keep trading with the last known value". It is "do not add risk until state is known".
Build a small set of hard stops and make their effects precise. A daily loss stop should say whether it uses realised P&L, mark-to-market P&L, fees and open positions.
Specify whether the stop blocks new orders, cancels working orders, or also attempts to flatten. Automatic liquidation can itself create slippage, so the response must match the strategy and market.
Use ranges as starting points, not universal limits
The table gives typical market ranges that teams may use as initial test values for liquid instruments. These are not audited results for any company, and they should not be copied without checking account size, product, venue rules, volatility and API constraints. A broker can impose stricter limits, while a strategy may need tighter ones.
| Control | Typical starting range | What to test |
|---|---|---|
| Risk per trade | 0.1% to 0.5% of equity | Gap losses, stop slippage and correlated positions |
| Daily loss stop | 0.5% to 2% of equity | Whether it includes open P&L, fees and pending fills |
| Gross exposure | 1x to 3x equity | Margin use and simultaneous signals across instruments |
| Stale quote threshold | 1 to 5 seconds for many liquid share strategies | Feed delay, market state and strategy reaction time |
| Repeated reject trigger | 3 to 10 consecutive rejects | Whether rejects indicate a bad request, permission issue or venue outage |
| Slippage alert | 2x to 5x expected cost, or a configured basis-point ceiling | Spread, volatility, order type and partial fills |
Limits interact. A daily loss stop of 1% does little if the agent can open many correlated positions, while a per-order cap does little if it can submit orders repeatedly. Model total exposure across positions and working orders. Include other processes using the same account where possible, or the agent may assume capital is free when it is already committed.
Separate a warning from a blocking condition. A warning can log an approach to the limit; a hard limit must reject the request before it reaches the broker.
Make the block decision auditable, with the input values, rule version and reason code. For paper testing, an agentic paper-trading environment can help exercise order flows, but simulated fills still need comparison with live venue behaviour.
Weeks three to five: test the limits under stress
Run the agent first in shadow mode, where it records intended orders but sends none. Compare each decision with the data available at that instant, not with a cleaned-up historical bar.
Then use paper trading to check request handling, state transitions and the risk service. A simulator cannot establish that real liquidity, queue position or market impact will match.
Use scenarios that force the software into uncomfortable states. Include a disconnected socket after submission, a delayed fill report, a partial fill followed by a cancel, a stale quote, a rejected order, a restart with working orders, and a market halt.
Also test two independent signals arriving at once. The risk service should serialise or atomically reserve exposure so both do not pass against the same remaining capacity.
- Replay recorded market events and confirm the agent refuses orders when required data is late or inconsistent.
- Inject broker timeouts and duplicate messages, then verify that recovery does not create a second order or lose a fill.
- Run a simulated loss-stop breach and check that the configured response matches the written policy.
- Compare proposed size with account positions and open orders after every restart and reconciliation cycle.
- Review logs and alerts as if the operator were away, including what is missing when the alerting service fails.
Track distributions, not just averages. For execution, measure spread paid, slippage against a timestamped reference, fill rate, rejection rate and time to acknowledgement. Segment by instrument, order type, time of day and volatility regime. If paper fills look consistently better than expected live fills, reduce size or widen cost assumptions before allowing unattended orders.
Keep test cases reproducible. Store the strategy version, data snapshot, configuration, broker response and resulting account state. If the same input produces a different order after a code change, the difference should be explainable. Teams exploring paper trading for trading agents should treat the simulator as one test layer, not as proof that unattended live execution is safe.
Week six: allow limited live operation and define recovery
Promotion to live should be gradual. Begin with one instrument, one session and a small fraction of intended size. For the example account, that could mean a $500 notional cap and a maximum loss stop of $100 for the initial live window, with a person available to intervene. Increase one constraint at a time only after reconciliation, order handling and cost measurements remain within pre-set tolerances.
Unattended does not mean unobservable. The agent needs a heartbeat, last market-data timestamp, connection state, position and open-order summary, daily P&L, exposure headroom and last successful reconciliation. Alert on changes that require action, not every routine event. Send a distinct high-priority alert for a hard stop, unknown order state or mismatch between broker and local positions.
Define stop and restart authority before deployment. A stop command should block new orders immediately, then follow the stated policy for working orders and positions. Restart should not restore an old in-memory view of the account.
It should fetch broker state, reconcile it against persisted events, load the approved configuration and pass health checks before opening risk again. If reconciliation remains unresolved, stay stopped.
Review the system on a fixed cadence and after any material incident. Check limit breaches, rejects, unexpected position changes, slippage tails and data gaps.
Change thresholds through a reviewed configuration update, then rerun the relevant tests. If a strategy needs frequent manual exceptions to stay operational, the envelope or the strategy may be wrong.
Bring one concrete scenario to the next team meeting: the broker accepts an order, the connection drops before acknowledgement, and the agent restarts with a stale position cache. Which component owns the truth, what prevents duplicate exposure, and what observable evidence must be present before it is allowed to trade again?
Frequently Asked Questions
What guardrails should an unattended trading agent have?
At minimum, define allowed instruments, order size, position and exposure caps, loss limits, data freshness checks and a stop procedure. Add persistent order state and account reconciliation so a restart cannot act on an outdated view.
How large should a trading agent's daily loss limit be?
There is no universal figure. Typical starting ranges for some liquid strategies are 0.5% to 2% of equity, but the limit should reflect strategy volatility, account size, correlated exposure and whether open P&L and fees are included.
How should an agent handle a broker API timeout after submitting an order?
Treat the outcome as unknown, not as a failed order. Query broker order and execution state using the original client order ID before deciding whether any retry is safe.
Can paper trading prove an agent is safe for live trading?
No. Paper trading can test request handling, state transitions and risk checks, but simulated fills may not reflect queue position, liquidity, market impact or venue outages. Compare its assumptions with live execution data and retain conservative limits.
What should happen when a trading agent restarts?
It should fetch positions, open orders and executions from the broker, reconcile them with persisted state, and confirm its approved configuration and data connections. It should remain blocked from opening risk if account state is unresolved.
