Ask a frontier language model to compute a 14-day RSI from a price series and it will give you a confident, cleanly formatted answer that is wrong maybe one time in five, and hard to catch because the number lands in a plausible range. Now imagine that number sits inside an agent that decides whether to exit a position, escalate a fraud alert, or approve a credit line.
This failure mode is spreading through the agent boom. Teams are wiring LLMs into trading and risk systems, and many of them are letting the model participate in calculations. Nobody decided this was a good idea. The boundary just never got drawn. The prompt says "analyze the market data and decide," the model obliges, and somewhere in that reasoning chain it silently invents a moving average.
The fix is a single architectural rule: in any quantitative system, every number the system acts on must come from deterministic code. The language model can read numbers, rank them, explain them, and choose between actions they imply. It must never produce them.
What the boundary looks like in practice
I spent the past few months building a systematic engine for short-term equity and ETF positioning, designed from the start to sit underneath an LLM orchestrator. The design question was how to make the model's arithmetic irrelevant by construction.
The answer has three parts.
First, a deterministic scoring core. All indicators, regime classifications, and position scores are computed in a typed Python library with no model in the loop. The macro-regime classifier, for instance, weights six market signals: equal-weight versus cap-weight breadth, high-yield versus investment-grade credit spreads, small-cap relative strength, the equity-bond risk ratio, discretionary-versus-staples sector rotation, and the 10Y-2Y yield curve. When a data feed fails, the classifier redistributes that signal's weight across the survivors according to a fixed rule. There is no model anywhere in that path.
Second, decisions expressed as an enumerated cascade rather than free-form reasoning. The engine implements a chain-of-responsibility with nine prioritized actions: exit on exhaustion, re-enter on rebound, and so on down the list. The first rule whose conditions are met fires; the rest never execute. The LLM's job is to invoke the engine, receive a typed result, and translate it into narrative and workflow. It selects among outcomes the deterministic layer has already validated. It cannot invent a tenth action, and it cannot nudge a threshold.
Third, tests that only a deterministic core makes possible. The engine ships with 53 unit tests covering indicator identities and boundary conditions: does RSI hit exactly 100 on a monotonic series, does the cascade fire the right rule when two conditions are simultaneously true. You cannot write that test suite against a model call. A component that returns a slightly different paragraph at temperature 0.7 is not a component you can regression-test, and a system you cannot regression-test is not a system you can put behind real money.
Why "make the model better at math" is the wrong project
The objection I hear most often is that models are improving fast, tool use is getting reliable, and the arithmetic problem will solve itself. Partially true, and beside the point. Even a model that computes RSI correctly 99.9% of the time fails three ways a library never does.
It fails silently: there is no exception, no NaN, just a fluent wrong number. It fails unauditably: when a regulator or an internal model-risk team asks why the system exited a position on March 4th, "the model reasoned about it" is not an answer, whereas "rule 3 of 9 fired because the credit signal crossed its threshold at 14:32" is. And it fails unreproducibly: rerun the same inputs and you may get a different trace, which makes incident review a guessing game.
Anyone who has taken a model through validation in a bank knows these three properties, not raw accuracy, are what model risk management interrogates. SR 11-7 and its European equivalents were written for exactly this: systems whose outputs cannot be explained or reproduced do not clear governance, however impressive the demo.
The division of labor
LLMs still belong in quantitative systems, in the places where they are strong. They are good at synthesis across messy sources, at translating a typed result into an explanation a human can act on, at deciding that a situation is unusual enough to escalate, and at operating the surrounding workflow: fetch, compare, summarize, notify. In most institutions that work, not the modeling, is the bottleneck.
The pattern generalizes well beyond trading. A fraud triage agent should read scores from a model server, never estimate them. A credit workflow agent should call the pricing engine, never approximate it. In each case the deliverable is the same: a hard contract at the boundary, typed structures crossing it, and an enumerated action space on the far side.
The teams that ship durable agentic systems in finance over the next two years will be the ones who decided, early and in the architecture, which layer is allowed to do arithmetic. Draw that line before your agent draws it for you.
The engine described here is open source: https://github.com/alinakhay/Quant-Regime-Engine. I write about quantitative finance, market structure, and applied AI at https://alinakhay.com/.
Top comments (0)