Trading agents, by example.

Build a trading agent, end to end

New to this? Start here. A trading agent reads market data, decides what to trade, and places the order on its own. You can write the deciding part in an afternoon. The rest of this page is mostly about the parts that take the other three weeks: getting filled, not blowing up, and keeping the thing alive.

The five parts of a trading agent

Every agent has the same five layers, from a moving-average bot to an LLM-driven one:

1. Data: live prices, book depth, funding, and whatever your strategy reads.
2. Reasoning: the rules or model that turn data into an intent like "go long ETH."
3. Execution: placing, amending, and cancelling orders, and handling partial fills.
4. Risk: sizing, stops, exposure caps, and a fast way to flatten everything.
5. Operations: state, reconnects, retries, rate limits, logging, and deployment.

Get data you can trust

Start with one venue and one feed. Open a websocket for live updates and keep a REST endpoint around for snapshots. The habit that saves you: after any disconnect, drop your local order book and re-fetch it. A stale book that looks correct is how agents send orders into prices that stopped existing ten seconds ago.

Keep deciding separate from doing

Have the reasoning layer emit a plain intent and say nothing about how to fill it. Something like { side: "long", symbol: "ETH", sizeUsd: 250, maxSlippageBps: 8 }. Later you can replace a moving-average rule with a model and never touch the execution code. Tangle the two together and the codebase becomes the kind you are scared to change.

Execution is where money leaks

This layer decides whether you keep your money, so give it the most care. It has to handle:

• a half-filled order, without panicking or doubling down;
• a retry after a timeout that does not accidentally open a second position (use idempotency keys);
• an exit that still works when the venue is slow or half your requests are timing out.

Writing this correctly takes a couple of weeks. Getting it wrong takes about ninety seconds. The exit case matters most: you want a single call that flattens a position even when everything else is on fire.

Build it or buy it

You can write all five layers, start from an open-source framework like Freqtrade, Nautilus Trader, or Hummingbot, or call an execution API and own only the strategy. The right choice depends on how much of the plumbing you want to babysit.

If writing strategy sounds better than maintaining reconnect logic, that is the case for an execution API: you keep the strategy and hand placement, backtesting, deployment, and exit handling to a service built for it. The example agents above all take this route on Superior Trade. The MCP section shows how an agent calls execution tools.

Build a Hyperliquid trading agent

Hyperliquid is unusually friendly to agents. The order book lives on-chain in HyperCore, median latency is around 0.2 seconds (HyperBFT consensus), and placing or cancelling an order costs no gas. You also get a delegation model that lets a bot trade your account without being able to drain it. Here is how the pieces fit.

Use an agent wallet, not your main key

Hyperliquid lets you approve a separate agent wallet (sometimes called an API wallet) that can place and cancel orders on behalf of your account but cannot withdraw. Give that key to your bot, not your real one. If it leaks, the worst case is unwanted trades, not a drained account. You can delegate several agent wallets to one account, which is handy if you run more than one strategy.

Funding and the testnet

Fund the account with USDC bridged to Hyperliquid (native USDC on Arbitrum, and mind the 5 USDC bridge minimum), then keep a small buffer so margin math never rounds you into a failed order. Before any of that, run the whole thing on the testnet with faucet USDC. The testnet behaves like mainnet closely enough that most bugs you will hit show up there first, for free.

The two connections you need

Open a websocket for live state: prices, your fills, your open orders, and the book. Keep the REST endpoint for snapshots and reconciliation. Reconcile on every reconnect. On a gas-free venue it is tempting to fire cancel-and-replace constantly, which makes a stale local book even more dangerous, so trust the exchange snapshot over your own memory after any gap.

Exits and reduce-only

Mark your exit orders reduce-only so a flatten can never accidentally flip you into a position on the other side. When you want out, you want out in one call that you can trust under load. This is the single most important thing to get right on a leveraged venue, and it is the part most quick tutorials skip.

Or use an existing framework

If you would rather not call the SDK directly, several open-source frameworks already connect to Hyperliquid: Freqtrade added native Hyperliquid support, and Nautilus Trader and Hummingbot can both trade it too. Each handles the order plumbing, so you bring the strategy and little else. Superior Trade builds on Freqtrade and adds a one-call atomic exit plus coverage across Hyperliquid's HIP-3 markets.

Give an agent a trading tool over MCP

The Model Context Protocol lets you hand an agent a small set of tools and let it decide when to call them. For trading, that means the model reasons about the market and calls place_order or flatten, while your server does the signing, the bookkeeping, and the safety checks. Done right, the model never touches a key.

Design the tools around intents, not endpoints

Resist mirroring the raw exchange API. A model does better with a few clear tools than forty thin ones. A workable set:

• get_positions: current positions, margin, and open orders.
• place_order: side, symbol, size in USD, order type, and a max-slippage bound.
• cancel_order: by client order id.
• flatten: close a position in one call, reduce-only.
• backtest: run the proposed rule over recent data and return the summary.

Keep keys and guardrails in the server

