How to start executing orders with an AI agent as a developer

Developers start executing orders with an AI agent by creating a scoped API key, defining a budget cap in plain US dollars, and connecting the agent through MCP tools or a REST endpoint. The agent submits orders against a paper trading environment first, and the owner must explicitly authorize live keys before real money is at risk. All funds remain in a wallet the owner controls, because the agent can spend within preset limits but cannot withdraw to itself or change approved withdrawal addresses.

What do you need before your agent places its first trade?

Before an agent can execute an order, you need a wallet where funds remain under your control, an API key scoped to specific actions, and a clear budget cap. The infrastructure should be non-custodial by construction, meaning the agent receives permission to trade but never holds or withdraws assets to its own addresses. You will also need to decide which market types you want to access, such as stocks through a stock broker, crypto on chain, perpetual futures at a perps venue, options at an options venue, or outcomes at a prediction market. Each market type has different settlement mechanics, but a unified API should abstract the contract math so you size orders in dollars rather than lot sizes or contract multipliers. You should start with paper trading, which lets the agent submit orders that simulate execution without touching real capital. This phase reveals whether your agent's logic, prompt templates, and error handling behave correctly when market data changes. It also lets you verify that the agent interprets your instructions as intended. Suppose you tell the agent to maintain a fifty dollar position in a particular token. In paper trading, you can confirm that it sends a single order for fifty dollars rather than fifty units, because the API normalizes sizing. You can also observe how the agent reacts when a limit price is not met, or when a market is paused. These observations are easier to make when no real money is moving. You should also verify that your wallet has the correct asset type for the markets you intend to trade. A stock broker might require settled cash, while a perps venue might require collateral in a specific stablecoin. The unified API should still present a single balance view, but you need to ensure the underlying wallet is funded appropriately.

How do scoped keys and safety controls work?

A scoped API key restricts what the agent can do, where it can do it, and how much it can spend. You can set budget caps, position limits, and allowed instruments so that even a compromised or confused agent cannot exceed your guardrails. Scoped API keys for trading agents let you roll your own limits or rely on an API built for agents that enforces them at the infrastructure level. You should also configure an exit plan, which might include a maximum daily loss or a time-based flattening rule, and a panic kill switch that immediately cancels open orders and revokes access. These controls exist because trading can lose money, including everything, and an agent that operates faster than a human needs hard boundaries that do not depend on prompt politeness. A scoped key is different from a general exchange API key. A general key might allow withdrawals, transfers, or account changes. A scoped trading key should only permit placing and canceling orders within a specific budget. If the agent tries to exceed that budget, the infrastructure rejects the order before it reaches the venue. This rejection happens regardless of what the LLM decided in its reasoning step. Position limits work similarly. You might allow the agent to hold up to five hundred dollars of a given stock and no more than one thousand dollars across all perps. If a new order would breach either limit, the system blocks it. The kill switch is a separate circuit. You can trigger it manually, or you can automate it so that a drawdown threshold flattens the account and disables the key. After a kill switch fires, you review the logs, fix the logic, and issue a new key if you choose to continue.

How does an AI agent actually send an order?

Agents connect through MCP tools in clients like Claude or Cursor, or through a direct REST API integration. The exact request schema is in the docs; the shape looks like this.

POST /v1/orders
Authorization: Bearer YOUR_KEY
Content-Type: application/json

{
  "market": "example-market-id",
  "side": "buy",
  "amount_usd": 150.00,
  "type": "limit",
  "price": 100.00
}

The API normalizes venue-specific contract math, so an amount_usd field of one hundred fifty dollars translates to the correct number of shares, contracts, or tokens on the underlying venue. The agent never needs to compute tick sizes, margin ratios, or decimal precision itself. When using MCP, the agent discovers available tools for placing orders, checking balances, and reading positions, then calls them with parameters you define in its system prompt. How an AI agent executes orders through MCP covers the handshake and tool discovery process in more detail. The REST path is useful when you want to build a dedicated service that runs on a server and polls or streams data. The MCP path is useful when you want an LLM in a chat interface to reason about trades and invoke tools directly. Both paths use the same underlying order routing and safety controls. In either case, the agent does not hold the private key to your wallet. It holds a scoped API key that authorizes trading actions within the limits you set. The response from the order endpoint includes an identifier you can use to track the order lifecycle, from pending to filled or rejected. You should log this identifier and the full request context so that your audit trail is complete.

