What developers should understand about trading bots versus agents

A trading bot is a program that executes a fixed set of rules on market data. A trading agent is a system that uses a large language model to reason about goals and then decides whether to trade. Both can lose money, including the full balance, but they differ in architecture, control surfaces, and how a developer must think about risk.

What is a trading bot, really?

A trading bot is deterministic software. It reads market data from an API or a websocket, runs that data through a strategy you wrote in code, and sends orders when the conditions match. There is no reasoning step, no interpretation of news headlines, and no adaptation to new circumstances unless you stop the program, edit the file, and redeploy. Suppose you write a script that buys when one moving average crosses above another and sells when the relationship reverses. The bot will do exactly that, every time, until you stop it or the server restarts. The state is explicit, the logic is inspectable in a single file, and the behavior is repeatable across backtests. You can version the strategy in Git, roll back to a known good commit if a new rule misbehaves, and run the same binary for months without drift. The bot does not learn, which is a feature when you want certainty. It also means the bot will not adapt to a regime change unless you push new code. Because the rules are frozen in code, you can test the strategy against historical data and know with high confidence what it would have done in the past. You can also step through the code in a debugger, inspect variable values at the moment of a trade, and add a breakpoint to catch an error before it reaches the API. The primary risks are the usual software risks: a typo in a formula, an unhandled API exception, an infinite loop that spams orders, or a market event that your rigid rules do not address. If the bot fails, it tends to fail in the same way every time, which makes diagnosis straightforward. Safety is largely a matter of traditional engineering discipline. You write unit tests, you review diffs, you add circuit breakers that halt trading if volatility spikes beyond a threshold you set, and you monitor logs for stack traces. The bot runs on a server or a cloud function, holds a static API key, and communicates directly with the trading venue. Latency is low because the work is arithmetic, comparisons, and HTTP requests, not inference over billions of parameters.

What makes a trading agent different?

A trading agent places a large language model between the strategy and the API. Instead of encoding every rule in Python or TypeScript, you write a system prompt that describes the goal, the constraints, and the available tools. The agent receives market data by calling tools over MCP or a similar protocol, reasons about the current situation in natural language, and then decides whether to place an order, adjust a position, or wait. The same underlying API executes the trade, but the path to get there is probabilistic. The agent is not deterministic. If you feed it the same price chart twice, it may emit slightly different reasoning and, in some cases, a different action. The agent's output is a structured tool call, such as a JSON object that names a function and its arguments, but the decision to emit that call emerges from probabilistic sampling. You can lower the temperature to make the model more deterministic, but you cannot make it fully repeatable in the way a for loop is. That flexibility is the point. An agent can parse unstructured information, compare conditions across multiple markets, and explain its intent in plain text before it acts. You might tell it to maintain a neutral delta exposure across a portfolio that includes stocks, perpetual futures, and options, and it can decide which legs to adjust without you rewriting the code for every new position. How AI trading agents differ from bots and why MCP matters goes deeper on this architecture. The tradeoff is predictability. Because the agent reasons rather than calculates, it can misinterpret a prompt, overtrade when volatility rises, or fixate on a spurious pattern that a human would ignore. You do not simply review code; you review completions, test prompt edge cases, and restrict the toolset so the model cannot call functions you never intended to expose. The developer becomes both a strategist and a safety engineer, because the LLM has a degree of freedom that a script does not.

How does safety differ between bots and agents?

With a bot, safety is about code correctness. If the logic is sound and the inputs are clean, the output is predictable. You can backtest the strategy because the algorithm does not change between runs. A failed unit test tells you exactly which branch is broken. With an agent, safety is about bounding behavior that you cannot fully predict. The model is a black box that evolves with temperature settings, context window limits, and provider updates. You cannot fully backtest an agent in the traditional sense because the LLM may produce different outputs for the same historical scenario next month, or even next hour. You should also consider the context window. If you feed the agent a long history of trades and market data, it may eventually lose the beginning of the conversation, including your safety instructions. Truncation can silently drop the sentence that forbids leverage above a certain level. Bots do not suffer from this because they do not hold a conversational context that competes for space. That means you must enforce hard limits outside the model. Scoped keys ensure the agent can only trade specific markets. Budget caps prevent it from deploying more capital than you allocated. Position limits stop it from taking size that exceeds your risk tolerance. A panic kill switch flattens positions and revokes the key instantly. What beginners get wrong when taking an AI trading agent live covers common gaps in this layer. Both systems can lose money, including the entire balance, and neither can guarantee profits. The difference is that a bot usually fails from a bug you can grep in a log, while an agent can fail from a subtle shift in prompt interpretation that leaves no stack trace. You must also guard against prompt injection, where malicious or accidental text in a market data feed influences the model's reasoning. A bot ignores such text unless you explicitly parse it; an agent might read it and act on it.

