Key Elements of an Operational Runbook for AI Trading Agents
Learn the essential sections, controls, and safety checks to include in a runbook that guides reliable operation of AI‑driven trading agents.
Produced with automation, then checked by deterministic quality rules and an independent source-grounded review before publication.
- 01Define clear data‑quality checks and source verification before any order is sent.
- 02Document key scopes, limits, and expiry policies to enforce owner‑authorized controls.
- 03Include an emergency‑stop procedure that revokes agent keys and pauses activity.
- 04Specify reconciliation steps to handle timeouts, partial fills, and error states.
- 05Outline regular review cycles for permissions, limits, and performance logs.
An operational runbook for AI trading agents should lay out every step from market‑data intake to post‑trade reconciliation. It must describe who can act, what limits apply, and how to halt activity safely. The document serves as a single source of truth for operators, auditors, and developers.
What data checks belong in the runbook?
Accurate market data is the foundation of any trading decision. The runbook must require each feed to expose its source, timestamp, freshness indicator, and any coverage warnings. Missing or unverified price information should trigger a pause rather than being treated as zero.
- Verify source authenticity for each venue.
- Record timestamp and freshness for every price tick.
- Log coverage gaps or warning flags.
- Define fallback behavior when data is stale or incomplete.
How should key management be documented?
Agent keys operate under owner‑authorized scopes and limits. The runbook must list each key’s purpose, allowed order size, daily notional, daily loss cap, expiry, and any custom policy fields. Remember that a trade‑scoped key cannot withdraw funds; withdrawal requires a separate owner‑signed intent.
- Scope definition (order placement only, no withdrawals).
- Owner‑signed limits for size, notional, loss, and expiry.
- Procedures for rotating or revoking keys.
- Audit log requirements for every key use.
What emergency‑stop procedures are required?
An emergency stop must cancel managed activity where possible and revoke the calling key. It does not automatically close open positions or revoke existing token allowances; those actions need separate owner review.
- Trigger conditions (e.g., data outage, limit breach).
- Steps to revoke the active agent key.
- Checklist for owner to assess open positions.
- Documentation of any manual closures performed.
How do you handle order states and reconciliation?
Durable mutation identity and explicit error states are essential because a timeout does not prove an order failed. The runbook should map each possible order state and outline reconciliation steps for mismatches.
- Enumerate order states (submitted, acknowledged, filled, partially filled, rejected, cancelled).
- Record mutation IDs for every order request.
- Define timeout handling and subsequent verification queries.
- Reconcile account balances against expected outcomes.
How often should permissions and limits be reviewed?
Regular reviews reduce deviation between documented policy and actual behavior. The runbook must set a cadence for auditing key scopes, owner‑signed limits, and usage logs.
- Monthly audit of key permissions and expiry dates.
- Quarterly review of daily loss and notional limits.
- Immediate review after any security incident.
- Update documentation to reflect any changes.
Related best‑practice resources
- Daily loss limits shape safe AI trading agents
- What order states should an AI trading agent understand?
- Designing effective exit plans for AI trading agents
A runbook is only as good as its discipline; regular reviews and strict adherence to documented limits are essential for safe AI‑driven trading.
Why must market data include freshness warnings?
Stale or missing data can lead to incorrect orders; the runbook should require a pause until reliable data is restored.
Can an emergency stop close all open positions automatically?
No. The stop revokes the agent key and pauses activity, but closing positions requires a separate owner decision and action.
Frequently asked questions
It provides a documented, repeatable process that covers data validation, key controls, emergency actions, and reconciliation to reduce operational risk.
By defining the key’s scope in the runbook and enforcing that withdrawals need a distinct owner‑signed intent.
Do not assume failure; use the mutation ID to query the venue, verify the order state, and reconcile any differences before proceeding.
Key rotation should follow the expiry policy documented in the runbook and be reviewed at least monthly for any emerging risks.
Regular reviews keep documented policy aligned with actual behavior and help detect deviation or security gaps early.
When data outages, limit breaches, or security incidents occur, the stop revokes the active key and pauses further activity.
Sources and verification
Product claims in this article were checked against these first-party references. Runtime status remains authoritative for current availability.
- Felix documentationfirst party
- Felix machine referencefirst party
- Felix runtime statuslive status
Build with Felix now.
Felix infrastructure is live through MCP and the API. The full trading app launches September 17.
A decision log captures every step an AI trading agent takes, providing transparency, auditability, and a safety net for operators. This guide outlines the key fields and best practices for building a robust log.
Understanding how to prove an AI agent’s trade execution is essential for reliable operations. This article outlines the evidence required, from order confirmations to market data timestamps, and explains how to handle uncertainty and errors.