Approximation vs. Computation: Why LLMs Should Not Do Your Arithmetic

An LLM asked to compute a Roth conversion is not computing. It is producing the most likely-looking answer given the surrounding text.

A user typing how much can I contribute to my Roth IRA in 2026 at age 55 into a chat product looks like they are asking a factual question. They are. The product looks like it is answering one. It usually is not. The gap between what the user assumes and what the model is actually doing is the reason financial LLM interfaces need a computation layer, not a better prompt.

What the model is doing

A base language model, given that prompt, does one thing: it produces the most probable next tokens conditioned on the input. The output happens to be numerical because the training data around Roth IRA contributions is numerical. The model has not looked up a limit. It has not performed arithmetic on a catch-up amount. It has predicted what a plausible answer looks like, given that the training corpus contains millions of examples of people writing about Roth IRA limits.

This is not a criticism of language models. Token prediction is what they are for. It is a criticism of asking one to do work it was not designed to do, and then displaying the result as if it had done that work. A model that has memorized a Roth limit from a document produced in 2022 will confidently produce that limit in 2026, in the same cadence as any other answer, with no indication that the number is three years out of date.

Why the failure is invisible

The reason this failure mode persists is that language models produce wrong numbers with the same fluency as right numbers. A model that returns seven thousand dollars for a 2026 IRA limit and a model that returns seven thousand five hundred dollars will both produce a confident, grammatical sentence. The user has no signal that one is stale and one is current. There is no red underline, no timestamp, no version, no source. There is just prose.

Retrieval augmentation improves the situation somewhat by grounding the model in a document. It does not solve it. Retrieval finds a passage; it does not perform the math the user actually asked for. If the user's question requires combining a limit with an age band, an income phase-out, and a spouse's contribution history, the retrieved passage answers none of those questions on its own. The model still has to compose the answer, and composition is where the fluent-but-wrong output returns.

The tool-call pattern

The alternative is architectural, not linguistic. The chat product still writes prose. The number in the prose is produced by a deterministic function — a model, in Worthune's vocabulary — that the assistant is required to call. The assistant does not compute. It delegates. The response includes the tool call, the inputs, the outputs, the version of the model that ran, and the constants used. The user reads the prose; the compliance officer reads the tool-call trace.

Model Context Protocol, MCP, is the emerging standard for this delegation.^[1] An assistant configured with the Worthune MCP server can enumerate available models, read each model's contract, and invoke a model by name with typed inputs. The response is not a paragraph; it is a JSON envelope with a spec version and a hash. The assistant then translates the envelope back into prose, citing the version. The prose is human-readable. The trace is machine-verifiable. The number is the same in both.

“The user did not ask for a plausible number. They asked for a correct one. Those are different products.”

Where the pattern applies

Not every financial question requires a tool call. A question about what an IRA is can be answered with prose. A question about the difference between traditional and Roth can be answered with prose. A question with a number in the answer cannot. The rule that has held up in practice is that any answer whose correctness depends on a constant, a formula, or an arithmetic operation is a tool call. Any answer whose correctness depends on definition, framing, or context is prose.

The line is not always obvious to the assistant. A prompt like should I convert my Roth this year sounds like advice; it is actually a Roth-vs-traditional break-even model plus a tax-projection model plus a narrative wrapper. The assistant that answers with prose alone is wrong. The assistant that calls the two models, cites the versions, and then writes the narrative is right.

What this means for a shipping product

A financial assistant that ships with tool-call discipline has four properties a prose-only assistant does not. Its answers are reproducible: the same input produces the same envelope, and the envelope produces the same answer. Its answers are current: the constants come from a registry with revision dates, not from training data. Its answers are auditable: the tool-call trace is a compliance artifact. And its answers are refusable: when the input is out of range, the model returns an error and the assistant surfaces it, rather than the model inventing a plausible number.

The last property is the one product teams underweight. A refusal is a feature. A calculator that returns an error when a user enters a negative interest rate is not a broken calculator. It is a validated one. An assistant that refuses to answer when the underlying model refuses is not a limited assistant. It is a truthful one. The alternative — an assistant that answers anyway — is the failure mode this article exists to prevent.

A working test for any deployed assistant

Send the assistant a prompt that requires a current-year constant to answer correctly. Log the response and the tool-call trace. If the response contains a specific numerical answer and the trace is empty, the assistant is guessing. If the response is a specific numerical answer and the trace contains a call to a deterministic model with the current spec version, the assistant is computing. There is no third state. Products that pass this test have earned the right to display a number. Products that fail it are shipping fluent prose about arithmetic, which is a category-different product than the one users think they are using.