From manual trading to agent execution

Manual trading means a developer opens a broker or exchange interface, interprets venue-specific contract sizes, and submits each order by hand while managing risk in real time. Switching to an agent through a single API replaces that sequence with programmatic execution, but the real difference is not simply speed. It is that the agent operates inside a cage of scoped keys, budget caps, and owner-approved withdrawal rules that manual trading does not enforce by default. The developer still designs the strategy, yet the agent can trade stocks, crypto, perps, options, and prediction markets continuously while the owner retains custody of the funds.

What does manual trading look like for a developer?

Manual trading for a developer usually means maintaining separate accounts across a stock broker, a crypto exchange, a perps venue, an options venue, and a prediction market. Each interface uses its own nomenclature for balances, margin, and buying power, so the developer becomes the human router, translating strategy intent into venue-specific order parameters. A stock broker might display shares and notional values in one format, while a perps venue uses margin ratios and leverage tiers, and an options venue lists delta, strike spacing, and multiplier rules that must be calculated by hand. The developer moves capital between accounts, tracks exposure across spreadsheets or custom dashboards, and physically clicks buttons when entry or exit conditions trigger. There is no unified layer that normalizes these differences, so a multi-market portfolio requires the developer to hold the mental model of every venue simultaneously. Even simple tasks, such as checking total exposure, require logging into multiple platforms and summing values that may be denominated in different currencies or margin modes. Capital is fragmented, reporting is fragmented, and the developer must remain present to act. If the market moves while the developer is asleep, in a meeting, or simply distracted, the position remains exposed because there is no automated sentry watching the book. Risk management is manual too, relying on mental arithmetic, stop-loss orders that may not be available on every venue, and the discipline to close a losing trade before the loss exceeds the plan. Trading can lose money, including everything, and manual execution adds the risk of human error, delay, or emotional deviation from a planned strategy.

What changes when an agent takes the orders?

When an agent takes over, the developer writes decision logic in code and connects it through MCP tools or the REST API, replacing clicks with function calls. The agent evaluates signals, sizes positions, and submits orders without waiting for human confirmation, which means it can act while the developer is offline or focused on other work. This connection can be made from Claude, Cursor, or other MCP clients, or from a direct server integration, depending on where the strategy logic lives. The developer can test the agent in a paper trading environment before authorizing live keys, which turns strategy validation into a reproducible script rather than a sequence of manual trades tracked in a notebook. However, this autonomy is only safe because the developer preinstalls boundaries that are enforced by the infrastructure rather than by willpower. The agent does not have unlimited discretion; it carries a scoped key that restricts which markets and actions it can access, a budget ceiling it cannot exceed, and position limits that prevent oversized bets. How trading APIs let AI agents trade across markets explains how a single integration point replaces the fractured manual workflow. The developer still defines the strategy, but the agent becomes the executor that never forgets a rule because it cannot operate outside its programmed cage. This shifts the developer's role from operator to designer, which means more time spent on safety logic and less time watching price charts. The agent also normalizes the developer's intent across all five market types, so a single strategy concept can be expressed in one format rather than five.

How does non-custodial design affect the comparison?

In many manual trading setups, the developer deposits funds directly into a venue account, which means the venue controls the private keys or ledger entries for that capital. The developer trusts the venue to return funds on request and to maintain segregated balances. Felix is non-custodial by construction, so funds sit in a wallet the owner controls and the agent can spend within limits but can never withdraw to itself or steal. Withdrawal addresses are owner-approved only, which means even if the agent logic were compromised or a key were leaked, the attacker could not reroute funds to an external address. This is a structural difference, not a convenience feature. This custody model also changes how developers think about key rotation. In a manual setup, a compromised API key might allow a thief to withdraw everything to an unapproved address. In this non-custodial model, a scoped key can only trade within limits, and the owner can revoke it instantly without waiting for a venue support ticket. Manual trading often requires trusting the venue with custody, whereas agent trading through this model requires trusting the code and the safety controls, while custody remains with the owner. The developer must still authorize the key explicitly for live trading, which adds a deliberate step that manual trading does not always require. A practical checklist for non-custodial AI trading walks through how to verify this setup before going live. The developer must understand that non-custodial does not mean risk-free; trading can lose money, including the full budget allocated to the agent, and the owner is still responsible for setting sensible limits and monitoring the wallet.

