Agentic AI · Case Study · Module 11

Case Study: An LLM Trading Loop in Production

Since mid-2026 we have run a small automated intraday SPY options loop in production in which a frontier multimodal LLM (Claude Opus) makes the discretionary calls — whether to enter, in which direction, and how to manage the position — inside a lattice of mechanical guardrails that it cannot override. This page is an engineering case study of that system: the architecture, the data problems we did not expect, and the guardrails that exist because something real went wrong. It is not a performance claim, and single-account results would be statistically meaningless anyway — what transfers is the design.

Part of the Agentic AI module: Build an LLM Trading Agent (the from-scratch architecture guide) · LLM Trading Research Landscape · Multi-Agent Trading Architectures · Do LLM Trading Agents Actually Work? · Commercial Agentic Trading Products.

The System's Shape

The loop is cron-driven, not event-driven — a deliberately boring choice that makes every decision reproducible and auditable:

Agent-loop diagram: Data Ingestion feeds LLM Signal Generation, which feeds Guardrails, which feeds the Execution State Machine, which feeds Performance Feedback below it, which loops back with a curved arrow underneath to LLM Signal Generation
The same five-layer loop taught in Build an LLM Trading Agent — the production system on this page is an instance of that shape: the LLM proposes, code-level guardrails gate, deterministic code executes, and feedback closes the cycle.

In live mode the broker (Tradier) holds a native OTOCO bracket server-side, so the resting stop and target survive even if our box dies; the loop's job shrinks to trailing, time-based exits, and reconciliation.

Bounded Discretion: the Model Proposes, Code Disposes

The single most important design decision: the LLM never has authority, only influence.

The Tape Is the Weakest Link

Nothing in this project consumed more debugging than data quality, and every incident produced a defense that is now permanent:

Guardrails With a Birth Certificate

Every mechanical veto in the entry path exists because of a specific, logged failure — none were designed from imagination:

Two-row pipeline diagram: Numeric Packet feeds Model Read, which feeds Clamp, which feeds Event Blackout; the path then drops to a second row where Climax-Chase Veto feeds Stop Geometry, which feeds Sizing and Risk Caps, which feeds the final Order box; every stage after the model read is a mechanical gate that can stop the entry
The entry path's guard stack: packet → model read → clamp → event blackout → climax veto → stop geometry → sizing and risk caps → order. Illustrative — every stage after the model read is deterministic code, any gate can kill the entry, and the next grid tick simply re-reads.

Falsifiability: Score Every Read, Not Every Trade

A system that trades a few times a week cannot be evaluated on its trades for months. The loop therefore grades every logged directional read — roughly forty per week — against what the underlying actually did 15, 30, and 60 minutes later: hit rate, signed edge, and calibration of the high-probability flag, computed nightly from the ledger.

This also disciplines the prompt itself. A context input earns a slot in the packet only if it is mechanical, scalp-timeframe-relevant, and scoreable after the fact; anything else is rationalization fuel for a language model that is very good at rationalizing. Several plausible-sounding inputs have been rejected under that razor, and at least one untested heuristic the model exhibits (refusing entries late in a trend as “exhausted”) is on the docket to be graded — not assumed — from the same logs.

Reconciliation, or: Live Trading Is a Distributed-Systems Problem

The paper-to-live transition surfaced a class of bugs that backtests cannot show, all of the flavor “two systems disagree about reality”:

What We'd Tell You to Steal

  1. Bounded discretion. Give the model a vote, never a veto over your risk layer. Clamp everything it suggests.
  2. Treat staleness as the default state of market data, and make every decision path prove its inputs are fresh.
  3. Log for falsifiability from day one. Counterfactually score every read; make every guard's rejection a ledger event. You will tune on evidence instead of vibes.
  4. Let guardrails be post-mortems, not speculation. Ship the minimal loop, then convert each real failure into exactly one mechanical rule.
  5. Do the live-execution engineering. Fill races, partial fills, cancel verification, and reconciliation are where paper systems die in production.

Frequently Asked Questions

Does the LLM place trades directly?
No. It returns a structured opinion; deterministic code applies clamps, vetoes, sizing, and risk caps before any order exists, and mechanical stops sit beneath everything it does.
Why an LLM at all instead of pure rules?
The multimodal read (chart + numeric packet) handles regime nuance that brittle rules encode poorly -- but only inside guardrails, and only because every read is counterfactually scored so its edge is measurable rather than assumed.
What was the hardest engineering problem?
Data integrity: delayed feeds, missing minutes, and load-balanced endpoints serving stale snapshots. Staleness detection and freshness gates mattered more than any prompt change.
Is this a recommendation to run one?
No. It is an engineering case study; short-dated options are a fast way to lose money, and nothing here is investment advice.

Build the same bounded-discretion pattern yourself on a paper account, or see what independent live benchmarks found when they tested agents like these.

Build Your Own →   Do They Actually Work? →