A developer's guide to agentic trading systems

Agentic trading is the practice of letting software systems make decisions about what to buy or sell and then execute those decisions without manual intervention. For developers, building such a system traditionally meant integrating with many different brokers, exchanges, and clearing systems, each with its own authentication, contract sizing, and risk model. Felix collapses this into a single API and a single key that lets an agent trade stocks, crypto, perpetual futures, options, and prediction markets using plain dollar amounts, while the owner keeps full custody of the funds. The result is that developers can focus on strategy and safety logic instead of venue-specific plumbing, and the architecture is designed so that you can swap out the decision model without changing the execution or safety plumbing.

What does an agentic trading system actually do?

An agentic trading system has three logical layers: a decision layer, an execution layer, and a safety layer. The decision layer generates trading signals. It might be a large language model that reads news and outputs a directional bias, a statistical model that detects mean reversion, or a deterministic rules engine that rebalances a portfolio on a schedule. Whatever its internal logic, its output is an intent: buy this asset, sell that one, or hold cash. The execution layer receives that intent and turns it into an order. The safety layer sits between them, or wraps the execution layer, and enforces hard constraints. It checks whether the proposed order exceeds the daily budget, violates a position limit, or conflicts with a pre-set exit plan. If the order passes all checks, it goes to the market. If not, it is blocked and logged. Unlike a simple alert bot that sends a message to a human trader, an agentic system submits orders itself. This autonomy is useful because it removes latency and emotional hesitation, but it also means the developer must be rigorous about boundaries. The system is spending real money, and trading can lose money, including everything. Therefore, the architecture should treat the safety layer as the primary design problem, not an afterthought. Many developers spend weeks on signal generation and minutes on safety. A better approach is to build the guardrails first, then let the strategy operate inside them.

How do you connect an agent to markets?

Developers have two integration paths. You can connect through MCP tools, which let Claude, Cursor, and other MCP clients call trading functions directly within their reasoning loop, or you can use the REST API for custom, headless integrations. Both paths use the same underlying key and permission model. The MCP approach is useful when you want the language model to evaluate a scenario, decide on a trade, and execute it within the same conversation. The REST API is better for scheduled jobs, event-driven systems, or custom dashboards that do not use an MCP client. In either case, the agent authenticates with a scoped key that carries its own budget and market restrictions. The same underlying account can power both MCP and REST integrations, but the scoped keys let you give each client different permissions. You might let your MCP client check balances and submit small orders while your REST service handles scheduled rebalancing with its own separate cap.

{
  "market_type": "perpetual_futures",
  "direction": "buy",
  "amount_usd": 250,
  "instrument": "ETH",
  "api_key": "YOUR_KEY"
}

The exact request schema is in the docs; the shape looks like this. Because the API normalizes across markets, the integration code does not need separate branches for each venue type. You do not need to learn how a perps venue sizes contracts versus how a stock broker handles fractional shares, or how an options venue structures multipliers. The agent expresses intent in dollars, and the API handles the rest. This reduces the surface area for bugs and makes it easier to move an agent from one market to another without rewriting the execution logic. For a developer, this means the integration is a solved problem, and your time is better spent on the decision and risk layers.

Why is non-custodial architecture important for developers?

When you build software that handles money, custody is the biggest architectural concern. Felix is non-custodial by construction: the funds sit in a wallet the owner controls, and the agent can only spend within the limits of its scoped key. The agent can never withdraw funds to itself or to an address the owner has not pre-approved. This matters because even if the agent's key is compromised, or the large language model hallucinates an instruction, the worst-case loss is bounded by the scoped budget and position limits. For developers, this means you are not building a custodial fintech application. You do not need to hold user funds, manage withdrawal queues, or secure hot wallets beyond the scope of the agent's key. The owner approves withdrawal addresses at setup, and the agent can only trade, not steal. This changes the security model from "trust the developer" to "trust the math and the scoped permissions." You can read more about this shift in How trading with an agent changes security from first principles. It also means that building an agentic trading system is closer to building a signed transaction bot than to building a bank. The developer provides the tooling and the strategy, but the owner retains control of the capital at all times. This distinction matters for liability, complexity, and sleep quality.

What safety controls should you build first?

Before the agent sends its first order, you should set four controls: budget caps, position limits, exit plans, and a panic switch. Budget caps define the maximum dollars the agent can deploy in a given period, such as a day or a week. Position limits prevent the agent from concentrating too much capital in a single asset, even if the decision layer is highly confident. Exit plans are pre-programmed rules for closing positions, such as stop levels, time-based exits, or volatility triggers, so the agent does not hold losers indefinitely while waiting for a new signal. The panic or kill switch flattens all positions and revokes the agent's key immediately. These controls are not optional extras; they are the foundation of the system. You should configure them before you write the strategy logic. If you are using MCP tools, the safety model works the same way: the key is scoped, the budget is capped, and the owner can revoke access at any time. For a practical walkthrough, see How to build guardrails for a trading agent. Remember that trading can lose money, including everything. The purpose of these controls is not to guarantee profit, but to guarantee that the agent cannot exceed the boundaries you set. It is easier to relax a tight limit after testing than to recover from a runaway agent.

How do you test before going live?

Every agent should start in paper trading. Felix provides a paper environment where the agent submits orders, tracks positions, and observes simulated fills without using real capital. This lets you debug the decision logic, test the order sizing, and verify that your safety triggers behave as expected under realistic market conditions. Paper trading also lets you test how the agent responds to API errors or rate limits without risking capital. Paper trading is not a guarantee of future performance, and simulated fills do not capture all the nuances of live liquidity, but they reveal integration bugs, timing issues, and logic errors that would be expensive to discover with real money. You should run the agent in paper mode long enough to see it handle multiple market regimes, error responses, and edge cases such as rejected orders, partial fills, or zero balances. Watch how the agent behaves when it hits a budget cap or a position limit. Only after the owner explicitly authorizes a live key should the agent touch real funds. Authorization is a deliberate step, not the default. This separation between test and live keys prevents accidental deployments from spending real money. When you do go live, start with the smallest budget cap that still produces meaningful signals, and scale up only after observing stable, predictable behavior over a meaningful sample of trades.

How do you size and place orders across markets?

One of the hardest parts of multi-market development is normalizing order sizing. A stock lot, a crypto decimal, a perps contract, and an options multiplier all use different units and minimum increments. Felix abstracts this by letting you size orders in plain US dollars. You send an order for $500, and the API handles the venue-specific contract math. This removes an entire class of calculation errors that developers often face when integrating with multiple venues. It also means your agent can treat a stock broker, a perps venue, and a prediction market with the same execution logic: evaluate the signal, determine the dollar risk, submit the order. The API translates the intent into the correct format for the underlying market. For portfolio-level thinking, you can explore how to manage positions across these different instruments in How to Start Multi-Market Portfolio Management with AI Agents. The key point for developers is that you do not need to maintain five different order builders. You maintain one, and you spend your time on the decision layer and the safety layer, which is where the actual risk lives. This uniformity is especially useful when you want to rebalance across asset classes, because the same dollar-based logic applies whether you are buying a stock or taking a perp position.