How agentic trading works for developers

Agentic trading is the practice of letting an AI system make decisions about what to buy or sell, then execute those decisions through an API that normalizes access to stocks, crypto, perpetual futures, options, and prediction markets. Unlike a traditional trading bot that follows a fixed script, an agent reasons about market conditions, adjusts its plan, and acts within boundaries set by its owner. For developers, this means building a system that combines LLM reasoning with real financial execution while keeping funds under the owner's control. The agent manages positions but cannot withdraw money to itself or override hard limits.

What is agentic trading?

Agentic trading sits between manual trading and fully automated bots. A bot runs a deterministic rule, such as buying when a moving average crosses above a price. An agent, by contrast, receives a goal, observes market data, and decides whether to trade, wait, or exit. It can explain its reasoning, adapt to new information, and handle tasks that are hard to encode as static rules.

The developer's job is to define the agent's scope, not to predict every market move. You provide the agent with tools, such as the ability to read prices or place orders, and you set constraints on how much it can spend and which markets it can access. The agent then operates within that cage. This architecture is what separates an agent from either a human clicking buttons or a cron job running a script.

Because the agent is autonomous, it can react faster than a human and handle more complex logic than a simple bot. However, that autonomy also means it needs strict boundaries. A developer does not hand the agent an open ended mandate to make money. Instead, the developer writes a system prompt or configuration that defines the strategy, the allowed instruments, and the maximum risk. The agent then interprets that prompt in the context of live market data. If the market moves against its position, it might decide to cut losses, reduce size, or wait, depending on the instructions it was given. The key is that the decision is made in real time by the model, not by a precompiled set of if-then statements.

Think of it as giving a research analyst a trading desk, a rulebook, and a spending limit. The analyst can choose which trades to make, but cannot break the rulebook or exceed the limit. The developer builds the desk, writes the rulebook, and sets the limit. The agent plays the role of the analyst. For a deeper comparison of architectures, see how trading agents differ from trading bots.

How does a trading agent connect to markets?

Developers integrate agents through two main paths: MCP tools for AI code editors like Claude or Cursor, or a direct REST API. Both paths use the same underlying system: one API key that speaks to multiple market types. The API handles the complexity of translating a simple dollar-denominated order into the contract math required by each venue.

With MCP, the agent discovers available tools, such as checking a balance or placing an order, through a standard protocol. The developer does not need to write custom wrappers for each market. The AI editor lists the tools, describes their parameters, and lets the agent invoke them as functions. This means a developer can go from idea to interacting with a market in minutes rather than days of integration work.

With the REST API, you send JSON requests and receive normalized responses that describe positions, orders, and market data in a common shape. This normalization is important because it means your agent logic stays the same whether it is trading a stock or a perpetual future. You size orders in plain US dollars, and the API converts that into the specific lot size, tick size, or contract multiplier that the venue expects. You do not need to learn the idiosyncrasies of each venue's request format.

The protocol layer also handles authentication and auditing. Every request is tied to the scoped key, so the owner knows exactly which agent performed which action. This makes debugging and compliance simpler than managing a patchwork of exchange credentials. The developer can trace every order back to the specific reasoning step that produced it.

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

{
  "key": "YOUR_KEY",
  "market": "perps",
  "action": "place_order",
  "params": {
    "symbol": "ETH-USD",
    "side": "buy",
    "dollar_notional": 500
  }
}

In either case, the agent never holds the user's private keys for a blockchain wallet or login credentials for a broker. It holds a scoped key that can only trade within limits. The developer does not need to manage wallet seed phrases or OAuth tokens for multiple platforms. The API abstracts that away, while the owner remains the ultimate custodian of the funds.

How does self-custody work with an agent?

Non-custodial design is built into the infrastructure, not added as a feature. The owner's funds sit in a wallet or brokerage account that the owner controls. The agent receives an API key that lets it place orders and manage positions, but the key cannot withdraw funds to an external address unless that address has been pre-approved by the owner. The agent cannot steal funds because it simply does not have permission to move them out of the owner's account.

This matters because the agent is autonomous. It may run while the owner sleeps. If the agent misbehaves or is compromised, the damage is bounded by the permissions attached to its key. The owner can revoke the key instantly, flatten all positions through a panic switch, and inspect every action through audit logs.