The server holds the exchange credentials and signs every request. The model passes arguments and gets results, nothing more. Put every limit you care about in the server: a maximum order size, an allow-list of symbols, a daily loss cap that rejects new entries once hit, and reduce-only on every exit. Treat the prompt as a hint and the server as the law. If the model asks for a 10x-too-large position, the server returns an error, not a fill.

A shortcut

If you do not want to build and host this yourself, some execution APIs already expose placement, backtesting, deployment, and a one-call exit as agent-callable tools with the guardrails in place. Superior Trade ships these as a skill you can register with an agent, which is what the copy prompts on the example agents above install.

Backtest, then deploy without lying to yourself

A backtest is the easiest place in trading to fool yourself. The chart goes up, the Sharpe looks great, and almost none of it holds up against a real order book. The goal here is a test you can actually trust, and a deploy that fails safely when it is wrong.

Why close-price backtests flatter you

The default backtest buys and sells at the closing price of each candle. Real trading does not work like that. You pay the spread to get filled now, or you sit in the queue and sometimes miss. Fees come out of every trade, and on perps funding quietly bleeds or pays you while you hold. Add those three and a strategy that looked like a steady climb can flatten into noise.

Paper-trade before real size

A clean backtest earns you the right to paper-trade, not to go live. Run the agent on live data with fake money for a few weeks. This is where the operational bugs surface: a reconnect that drops an order, a rate limit you did not expect, a data feed that disagrees with your historical source by a tick. None of those show up in a backtest.

Deploy so it fails safely

Once it is live, assume it will misbehave and build for that:

• a kill switch that flattens and halts on one command;
• a daily loss cap that stops new entries once breached;
• alerts on disconnects, rejected orders, and position drift from expectation;
• logs you can replay to understand what the agent thought it was doing.

Start with size small enough that a bug is a lesson, not a wipeout, and scale only after the live numbers track the paper ones. The results on the example agents above come from this kind of honest backtest on Superior Trade, with fees and slippage applied, not a close-price fantasy.

Loop engineering for trading agents

Loop engineering is the shift from writing a single prompt to designing the loop an agent runs in: gather context, decide, act, watch what happened, and repeat. A trading agent is that loop with money on the line, which makes it one of the most demanding places to get the loop right.

The loop, in one breath

Read the current state, decide on an intent like "go long ETH," place the order, observe the fill and how the market moved, then feed that back into the next pass. Every example agent above is one of these loops. Copy its prompt and you get a loop you can schedule, not a script you have to babysit.

Where the engineering actually is

The interesting decisions are not in the prompt. They sit in four places around the loop, and trading makes each one concrete:

• Context: keep the order book fresh. A stale book is a wrong decision waiting to happen.
• Safety: size caps, reduce-only exits, and an allow-list of markets, enforced in code and not in a prompt the model can talk itself out of.
• Graceful degradation: when the venue stops answering, the loop's job is to flatten and wait, not to keep guessing into the dark.
• Cost: every pass can spend fees, funding, and tokens, so a good loop spends them on purpose.

Close the loop: schedule it and let it learn

A loop that never runs again is just a script. Two practices turn a one-shot agent into one that compounds:

• Schedule the next run by trade frequency. Tie the interval to the strategy's timeframe: an hourly strategy should wake up hourly, a four-hour one every four hours, a funding carry every funding window. Tell your harness to schedule the next run, or drop in a cron job, so the agent decides when to look again instead of waiting for you.
• Write down what it learned. After each run the agent appends the outcome (fills, slippage, what it would change) to a doc it reads next time. That doc is an LLM wiki, and it is what stops the agent from relearning the same lesson forever.

The copy prompts on the example agents already do this: they install the skill, validate with a backtest, keep an LLM wiki, run the decide-act-observe loop, and register the next run on a schedule that matches the strategy.

Engineer the decision, not the plumbing

Most of the brittle part is loop mechanics, not strategy. Reconnects, idempotent retries, and a reliable one-call exit are the same on every agent. Hand that part to a service built for it, like Superior Trade, and loop engineering narrows to the part that is actually yours: what the agent decides, and when it should stand down. The MCP section shows how the model reaches those actions as tools.

Give your trading agent an LLM wiki

An LLM wiki, a term popularized by Andrej Karpathy, is a knowledge base written for a model instead of a person: plain markdown entity pages linked with [[wiki-links]] that the agent builds and maintains itself, so what it learns compounds instead of evaporating between sessions.

Why a trading agent needs one

An agent that starts every session blank relearns the same lessons forever. A wiki lets it remember which strategies worked on which markets, which ones quietly bled fees, and what the last drawdown taught it. Next session it builds on that instead of guessing from scratch.

What goes in it

• one page per strategy: the rule, the markets it suits, and its best honest backtest;
• one page per market: liquidity, funding behavior, and the hours that tend to trade well;
• links between them, so "breakout" connects to the markets where breakouts actually pay.

Lighter than RAG

There is no vector store to run. The agent reads the markdown directly, and adding a new source triggers a small compile step where it folds the new facts into the existing pages. Over time the pile of notes becomes a connected map of what your agent knows. It pairs naturally with the copy prompts above: each backtest the agent runs on Superior Trade is a result it can write straight back into its wiki, so the library grows every time it tries something. Karpathy's original sketch is a good starting point: the llm-wiki gist.