Why do safety controls need to be explicit with agents?

With manual trading, the human is the circuit breaker. A developer can see a position going wrong, feel the market shift, and decide to close it, or simply walk away from the keyboard and do nothing. An agent has no such intuition, so every safety mechanism must be explicit and enforced by the infrastructure rather than assumed. The controls include:

• ·Scoped keys that restrict which markets and actions the agent can access, so a bug cannot accidentally open an options position if the key is scoped to perps only.
• ·Budget caps that prevent the agent from deploying more capital than the owner intended over a day, a week, or a single trade.
• ·Position limits that stop concentration in a single trade that could wipe out the budget.
• ·Exit plans that define how to flatten under predefined conditions, such as a drawdown threshold or a time-based rollover.
• ·A panic or kill switch that revokes access and flattens positions if the developer detects abnormal behavior, without needing to log into five different accounts to close trades manually.

Why AI agents force developers to rethink trading risk management covers how these controls change the design process. How to set up audit logs and observability for trading agents with hard limits explains how to watch the agent once it is running. Without these controls, an agent is not a tool but a liability, because it will execute precisely what the code says even when the market context has shifted and a human would have paused.

What does the API abstraction actually hide?

One of the practical differences developers notice when switching from manual to agent trading is the disappearance of venue-specific contract math. The API accepts orders sized in plain US dollars and normalizes the underlying calculations for stocks, crypto, perps, options, and prediction markets. This means the developer thinks in notional exposure rather than lot sizes, margin fractions, tick values, or contract multipliers. Because the API presents one interface for five market types, the developer does not need to maintain separate authentication flows, rate limit logic, or error handling conventions for each venue. The agent carries one key, and the API manages the mapping to each underlying market. The exact request schema is in the docs; the shape looks like this:

{
  "market_type": "perp",
  "side": "buy",
  "notional_usd": 500,
  "symbol": "EXAMPLE-PERP",
  "client_id": "strategy-a-001"
}

The API translates that dollar figure into the venue's native sizing, margin checks, and formatting. This abstraction saves time and reduces the class of errors caused by misreading a multiplier, but it does not remove responsibility. The developer must still understand the underlying risk, because a five hundred dollar order in a leveraged perp is not the same risk profile as five hundred dollars in an unleveraged stock. The abstraction handles syntax, not economics. The developer remains the strategist, and the API remains the pipe. The normalization also means that a developer can move a strategy from one market type to another with fewer rewrites, though the risk parameters must still be recalibrated for each asset class.

When is it worth switching to an agent?

Moving from manual trading to an agent is not an upgrade for every developer; it is a trade-off between direct control and systematic automation. An agent makes sense when the strategy requires execution across multiple markets, when timing is sensitive and human latency is too costly, or when the developer wants to run a systematic approach without sitting at a terminal for twelve hours a day. For developers managing portfolios that span a stock broker and a perps venue, the agent removes the need to manually rebalance or hedge across accounts, though the developer must still specify the rebalancing rules in advance and accept that the agent cannot adapt to unforeseen market regimes without new instructions. Paper trading exists for testing, and live trading requires explicit owner authorization of a key, which means the developer can validate logic, observe behavior, and refine safety controls before real money is at stake. However, if the strategy is discretionary, highly subjective, or relies on rare qualitative events that resist formalization, manual trading may remain the better tool. Trading can lose money, including the entire budget, and an agent will not hesitate the way a human might. The developer must decide whether the gain in consistency, availability, and multi-market reach is worth the upfront work of building prompts, safety rules, and observability. The API opens the markets, but the developer must still decide what to do inside them.