What does the developer workflow look like for each?

Building a bot is familiar software engineering. You define a main loop, fetch data from a REST or websocket feed, compute indicators in pandas or your library of choice, and conditionally call the order endpoint. You test with historical tick data, optimize parameters through brute force or gradient descent, deploy to a server, and monitor uptime and error rates. When something breaks, you read the traceback, add a log line, and redeploy. Building an agent is closer to designing a control system. You craft a system prompt, enumerate the tools the model may call, and run paper trading sessions to watch how the model interprets ambiguous market conditions. You do not optimize parameters in the numerical sense; you refine instructions, tighten tool descriptions, and add guardrails. You spend time reviewing token usage and context window limits to ensure the model does not truncate the prompt that contains your safety rules. Developers who are used to version control for code must adapt to version control for prompts. A change of a single adjective in a system prompt can alter the agent's risk appetite, so you track prompt diffs with the same rigor you apply to code diffs. Debugging an agent often means reading a completion trace to see exactly which tool the model chose and why, rather than stepping through a stack frame. The feedback loop is slower because you must wait for the model to respond, review the reasoning, and then adjust the prompt before the next test. The exact request schema is in the docs; the shape looks like this.

curl -X POST "https://api.felix.trade/..." \
  -H "Authorization: Bearer YOUR_KEY" \
  -d '{
    "market_type": "perpetual_futures",
    "side": "buy",
    "usd_amount": 100
  }'

Both workflows require explicit owner authorization before a key can trade live capital. Paper trading lets you test connectivity and logic without financial risk, though paper results do not promise live performance because slippage and latency differ. Agents can connect through MCP tools from Claude, Cursor, or other MCP clients, or through the REST API directly. The MCP path is useful because it keeps the API key inside the client environment rather than inside the model's context window. For a bot, the API key is typically embedded in an environment variable on the server. For an agent using MCP, the key may reside in the client configuration, and the model only sees the tool schema, not the secret itself. This separation reduces the chance that a key leaks through a model completion or a prompt injection attack, though it does not eliminate the need for strict budget caps. How to manage a multi-market portfolio with one agentic API explains how the same normalized interface serves both bots and agents across stocks, crypto, perps, options, and prediction markets. Whether you choose a bot or an agent, the underlying market access layer is identical. What changes is the cognitive architecture above it.

When should you choose a bot over an agent?

If your strategy is pure arithmetic, requires millisecond consistency, or runs at high frequency, a bot is the better tool. Deterministic code is faster, cheaper to operate, and easier to audit. You do not pay inference tokens per decision, and you do not worry about a model provider update silently changing behavior. Choose an agent when the task involves reasoning over unstructured data, multi-step planning, or natural language goals that are hard to encode as rigid rules. For example, suppose you want the system to read a portfolio summary, evaluate risk across five market types, and rebalance in plain English terms. An agent can handle that cognitive load, though it will act more slowly and less predictably than a bot. You must also account for inference cost. Every decision consumes tokens, and frequent trading can make that expense non-trivial. Neither choice removes the risk of loss. Both need monitoring, logging, and a clear plan for shutting down when markets move against them. The agent simply adds a layer of interpretation that demands extra caution, extra latency, and extra budget.

How does non-custodial infrastructure fit in?

Whether you build a bot or an agent, Felix is non-custodial by construction. Your funds sit in a wallet you control. The API key lets the software place orders and manage positions, but it cannot withdraw funds to an address you have not explicitly approved. The agent can spend within the limits you set, yet it can never steal the balance. This matters because developers sometimes assume that an autonomous system must hold custody of capital to act. It does not. You can scope a key to a single market, cap its daily spend, and attach a kill switch that flattens everything and revokes access in seconds. How algorithmic traders can automate without giving up custody walks through the custody model in detail. Orders are sized in plain US dollars, and the API normalizes venue-specific contract math so both bots and agents can think in the same units regardless of whether they are trading stocks, crypto, perps, options, or prediction markets. A bot and an agent can even share the same account if you issue separate scoped keys, though you should monitor for unintended interactions. The infrastructure is the same for both architectures; only the control layer changes.

Frequently asked questions