How to run your first trading agent from an AI code editor

You can run your first trading agent from an AI code editor by connecting the editor to a non-custodial trading API through MCP tools or a direct REST client. The agent never takes custody of your funds, because the API lets the editor place orders from a wallet you control while scoped keys and budget caps limit what the agent can spend. If you have never automated a trade, you should begin in paper trading mode, define a maximum loss you can afford, and authorize live keys only after you observe the agent making decisions you understand. Trading can lose money, including your entire budget, so never automate capital you cannot afford to lose.

What do you need before you open the editor?

Before you write any code, you need three things: an AI code editor that supports MCP or REST calls, a trading account with a non-custodial API provider, and a clear decision about which single market you want to test first. The editor acts as the agent's interface; popular choices include Claude, Cursor, and other MCP clients that can discover external tools and call them within a chat session. You will also need to create an API key scoped to trading only, with a budget cap and position limit set by you, not by the agent. The key generation process usually takes place in a dashboard where you set a daily spend limit, a whitelist of symbols, and a withdrawal address that only you can update. The agent sees none of this administrative surface. It only receives the public endpoint and the scoped key, which means it can place orders but cannot change the safety parameters you defined.

You do not need to write a complex strategy on day one, and you do not need to connect to five markets at once. Many beginners start with a simple rule, such as rebalancing a small portfolio when prices move by a certain percentage, or reducing exposure after a sharp move on a prediction market. The key is that the strategy must be expressed in plain language to the editor, which then translates it into API calls. Because the API normalizes order sizing in plain US dollars, you do not need to calculate contract sizes, margin ratios, or venue-specific lot increments. The editor handles the syntax while you retain control over the economic limits.

You should also decide on a kill criteria before you write the first prompt. A kill switch flattens positions and revokes the API key if the agent behaves unexpectedly, and an exit plan tells the agent when to stop trading for the day. These controls are not optional infrastructure; they are a basic safety layer. You should also consider how to evaluate an autonomous trading system when you have never automated a trade, because the evaluation begins with the custody model and the permission scope.

How does the editor connect to markets?

AI code editors connect to trading infrastructure through two main paths: MCP tools and direct REST API calls. MCP is a protocol that lets the editor discover available actions, such as checking a price or placing an order, and then execute them through a local tool server. The editor sees these as functions it can call, much like it would read a file or run a test. The alternative is to paste the REST API documentation into the editor and let it construct HTTP requests directly. REST works in any editor that can make HTTP requests, while MCP tools advertise their own schemas so the AI can discover parameters without you pasting documentation. Both paths lead to the same non-custodial settlement layer.

The connection is stateless on the agent side. Each request carries the key and the instruction, so the agent does not need to maintain a persistent websocket or manage session cookies unless you choose to implement one. In both cases, the API key is scoped: it can place orders, read balances, and fetch positions, but it cannot withdraw funds to an external address. This is the non-custodial model that keeps your capital in a wallet you control. The agent can spend within the limits you set, but it can never steal the underlying capital or move it to itself.

If you want to understand the mechanics behind this safety architecture, you can read about the safety model for MCP trading tools. That article explains why scoped permissions, owner-approved withdrawal addresses, and panic switches are built into the protocol rather than added as afterthoughts.

What does a first agent interaction look like?

Suppose you want to test a simple hypothesis: when a market moves more than five percent in ten minutes, you want to reduce exposure by a fixed dollar amount. You open your AI editor and describe the rule in natural language. The editor asks you to confirm the market, the direction, the threshold, and the size of the reduction. It then drafts a script that polls for price changes and submits a dollar-sized order when the condition is met. You review the generated logic before it runs, because the editor is an assistant, not an autonomous authority.

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

{
  "api_key": "YOUR_KEY",
  "market_type": "perps",
  "side": "sell",
  "dollar_size": 50,
  "symbol": "EXAMPLE-PERP",
  "condition": "price_change_10m > 0.05"
}

The payload is intentionally small. You are not sending raw transaction bytes or calculating nonce values. The API abstracts venue-specific mechanics, so the editor does not need to know whether the underlying instrument is a perpetual swap or an equity option. It simply states the dollar size and the condition. The agent does not store your secret. The key is injected from an environment variable or a local secrets file that the editor reads but does not commit to version control. The response returns an order identifier, a fill status, and the remaining budget for that key. You can inspect this output in the editor's terminal or chat panel before you ever allow the agent to loop unattended.

It is important to note that this example is hypothetical. No real trade is described here, and any live implementation would need you to verify the schema against the current documentation. The purpose of the example is to show that the interaction is ordinary HTTP, not a proprietary binary protocol, which means the AI editor can generate and debug it like any other API call. If you are unsure how to test this safely, you can learn from common mistakes developers make with paper trading for AI agents.

How do you test without risking real money?

Every beginner should spend meaningful time in paper trading mode. Paper trading uses live market data and simulated fills, so you can observe how the agent reacts to real price movements without committing capital. You should treat paper trades as seriously as real ones: log every decision, compare the agent's output to your manual intent, and look for off-by-one errors in size or direction. Paper fills are often optimistic. They assume instant execution at the visible price, which is not always true in live markets with spread and depth. Use paper mode to debug logic, not to estimate profits. If your strategy relies on precise fill prices, you will need to add slippage assumptions before going live.

A useful testing sequence is to run the agent for one full market session with a strict decision log. Ask the agent to explain each order before it submits. If the explanation does not match your strategy, you have a prompt alignment issue, not a market issue. Fix the instructions, reset the paper session, and repeat. Only when the agent's decisions are predictable for several consecutive sessions should you consider a live key. This discipline is what separates a supervised experiment from an unattended gamble.

When you do move to live trading, do not increase the budget dramatically. The emotional difference between paper and real money is significant, and the agent may encounter latency or slippage that did not appear in simulation. Start with the smallest dollar size the API allows, and keep the total daily budget below an amount you could lose without changing your financial plans. You can read about how to start an AI agent with a small budget if you want a framework for sizing that first allocation. Trading can lose money, including the full amount you allocate, so this limit is your primary defense.

What should you watch during the first live week?

The first week of live trading is about observation, not optimization. Watch three things: whether the agent stays within its scoped permissions, whether the fills match the intended dollar sizes, and whether the drawdown stays inside your pre-defined limit. Do not add new markets or strategies during this week. The goal is to confirm that the system behaves in production exactly as it did in paper mode. Set a calendar reminder to review the agent every twelve hours during this period. Do not let it run unattended overnight until you have seen it behave correctly through multiple market sessions.

You should also verify that the kill switch works. Trigger it manually at least once to see positions flatten and the key revoke. This is a functional test, not a failure. If the kill switch does not respond instantly, stop trading until you understand why. Latency in a safety control is a trading risk in itself.

After the first week, review the trade log against your original strategy description. If the agent deviated because of ambiguous prompts, rewrite the instructions. If it deviated because of market conditions, decide whether your strategy was wrong or the agent misinterpreted the signal. Either way, the fix is usually a tighter prompt or a narrower scope, not a larger budget. Scaling up is the last step, and it should only happen after consistent behavior at small size.