An AI trading agent is an action loop
An AI trading agent is software that observes information, forms or selects a plan, uses tools and checks the result across multiple steps. The important distinction is not whether it has a chat box. It is whether the system can move from analysis to consequential action without a person approving every step.
That authority may be narrow: cancel an order when a risk limit is breached. It may be broad: choose instruments, rebalance a portfolio and manage collateral. The broader the authority, the less useful it is to evaluate only the model. Credentials, deterministic policies, execution adapters, reconciliation and human intervention become part of the product.
Agent, assistant, signal or bot?
| Category | What it produces | Who authorizes the action? |
|---|---|---|
| Signal | A timestamped suggestion such as buy, sell or hold | The user decides and acts |
| Assistant | Analysis or a draft order | The user confirms each consequential step |
| Rule-based bot | Orders triggered by predefined conditions | Rules authorize actions in advance |
| AI trading agent | A changing sequence of tool calls toward a goal | A mandate and policy authorize bounded actions |
| Managed product | Portfolio management as a service | The legal and technical product structure governs authority |
These labels describe different layers and can overlap. A managed product may use agents internally; a trading bot may use a model to classify market state. Start with the broader AI-for-trading taxonomy if the product's action boundary is unclear.
The seven-part agent control loop
A language model can help interpret context or select among approved actions. It should not be the only system deciding whether an order is legal, affordable or inside the portfolio mandate. Hard limits need code-level enforcement after the proposal and before execution.
What a safe intent looks like
“Buy more ETH” is not an executable specification. A reviewable intent includes the instrument, side, maximum notional, execution window, price protection, reason, evidence timestamps and a unique action identifier. For derivatives, it also includes leverage, collateral impact and liquidation constraints.
intent → policy decision → order request → venue response → reconciled portfolio state Every arrow can fail. The venue may accept an order but return a timeout. A second attempt can create duplicate exposure unless the request is idempotent or the system checks open orders first. A fill may be partial. A blockchain transaction may remain pending while market conditions change. The agent must respond to observed state, not assume its last instruction succeeded.
Controls that belong outside the model
- Least privilege: credentials permit only required venues, accounts, assets and actions.
- Exposure limits: position, order, concentration, leverage and loss limits are enforced in code.
- Freshness limits: stale prices, balances, model outputs and venue status are rejected.
- Price protection: orders have maximum slippage, limit prices or minimum received amounts.
- Approval thresholds: unusual size, new assets or withdrawals require a human or separate signer.
- Idempotency: retries cannot silently duplicate an order or transaction.
- Reconciliation: account and onchain state are compared with the agent's internal record.
- Emergency control: an independent operator can pause execution and revoke authority.
This is the systems boundary described in the automated trading systems guide. Calling the decision layer an agent does not remove established requirements for supervision, testing and operational control.
A failure example: the news is right, the trade is wrong
Suppose an agent correctly identifies a negative announcement and proposes reducing a position. The source may be authentic, yet the proposal can still be unsafe: the market price may have already moved, the account may have an open hedge, liquidity may be thin, or a large market order may create more loss than waiting.
A controlled path checks the source timestamp, current positions, open orders, liquidity and modeled execution cost. It expires the proposal quickly. Policy may resize the action, switch to a limit order, request approval or reject it. This is why factual accuracy, strategy quality and execution quality require separate tests.
Agent-specific failure modes
Hallucinated or overextended evidence
A source may be real while the conclusion is unsupported. Evaluation should test whether each material claim is faithful to the source, whether contrary evidence was omitted and whether the evidence is sufficient for the proposed action. A fluent explanation is not a substitute for those checks.
Agent hijacking
A tool-using agent consumes untrusted material: websites, token descriptions, news, messages and API responses. Malicious instructions embedded in that material can redirect a vulnerable agent. NIST's agent-hijacking work describes this as a separation problem between trusted instructions and untrusted data. Restricting tools and enforcing policy after model output reduces the consequence of a successful manipulation.
Goal drift
“Increase return” can encourage concentration or leverage unless the mandate defines the permitted risk. Objectives need explicit constraints and conflict rules. When two goals disagree—reduce drawdown and avoid realizing a loss, for example—the system should follow a documented priority or escalate.
Hidden delegation
An agent may call another model, service, smart contract or bridge. Each dependency adds data, availability and permission risk. The execution record should identify the versions and endpoints that materially affected the action, not only the name of the front-end agent.
Evaluation that measures the demo
A benchmark can reward completion while missing unsafe shortcuts. Test rejected actions, repeated attack attempts, regime changes, missing data, contradictory sources and venue failures. Then run shadow mode on live data before allowing bounded capital. A passing backtest establishes neither reliable tool use nor live execution quality.
What to ask before granting authority
| Question | Strong evidence | Weak answer |
|---|---|---|
| What can it do? | Exact account, venue, asset, function and limit list | “It trades autonomously” |
| Who holds the keys? | Named custody path, signer roles and revocation process | “Bank-grade security” |
| How is risk enforced? | Independent policy checks plus recorded rejections | Instructions inside the prompt |
| How was it tested? | Versioned scenarios, failure tests, shadow results and bounded-live status | A selected profit chart |
| What happens on uncertainty? | Expiry, safe state, pause and human escalation rules | “The model adapts” |
| Can actions be verified? | Linked intent, policy, order, fill and portfolio records | A model-generated explanation |
Logs, proofs and performance are different evidence
An intent log shows what the agent proposed. A policy record shows what a control allowed. An order or transaction record shows what was submitted. A fill, receipt or state proof can show what happened at an execution layer. None of these alone proves that the strategy was profitable, suitable or complete.
For onchain actions, continue to what trade proofs can and cannot prove. For portfolio authority, custody and exit mechanics, read onchain asset management. For AI operating directly in DeFi workflows, use the DeFAI guide.
Sources and scope
- CFTC Technology Advisory Committee — Artificial Intelligence in Financial Markets
- NIST — AI Risk Management Framework
- NIST — Building Evaluation Probes into Agentic AI
- NIST — Strengthening AI Agent Hijacking Evaluations
- FINRA — AI in the Securities Industry: Key Challenges
- Onchain Off Emotion editorial methodology
The control loop and examples are editorial evaluation frameworks. They do not certify a product, promise investment performance or establish the availability of a specific product feature.