What is the difference between paper trading and live authorization?

Paper trading creates a sandbox where the agent experiences realistic order lifecycle events without debiting your wallet. It is the correct place to test logic drift, duplicate order bugs, and race conditions. When you are ready to trade real money, you create a live key and the owner must explicitly authorize it. This authorization step is intentional; it prevents an agent that was tested in a notebook or chat window from suddenly accessing capital because a developer copied and pasted a key. The transition from paper to live should be accompanied by stricter limits, a smaller initial budget, and a manual review of the first few orders. Paper trading simulates fills based on available market data, but it does not guarantee that live execution will behave identically. Liquidity can shift, and the agent might encounter slippage that did not appear in the sandbox. Therefore, you should treat paper trading as a test of logic and safety boundaries, not as a precise prediction of profit or loss. After you authorize a live key, start with a budget that is a small fraction of your total capital. Watch the first orders closely to confirm that the agent still interprets your instructions correctly when real money is at stake. Only after you observe consistent, expected behavior should you consider raising the budget cap. Some developers keep paper and live logic in separate configuration files to avoid accidentally pointing a production agent at the sandbox, or vice versa. This separation is a worthwhile practice. You should also version control your prompts and your safety limit configurations so that you can roll back to a known good state if a change introduces unexpected behavior.

What mistakes do developers make when moving from testing to live?

One common mistake is assuming that paper fill prices will match live slippage. Paper environments simulate liquidity, but real venues have spread, depth, and partial fill behavior that can change execution costs. Another mistake is giving the agent an unscoped key with broad permissions because it was easier during prototyping. What developers get wrong about using one API for every market explains why a single unified API does not mean a single key with unlimited scope. Developers also sometimes forget to handle errors and rejections gracefully. A live order might fail because of insufficient margin, stale prices, or venue maintenance, and the agent should pause rather than retry aggressively. How to avoid common mistakes when running a trading agent from an AI code editor offers a checklist for catching these issues before they repeat. Another frequent error is poor prompt design. If the system prompt is vague, the agent might invent parameters or misinterpret a market identifier. You should define the exact format and valid ranges in the prompt, and you should validate the agent's output before it reaches the order endpoint. Retry logic deserves careful attention. A naive loop that resubmits a failed order every second can turn a small error into a large position. You should implement exponential backoff and maximum retry counts, and you should treat repeated rejections as a signal to halt rather than a transient glitch. Finally, developers often neglect observability. An agent that trades autonomously generates a high volume of decisions. Without structured logs, you cannot reconstruct why a particular order was placed at a specific time. You need to record the LLM reasoning, the tool call parameters, the API response, and the resulting position change.

How do you keep an agent from losing more than you planned?

You prevent unexpected losses by combining pre-trade limits with post-trade monitoring. Pre-trade limits include the maximum dollar amount per order, the total position size per symbol, and the net exposure across all market types. Post-trade monitoring means watching audit logs and position updates for behavior that diverges from the strategy. You should set a kill switch that flattens positions and revokes the key if the daily drawdown hits a threshold you defined in advance. Trading can lose money, including the full budget you allocate, so the amount at risk should be money you can afford to lose entirely. The kill switch is your final line of defense. It does not ask the agent to cooperate; it simply closes positions and disables the key at the infrastructure level. You can also use time-based rules. For example, you might allow the agent to trade only during certain hours, or you might force it to flatten all positions before a weekend. These rules reduce the window during which an unattended agent can act. Monitoring should be continuous. You should stream order events and position updates into a log store that you can query and alert on. If the agent places two orders in rapid succession when you expected one, an alert should fire immediately. This tight feedback loop lets you stop problems before they compound.