How agentic trading works from first principles

Agentic trading is not a strategy layer bolted onto a public API. It is an execution architecture built from the ground up to let an autonomous system reason about markets without ever gaining unbounded access to capital. The foundation is a set of cryptographic and financial constraints that sit between the agent and the market, normalizing venue logic into a single permissioned interface. Before the agent evaluates a single price or submits its first order, the owner has already defined what it can touch, how much it can lose, and how to stop it entirely.

What makes trading agentic rather than automated?

Traditional automation relies on deterministic rules. A webhook watches a price feed, and when a threshold crosses, it fires a market order. The logic is static, the state space is narrow, and the behavior is predictable because it is explicitly programmed. An agent, by contrast, interprets ambiguous state. It might read a news feed, compare implied volatility across an options venue and a perps venue, and decide whether to hedge or flatten. The model is stochastic, and its reasoning changes with context. This creates an architectural problem that simple automation never faces: how do you let a system think freely while guaranteeing that its actions remain bounded?

The architecture solves this by treating the agent as an untrusted reasoning process. Every action the agent proposes must pass through a deterministic policy engine that validates the intent against owner-defined constraints. The agent reasons, but the infrastructure permits. This separation of cognition from execution is the defining shift from a script to an agent. Where a webhook simply executes, an agent proposes and the policy engine validates. ai-agents-replace-webhooks-trading-automation The developer is no longer writing a rule engine. Instead, they are designing a prompt that proposes actions to a rule engine that they do not control and cannot override. The agent does not "have access" to the market in the traditional sense. It has the ability to request actions from a gatekeeper that evaluates every request against immutable financial and cryptographic limits. If the reasoning and execution layers were not separated, a prompt injection or model hallucination could attempt to increase leverage or move funds. By separating them, the worst possible outcome is a rejected order.

How does authorization work before the first order?

The first principle of the architecture is that authorization precedes action. The owner generates a scoped key that carries explicit spend caps, allowed market types, and permitted symbols. This key is not a root credential. It cannot withdraw funds to arbitrary addresses. It cannot change its own limits. It cannot extend its own expiry. It can only place orders within the boundary set at creation. The owner retains the underlying wallet, and the funds never leave the owner’s control. The scoped key is a delegation of trading authority, not a transfer of custody.

If the agent's host is compromised, the owner can revoke the key without moving funds. The funds remain in the owner’s wallet, and the agent's key becomes useless the moment it is revoked. This is the difference between custodial trading, where an API secret might control withdrawals, and non-custodial agentic trading, where the secret can only spend within a sandbox. The authorization step that enables live trading is a deliberate human gate, not a configuration toggle. Once revoked, re-authorization requires a new human action. It cannot be automated by the agent itself.

Until live authorization is completed, the agent operates in a paper environment where orders are tracked against real market data but never sent to a live venue. The wallet remains non-custodial by construction; the agent never holds the private keys to the underlying capital, and even a full compromise of the agent’s host cannot move funds to an unapproved address. ai-agents-trade-without-custody

How does the API normalize five different markets?

Stocks, crypto, perpetual futures, options, and prediction markets each have distinct contract specifications, margin models, and settlement cycles. A stock broker might quote in whole shares with a two-day settlement. A perps venue might use notional contracts with continuous funding rates. An options venue might quote in strike and expiry matrices with delta and gamma profiles. A prediction market might use binary shares or continuous limit order books. Without normalization, an agent would need to encode five different trading grammars and maintain five different state machines.

The API abstracts this into a single interface where every order is sized in plain US dollars. The agent sends an intent: buy a certain dollar amount of exposure. The infrastructure translates that intent into the venue-specific contract math, handles rounding, collateral checks, and margin requirements. For example, an agent requesting $1,000 of long exposure might receive five shares of a stock, a fractional notional perp contract, or a delta-adjusted options spread. The agent does not need to know the conversion rate. It expresses a directional view with a dollar budget, and the execution layer handles the rest.

This normalization also applies to reading data. When the agent queries its position, it receives a unified view of exposure in dollars across all five market types. It does not need to reconcile shares against contracts against delta. It sees a single portfolio denominated in the currency it understands. This eliminates an entire class of bugs where agents miscalculate contract size, which is a common source of unintended leverage in manual API trading. It also means the agent can rebalance across market types without rewriting its core logic. An agent might decide to reduce equity exposure and increase a hedge in a perps venue. It simply sends two dollar-denominated intents. The infrastructure handles the share count, the contract notional, and the cross-margin implications. The agent reasons about portfolio allocation in dollar terms, while the architecture handles the mechanics of settlement.

