I Asked Opus to Trade Crypto. That Was the Wrong Job for an LLM

What started as a bad idea turned into a much better architecture.

A few months ago, I sat down in front of Claude Opus and gave it a goal that now sounds ridiculous: come up with a strategy that makes $50 a day, because I am nothing if not a pragmatist.

That was the plan. Give a powerful model market data, connect it to an exchange, and let it figure things out.

I am not a quant. My background is full-stack web3 engineering. I came at the trading problem as a systems builder rather than a market researcher, and that framing turned out to be the useful part. The exercise exposed, very quickly, where LLMs belong in a system and where they absolutely do not.

The first mistake

The first version was the obvious version.

Prompt the model with the goal. Give it access to market data. Let it analyze the market, decide what to do, and place trades.

This is the kind of architecture people sketch when they are still intoxicated by what the model can do in a chat window.

It did not work.

The model’s weaknesses were sitting at the point of maximum consequence.

Letting an LLM make real-time decisions with real money is a bad system design choice. You have placed a nondeterministic component exactly where you need precision and consistency. The general case is covered in Part 1. Here I want to talk about the specific architecture that fell out of getting it wrong.

The second insight

The real breakthrough was realizing what I actually wanted: a strategy development system.

That sounds like a small shift in language, but it changes the architecture completely.

Strategy development is exploratory work. It benefits from breadth, iteration, and unusual combinations. This is where a language model can be genuinely useful.

Trade execution is the opposite. It needs explicit rules, fixed constraints, and deterministic behavior.

Once I separated those two jobs, the system started to make sense.

The pipeline that fell out of this

Once the role of the model became clear, the architecture got specific. The system I ended up with, call it the research pipeline, looks like this:

Strategy proposer       (LLM: explores structures)
        ↓
Specialist / critic     (LLM: tightens the proposal)
        ↓
Iterator / refiner      (LLM: variations within a structure)
        ↓
Optuna optimization     (algorithmic: parameter search vs. Sharpe)
        ↓
Backtest                (deterministic: historical performance)
        ↓
Out-of-sample           (deterministic: validation on held-out time
validation               periods, assets, and venues)
        ↓
Stability / regime      (deterministic: behavior under different
checks                  market conditions)
        ↓
Promotion / rejection   (deterministic: pass/fail gate)
gate
        ↓
Paper trading           (deterministic: live data, fake money)
        ↓
Live execution          (deterministic: live data, real money)

The frame is agent-driven research, with deterministic rails around it.

A larger model explores and proposes strategy structures. A smaller model generates variations inside a structure that already looks promising. A search and optimization layer tunes parameters. A deterministic validation layer runs backtests, measures drawdown, scores results, and filters out weak candidates. A deterministic coordinator decides which validated strategies are allowed to run under which market regimes. And the executor just runs the math.

None of this makes trading easy. Backtests lie, fees matter, paper trading is not execution, and optimization can overfit beautifully. That is exactly why the model should be upstream of the gauntlet, not downstream of it.

No LLM directly authorizes live fund movement.

That ended up being the most important lesson of the whole project: an LLM should never be the ungated component that moves money.

This is a hard boundary, not a dial you tune. The LLM feeds a search process. The search process feeds a validation gauntlet. The validation gauntlet feeds an executor that has no opinions. The model stays on one side of that boundary and the money stays on the other.

Every stage has a job. The probabilistic stages explore. The deterministic stages filter and execute. The interface between them is the gate, and the gate is the architecture.

What changed once the costs dropped

There was another lesson hiding inside the architecture.

When inference is expensive, you ask the model to be brilliant. You want every run to count.

When inference is cheap, which it is on local compute, you ask the system to be selective.

That changes the strategy.

Instead of trying to get a frontier model to produce a small number of brilliant candidates, you can generate a large number of decent candidates, run deterministic filtering, and keep only the survivors.

That produces more validated strategies per dollar of compute, because you are sampling the strategy space densely instead of betting on a few expensive runs.

The intelligence lives in the pipeline that generates, tests, scores, and discards. Any one model call is disposable.

Once you see it that way, the architecture becomes much less mystical. The model feeds a search process. The pipeline is the asset; any individual model output is disposable.

Why this generalizes beyond trading

Trading is a useful teaching case because the consequence is unambiguous. Money moves. Strategies fail in measurable ways. The validation gauntlet has objective scores attached at every stage.

But the same architecture applies to any agent system where the cost of being wrong is real:

Code that ships to production
Communications sent on someone’s behalf
Database mutations
Permissions granted
Transactions signed

Take two of them. For code, the model proposes a patch; tests, type checks, review policy, and deploy gates decide whether it ships. For email, the model drafts; approval rules and human review decide whether it sends.

In every case, the right move is the same. Use the model to explore the space of possible actions. Use deterministic systems to filter, validate, and execute. Put the gate between them, and put the gate in a place where you can audit it.

The naive design puts the LLM at the end of the pipeline because that is where the decision happens. The right design puts the LLM at the front of the pipeline because that is where breadth is useful. The model does not earn trust by sounding confident; the system grants it only after checks pass. Between the model and the consequence sits a gate, not a gradient. The model explores on one side; deterministic systems execute on the other.

The real punchline

I started with a fantasy: prompt a powerful model, connect it to a market, and collect profits.

I ended up with a more useful architecture.

The LLM explores.

Reproducible systems optimize.

Deterministic systems validate.

Deterministic systems execute.

The lesson was not that agents can trade; it was that agents need a consequence boundary.

The model proposes. The pipeline trades.

Steve Ciraolo is the founder of Rank One Labs, where he builds agent operations infrastructure for AI-native teams and provides integration assurance for systems that touch real consequences, on-chain or off.