How LLMs Will Trade Crypto: The Agentic Trading Architecture
An LLM-driven crypto trading agent runs a five-loop cycle: observe, reason, propose, authorise, execute. Here is the architecture in 2026.
An LLM does not 'trade' in the same way an algorithmic strategy does. It runs a reasoning loop that observes new information, considers possible actions, proposes a specific trade, secures human (or policy-based) authorisation, and only then executes via a wallet. The architecture has five distinct loops, and getting each one right is the difference between an agent that is useful and one that is dangerous.
Loop 1: Observation
- Price feeds: chain-specific oracle prices, CEX best-bid/best-ask, DEX pool reserves
- Mempool data: pending swap volume in the user's tokens, sandwich-attack indicators
- On-chain whales: large transfers, new accumulation patterns, unusual contract calls
- Off-chain news: Bloomberg/Reuters wire, regulatory filings, CT (Crypto Twitter) sentiment
- Macro context: DXY, US 10Y yield, Fed funds expectations — the variables that drive risk-on/off
Loop 2: Reasoning
The LLM is given the observations as context and produces a structured analysis: 'This signal suggests X. The best response would be a trade of size Y on venue Z. The risk is W.' This is the only loop where LLM creativity is genuinely valuable — humans can write the other four loops as deterministic code, but synthesising disparate signals into a defensible thesis is what LLMs do uniquely well.
Loop 3: Proposal
- The reasoning output is constrained into a structured proposal: instrument, side, size, venue, max slippage, time-in-force
- The proposal is sanity-checked against a static policy (max position size, allow-list of instruments, blackout times)
- If the proposal violates any hard constraint, it is rejected before reaching the user — no human time wasted on unauthorisable trades
Loop 4: Authorisation
- For trades within pre-authorised bounds (e.g., session keys), the agent self-authorises and proceeds to execution
- For trades above the auto-approve threshold, the agent surfaces a human-readable summary and requests explicit approval
- The summary always includes: rationale, downside scenario, max loss in dollar terms, alternative trades considered
- The human can approve, reject, or counter-propose — human in the loop is the safety design, not friction to be removed
Loop 5: Execution
The approved trade is signed by the wallet and submitted via a routed, MEV-protected path. Confirmation is reported back to the agent, which records the trade in its audit log and updates its mental model of the portfolio. Execution latency, slippage realised vs expected, and post-trade impact are all fed back into the next observation loop — the agent learns from its own market footprint.
The Steyble Agent Trading Surface
Steyble exposes the swap router and perps venue as MCP-callable tools, with the policy layer described above and a structured authorisation surface. The agent does the reasoning; Steyble provides the wallet, the routing, the policy enforcement, and the human-approval UX. This is the cleanest 2026 separation between the parts an LLM should own and the parts a self-custody platform should own.