What keeps the agent from exceeding its bounds?

Hard limits are not an afterthought. They are load-bearing walls in the architecture. Budget caps define the maximum notional value the agent can deploy across all positions. Position limits restrict concentration in any single symbol or market type. Exit plans define automatic take-profit or stop-loss logic that runs at the infrastructure level without the agent's continued participation. A panic switch, accessible to the owner at any time, flattens all positions and permanently revokes the agent's key.

These controls are enforced by the infrastructure, not inside the agent's prompt. Even if the model hallucinates a strategy, or if a prompt is injected with malicious instructions, the policy engine rejects any order that violates the pre-set boundary. The prompt is the first layer of guidance, the model's own reasoning is the second, and the immutable policy engine is the third. prompt-design-hard-limits-trading-agents This is the difference between asking an AI to be careful and making it physically impossible to exceed a limit.

The panic switch is worth examining closely. It does not merely pause the agent. It submits closing orders to flatten all open positions and then revokes the scoped key. This matters because a stopped agent that still holds open positions is still exposed to market risk. Flattening removes the risk. Exit plans operate similarly: they are server-side triggers that run even if the agent's host is offline, has crashed, or has lost network connectivity. The scoped keys themselves can carry time limits, so a key might naturally expire after a set period unless the owner explicitly renews it. Trading can lose money, including everything, but the architecture ensures that losses happen only within the owner-defined perimeter and that the owner can terminate exposure immediately.

How do developers connect an agent to this infrastructure?

Developers integrate through two paths. The first is a REST API that accepts orders, cancels, and portfolio queries in a normalized schema. The second is an MCP server that exposes trading tools directly to compatible AI clients such as Claude or Cursor. In both cases, the agent authenticates with the same scoped key, so the permission model is identical regardless of the entry point.

The MCP path is useful for prototyping and interactive agents. The LLM sees tools like place_order or get_position and invokes them as part of its reasoning loop. The tool descriptions themselves include the hard limits, so the model plans within visible constraints. From the agent's perspective, the tools are stateless. The infrastructure holds the canonical state of positions, budgets, and orders. The REST path is useful for deploying persistent services where the developer orchestrates the calls directly and manages their own scheduling logic, such as cron jobs or event-driven systems. Both paths lead to the same policy engine, so a prototype built with MCP can migrate to a production REST service without changing the risk model.

The exact request schema is in the docs; the shape looks like this:

{
  "key": "YOUR_KEY",
  "intent": {
    "market": "perps",
    "direction": "long",
    "budget_usd": 500,
    "symbol": "ETH"
  },
  "risk_context": {
    "max_position_usd": 2000,
    "kill_switch_enabled": true
  }
}

The response contains the executed notional, the venue-specific contract details, and the remaining budget. Because normalization happens server-side, the agent's code stays simple. It does not need to manage exchange IDs, margin fractions, or settlement timing.

Why does paper trading matter before live authorization?

Paper trading mirrors the live execution path without submitting orders to real venues. It lets the owner observe how the agent behaves when it sees real market data, experiences simulated slippage, and attempts to resize positions across different market types. This is not a guarantee of future performance. Markets can change, and simulated fills do not always match live liquidity. But paper trading reveals whether the agent's reasoning loop interacts correctly with the hard limits, whether the exit plans trigger as expected, and whether the dollar sizing logic produces the intended exposure.

The primary value of paper trading is testing the integration, not validating a strategy. It shows whether the agent respects the kill switch, whether it handles rejected orders gracefully, and whether it misinterprets the normalized market data. It also lets the owner test the panic switch in a safe environment, ensuring that the flattening logic behaves correctly before any real capital is deployed. These are architectural concerns. A strategy that works in simulation might fail in live markets due to latency or liquidity, but an agent that crashes when it receives a rejection will certainly fail.

Moving to live trading requires an explicit owner authorization of the key. This is a deliberate human gate that forces a review of the agent's behavior, the scope of the key, and the size of the budget. Skipping paper trading often means discovering architectural misalignments, not just strategy flaws, with real money at risk. paper-trading-ai-agent-beginner-misconceptions Trading can lose money, and the transition from simulation to live markets should be treated as a deployment of constrained infrastructure, not just the flip of a switch.