The permission model works like a capabilities system. The key is granted a set of abilities, such as placing spot orders or closing perps positions, and each ability is bounded by parameters. For example, the key might be allowed to place orders up to one thousand dollars per trade and five thousand dollars per day. If the agent tries to exceed either limit, the API rejects the order. This is enforced server side, so a compromised agent cannot override its own constraints by generating a clever prompt.

You can read more about the model in how self-custody works for algorithmic traders.

• ·Scoped keys that restrict which markets and actions the agent can use
• ·Budget caps that limit total capital at risk
• ·Position limits that prevent oversized trades
• ·Exit plans that trigger automatic flattening under defined conditions
• ·A panic or kill switch that revokes access and closes positions immediately

These controls are not suggestions. They are hard limits enforced by the API. Even if the agent's reasoning loop produces a dangerous idea, the infrastructure blocks it before any money moves. The owner can sleep because the system is designed to say no.

What keeps an agent from losing everything?

Trading can lose money, including the entire budget allocated to the agent. No control eliminates risk, but layered limits prevent a single bug or bad decision from wiping out the owner's account.

Position sizing is the first line of defense. By capping the dollar notional of any single order, the developer ensures that even a mistaken trade is survivable. Budget caps act as a ceiling on total agent spending. Together, these two limits mean that an agent with a bug might lose its allocated budget, but it cannot access the owner's other funds or personal accounts. The cage is financial as well as technical.

Paper trading lets the agent run for days or weeks with fake money to surface logic errors before any real capital is exposed. During paper trading, the agent sees real market prices and its simulated fills are realistic, but no actual transfer of value occurs. This is where developers often discover that their agent misinterprets a data field, loops on a condition, or fails to handle a specific market state. It is cheaper to find these errors in simulation than in production.

Exit plans add another layer. They are automatic rules that close positions when certain conditions are met, such as a portfolio drawdown of ten percent or a single position losing five percent. These are not agent decisions. They are infrastructure level triggers that execute even if the agent is stuck in a reasoning loop or unable to respond. This separation of concerns, agent logic versus safety infrastructure, is what makes the system robust.

Live trading requires an explicit owner authorization step. The agent cannot accidentally promote itself from a paper environment to real money. The owner must approve a live key, and that approval can be scoped to a specific budget and timeframe. If the agent hits a drawdown limit or behaves unexpectedly, the kill switch flattens positions and revokes the key. The owner can then inspect the logs, patch the agent, and redeploy with a new key. For a practical look at sizing, see how position sizing protects owner funds.

How do you move from idea to live trading?

The safest path is to treat the agent like any other software: test, then deploy with guardrails.

1. 01Define the strategy in plain language. State what the agent should do, what it should never do, and what success looks like. Be specific about markets, timeframes, and maximum acceptable loss.
2. 02Run the agent in paper trading. Let it encounter real market data and execute simulated orders. Watch for unexpected behavior, such as repeating orders, misinterpreting price feeds, or ignoring stop conditions.
3. 03Review the logs. Check that the agent's reasoning matches its actions and that it respects the limits you set. Look for drift between the intended strategy and the actual prompts the agent generates.
4. 04Authorize a live key with a small budget. Start with an amount you are prepared to lose entirely. Treat this as a production canary, not a finished product.
5. 05Monitor for the first few sessions. Keep the kill switch ready and compare live results against paper behavior. Market impact, slippage, and latency can all differ between simulation and reality.
6. 06Expand scope only after the agent demonstrates consistent adherence to limits over a meaningful period. Increase budget or add markets gradually, never all at once.

After the first live sessions, schedule a regular review cycle. Compare the agent's stated reasoning with its actual trades. Update the system prompt to clarify ambiguities the agent exploited. Over time, the agent becomes more predictable, but it never becomes risk free. Markets change, and an agent that worked last month may fail next month. Continuous monitoring is not optional. It is part of the development lifecycle.

If you are ready to run your first agent, how to run your first trading agent from an AI code editor using MCP walks through the setup.

Remember that an agent is only as safe as the limits you place around it. The infrastructure provides the cage, but the developer designs the cage door. Start small, log everything, and keep the kill switch within reach. The goal is not to build a perfect trader on the first attempt. The goal is to build a system that fails safely while it learns.