In AI trading, which model comes first: the AI model or the trading model?

This is private exploration and general reflection, not financial, investment, tax, or legal advice.

I like this question because it looks simple and then refuses to stay simple. "What AI model should I use for trading?" sounds like a clean architecture choice. Transformer or LSTM? Supervised learning or reinforcement learning? Maybe some hybrid. But when I followed the actual Alpaca-shaped problem a little further, I kept running into a different obstacle: the word model was doing too much work.

In one sense, the AI model is the thing making a forecast. In another sense, the trading model is the set of rules that turns forecasts into positions. Then there is the execution model, which decides what fills you actually get, and the risk model, which decides how much damage you permit before the system stops pretending it still understands the regime. If those are blurred together, the conversation gets dramatic too early. It starts sounding like a hunt for a magic predictor when the real work is system design under cost and uncertainty.

The word model hides four different problems

That table is probably the core clarification I wish I had at the beginning. When people argue about "the model" in trading, they are often arguing about different layers of the stack without noticing it. My current view is that the AI model is almost never the first thing to isolate. The first thing to isolate is the tradable problem definition.

What changes once the broker is real

The research path behind this draft eventually stopped feeling like "which architecture wins?" and started feeling like "which constraints dominate?" On that point, the Alpaca surface matters a lot. As of April 2026, the official crypto docs still point to maker/taker spot fees, support for market, limit, and stop_limit orders with gtc and ioc, and a paper environment that explicitly omits market impact, latency slippage, queue position, price improvement, and regulatory fees. Those are not implementation footnotes. They change what kind of strategy is even plausible.

If the low-volume fee tier starts at 15 bps maker and 25 bps taker, a high-turnover strategy is not starting from zero. It is starting in a hole. If paper trading does not simulate queue position or market impact, then a backtest or paper curve can be directionally right and economically false. If the broker surface is spot-oriented, then long-or-flat timing systems immediately make more practical sense than academic long-short machinery that assumes a different venue.

Once those constraints are on the table, the ordering changes. The first question is not "which AI model should predict the next move?" The first question becomes something like: "What holding period, turnover budget, and cost tolerance give a forecast any chance to survive?" That is really a trading-model question before it is an AI-model question.

The formula I keep coming back to

Whenever this topic gets fuzzy, I end up reducing it to a rough expectancy equation:

net edge ~= gross predictive edge
           - fees
           - spread
           - slippage
           - adverse selection
           - forecast mistakes amplified by sizing

That is not a full trading model. It is just a forcing function. It reminds me that a slightly better forecaster can still be a worse system if it needs more turnover, more confidence than it really has, or more aggressive sizing to show its edge. A mediocre forecast attached to disciplined trading and risk rules can beat a more sophisticated forecast attached to sloppy execution. That is the part of AI trading discourse I think gets lost when the whole conversation collapses into model architecture.

What the research pass actually changed

I did not come out of the underlying research convinced that there is some single dominant architecture waiting to be named. The most useful bucket distinction was simpler than that:

• supervised signal models that forecast direction, returns, volatility, or regime
• ranking and allocation models that decide which liquid pairs deserve capital
• reinforcement-learning overlays that might help with sizing or execution once a slower signal already exists
• pure end-to-end RL systems that look elegant conceptually but are harder to trust once costs, overfitting, and regime change are treated honestly

That last category is where the language issue really matters. If someone asks for the best AI model, it is tempting to answer with the flashiest thing in the stack. But the research path I found more credible kept pointing back toward narrower first prototypes: liquid pairs, slower decision intervals, long-or-flat behavior, explicit volatility targeting, and hard stop conditions. That is not because the AI side is uninteresting. It is because the strategy model has to earn the right to become more complicated.

My current read is that the first serious prototype on this broker surface would probably look boring on purpose: a small basket of liquid spot pairs, decisions every few hours rather than every few seconds, conservative cost assumptions, a benchmark that is difficult to embarrass, and a rule that the paper system has to stay alive when the execution assumptions are made intentionally harsher. Only after that would I care much whether the forecaster is a tabular model, a temporal convolution, a patch-based transformer, or something fancier.

Why paper results lie politely

One subtle trap in this space is that paper systems usually fail in flattering ways. They fail by hiding the exact frictions that turn a forecast into a trade. The backtest gets the midprice. The paper account gets the best current quote. The fill arrives without signaling your intent to anyone. The partial fill logic is simplified. The queue behaves more kindly than an exchange would. Then someone concludes that the AI model worked when what really happened is that the execution model was imaginary.

I do not think that means paper trading is useless. It means paper trading answers a narrower question than people want it to answer. It is good for workflow, instrumentation, order-state handling, and sanity checks. It is not proof that the economic loop closes. If I were evaluating an early system, I would treat paper trading as an infrastructure test and treat any live micro-allocation phase, if it ever got that far, as a measurement phase for degradation rather than a victory lap for the forecast.

So which model comes first?

If I had to answer my own question provisionally, I would say the trading model comes first, or at least the AI model is not separable from it for very long. The forecast model matters, but only inside a structure that already answers some prior questions: what horizon is tradable, what costs are survivable, what fills are believable, what concentration is acceptable, and what conditions shut the system down.

That is the bigger reason this topic interests me. It sounds like a trading question, but it behaves like a systems question. The easy mistake is to search for intelligence first. The harder and more useful move is to define the environment that intelligence has to survive.

What still feels unresolved

I do not think this fully settles the architecture question. There may be broker surfaces, data advantages, or execution contexts where the AI model really is the main bottleneck. There may also be narrow places where an RL policy earns its keep earlier than I expect. But for the specific problem that prompted this draft, AI-shaped crypto trading through a broker with visible fees, constrained order types, and imperfect paper simulation, the ambiguity around the word model was the real first bug.

Once I noticed that, the problem got smaller, more honest, and much more interesting.