Deterministic Models vs. LLM-Generated Math

A language model asked to compute a Roth limit does not compute. It predicts the next tokens. Deterministic models do the computing. The hybrid pattern uses each for what it is good at.

There are two ways a financial product can put a number in front of a user in 2026. The product can call a deterministic model — an implementation of a documented specification that produces the same answer for the same inputs every time. Or the product can ask a language model to generate the number, either directly or by way of a retrieval step that gives the model a passage to quote. The two approaches have different failure modes, different latency profiles, and different suitability for different questions. The comparison below is about matching approach to question, not choosing one and ignoring the other.

Deterministic models

A deterministic model produces an output from inputs according to a specification. Given the same inputs and the same specification version, the output is guaranteed identical. The model can return a versioned response envelope that captures what was computed, from which the answer can be reproduced later. The model refuses out-of-domain inputs rather than clamping them into a defensible-looking answer. All of this is standard software behavior; none of it is exotic.

The strength of the deterministic approach is reproducibility. The weakness is expressiveness. A deterministic model computes what its spec says it computes. It cannot interpret an ambiguous user question, summarize a rule change in prose, or produce a narrative recommendation. The moment the user's question strays from the spec — into definitions, framing, or context — the deterministic model has nothing to say.

LLM-generated math

A language model asked for a number produces the most probable next tokens conditioned on the prompt. The output is numerical because the training corpus around the question is numerical. It is not the result of arithmetic; no addition took place. This produces a specific failure mode: the model produces confident, fluent, plausible answers that may or may not be correct, and the user has no signal to tell which.

The strength of the language-model approach is expressiveness. A language model can interpret ambiguous questions, produce natural-language explanations, and summarize context. The weakness is arithmetic. A model trained on documents predating a tax-year change will produce the pre-change number in the post-change year, in the same confident cadence as any other answer. Retrieval augmentation improves grounding without solving the composition problem: the retrieved passage answers what was said, not what should be computed.

The hybrid pattern

The hybrid pattern uses each for what it is good at. The language model interprets the user's question, extracts inputs, and produces a natural-language reply. The deterministic model, invoked as a tool call from within the language model's turn, produces the number. The reply cites the spec version that produced the number and stores the envelope alongside the conversation. Neither approach is asked to do the other's job.

The hybrid pattern is the working answer for most 2026 financial products. Consumer chat assistants that produce numbers on demand cannot afford the language-model-only failure mode; regulatory scrutiny and user distrust both close in on assistants that guess. Deterministic-only products cannot afford to skip the natural-language layer users now expect. The specific technical mechanism — direct API tool call, MCP server, agent framework — varies by product; the pattern does not.

What tool-use discipline looks like

A financial assistant that ships with tool-use discipline has three visible properties. First, when the user asks a question with a specific number in the answer, the assistant's tool-call trace shows a deterministic-model invocation with the exact inputs. Second, the assistant's reply cites the spec version that produced the number. Third, when the user's inputs are out of domain, the assistant surfaces the refusal from the model rather than guessing a plausible answer. Products with these properties hold up under careful users and careful reviewers; products without them depend on nobody checking.

The batch-1 Approximation vs. Computation piece develops the tool-use argument in more depth. This piece is the pattern-level comparison; that one is the specific case for why arithmetic and prediction should not share a job.

“Prediction fills in what is likely. Computation returns what is true. Products that need both should use both.”

When either approach is enough on its own

A definition-only product — a glossary, a concept explainer, a research summary — can be entirely language-model driven, and adding a computation layer would not improve it. A pure calculator embedded in a form-driven UI can be entirely deterministic, and adding a language-model layer would not improve it either. The hybrid pattern applies where the user surface is conversational and the correctness surface is computational. Most modern financial products live on that intersection now, which is why the pattern gets so much attention.

The evaluation grid callers should run

A caller evaluating whether to add a deterministic layer to a language-model product can run a specific test. Take twenty representative prompts that produce numbers in the current product. For each, log the language model’s answer and the correct answer against a primary source. Score the accuracy rate. There is no canonical threshold, but products scoring well below perfect on number-bearing prompts are clear candidates for a deterministic layer; products below are candidates. Score the accuracy rate again after one year without touching the model. Products whose accuracy rates hold are working from a stable training corpus; products whose rates degrade are drifting with the world.

The direction the category is moving

Language-model products with numerical answers are converging on the hybrid pattern. Many products that shipped in 2023 and 2024 with pure language-model answers have since added tool-call layers; the visible failure mode made the case for them. The category-level direction is toward more computation and less prediction on the specific class of answers that depend on constants or formulas.