Inside the Stack: How an LLM Actually Places a Trade on Your Exchange

Everyone has seen the demo: someone types “short BTC if it loses 60k” and a position appears. What happens between the keystroke and the fill is less glamorous and far more interesting. Here is the architecture behind the new generation of AI trading platforms, and the design decisions that separate a toy from something you would fund.

Layer 1: the connection

An LLM cannot call an exchange. It can only produce text. The bridge is a tool-calling protocol — today, overwhelmingly the Model Context Protocol (MCP). An MCP server wraps an exchange’s REST and WebSocket APIs into typed functions the model can invoke: get_price, open_position, set_tp_sl, close_all. OKX publishes one. So do Robinhood, Gemini and a dozen smaller venues.

For platforms that aggregate many venues, the pattern is a connector registry. When you connect your exchange to an AI on Cubrik, you are registering credentials against one of these wrapped servers; the app then exposes the venue’s full toolset to the agent. The MoonX connector, for instance, ships 36 tools, all enabled by default, with behaviour narrowed by the user’s prompt rather than by toggling tools one at a time.

Layer 2: credentials and blast radius

The single most important design question is where the key lives and what it can do.

Scope. A trading key should be able to read balances and place orders, and nothing else. Withdrawal permission is never granted. Most venues enforce this at key creation.

Storage. Keys are encrypted at rest and injected into the MCP process at runtime; the model never sees the raw secret in its context window.

Isolation. Robinhood’s approach of a separate agent account with its own funding is the cleanest version of this. OKX’s one-click flow replaces the key with an OAuth-style grant that can be revoked from the exchange side.

Layer 3: the reasoning loop

An automation is three things: a trigger, a standing instruction, and a tool allow-list. The trigger (a price cross, a candle close, a cron schedule) wakes the agent. The instruction is the prompt — the strategy, risk rules and style the user wrote. The agent then runs a loop: pull market data, reason, optionally call an indicator tool, decide, act, write a log entry.

Two details matter here. First, the model is stateless between runs; persistent context (open positions, recent decisions) has to be fetched from the exchange and from the platform’s own trade history on every wake-up. Second, the loop needs a hard budget: a cap on tool calls and tokens per run so a confused agent cannot spin indefinitely. Cubrik meters this as credits, which doubles as the pricing unit.

Layer 4: observability

If you cannot read why a trade happened, you will not trust the next one. Serious platforms store the full reasoning trace alongside each order: the data the agent saw, the rule it applied, the tool it called. This is also what makes the prompt debuggable. Most “the AI went rogue” stories turn out to be an ambiguous instruction, visible in the log.

What is still hard

Latency: an LLM round-trip is hundreds of milliseconds at best, which rules out scalping unless the heavy decision is pre-computed and the agent only fires a prepared order. Determinism: the same prompt can yield slightly different decisions run to run, so risk rules must be enforced in code, not left to the model. And venue drift: exchange APIs change, and every connector is a maintenance commitment.

None of this is exotic engineering. What is new is that it is packaged for a user who will never open a terminal. The interesting products in this space are not the ones with the smartest model. They are the ones that got layers two and four right.