Why Deterministic Workflows Beat LLM-Native Data Access

The safest way to put an LLM into a business workflow is to not let it decide where the data comes from. Use the model to reason over data you fetched deterministically, and keep it off the critical path where a wrong turn becomes a wrong answer nobody catches. A model reasoning over the correct rows is doing the thing it is good at. A model deciding which rows are correct is doing the thing it is worst at, and doing it silently.

S&P Global just made this distinction the headline of a product. On July 21, 2026 they launched Adaptive Retrieval alongside their existing Deterministic Retrieval, and shipped both through one AI Data Portal. Deterministic Retrieval, built on the Kensho LLM-ready API, answers a structured query: ask for a specific company, a specific transcript, get exactly that. Adaptive Retrieval lets an agent take a natural-language request, decide which datasets to touch, and assemble the answer itself. Their own framing tells you which one they trust for what: deterministic for focused, controlled tasks, adaptive for open-ended research where you can afford to check the work.

That is the correct split. It is also the split most teams get backwards.

The dominant pattern: let the model drive, then act surprised when it hallucinates

The default way people wire an LLM into operations is to hand it the whole job. Give the agent a question, let it pick the data source, let it run the query, let it write the answer. It reads beautifully in a demo. Then it goes into a real workflow and starts inventing a customer that does not exist, pulling last quarter's number when someone asked for this quarter, or confidently citing a document it never opened.

The failure is not the model being dumb. The failure is architectural. When the model chooses what data to fetch, every fetch is a guess. A guess that lands in a financial report or a customer-facing answer is indistinguishable from a fact until someone downstream gets burned. You have put the least reliable component of the system in charge of the one thing that has to be exactly right.

Retrieval quality is where hallucination is born or prevented. Hand the model the steering wheel on retrieval and you have not built an assistant, you have built a fast, articulate way to be wrong.

The Nyyon mechanism: a deterministic spine with the LLM in a bounded slot

We build workflows on a deterministic spine. A deterministic spine is a workflow where retrieval, routing, and side effects are handled by code, and the model only reasons over data the code already fetched.

The steps that move data, the queries that pull records, the branches that decide what happens next: those are code. Explicit, versioned, testable, the same inputs producing the same outputs every time. The LLM sits in specific, bounded slots inside that spine where judgment actually helps: reading a messy email and extracting fields, drafting a summary from records already fetched, ranking options a human will confirm.

The consequence is that the model can be wrong without the workflow being wrong. If it drafts a weak summary, the underlying data is still correct and a human sees the miss. If it misreads intent, the branch it triggers is still one of a fixed, known set, not an open door. The blast radius of a hallucination shrinks to the size of the slot, instead of contaminating the whole result.

This is not anti-LLM. It is the opposite. It is how you use a powerful, unreliable component without betting the outcome on its reliability. You do not depend on the model. You depend on the pipeline, and you rent the model's reasoning where reasoning is the job.

How it works in practice

Take a workflow that pulls a client's account status, checks three systems, and drafts a reply. Built right, it looks like this. Code authenticates and queries each system by ID. Code assembles the record. The LLM reads that assembled record and writes the draft. A person approves before it sends. Every number in the draft traces to a row a query returned, not to something the model decided sounded plausible.

Compare that to the agentic version, where the model is told "handle this client's request" and left to figure out which systems to hit. The second one demos better and fails in production, because the moment it picks the wrong account or the stale field, nothing in the system knows.

S&P Global sells the reliable path as a product because their customers cannot afford a hallucinated earnings figure. Deterministic Retrieval exists precisely so an AI system gets exactly the row it asked for, cited and auditable. Adaptive Retrieval is offered for the tasks where exploration is the point and a human will vet the output. Two tools, matched to two risk levels. The mistake is using the exploratory one where the controlled one belongs.

What changes if you build this way, and what does not

What changes: hallucinations stop being random and start being contained. You can point at exactly which slot a bad output came from and fix that slot. You get auditability for free, because every fact in the output was fetched by a step you can name. The workflow survives contact with reality, which is the only bar that matters once it is running unattended.

What does not change: the model still does the reasoning it is good at, and you still get the speed and flexibility that made you want an LLM in the first place. You are not trading capability for safety. You are putting the capability where it pays and the guardrails where the risk is.

The tradeoff is real and worth naming. A deterministic spine takes more design up front than pointing an agent at your data and letting it improvise. You have to decide what the steps are, which is the hard part, the part that is actually the job. Fully autonomous multi-agent systems will keep getting better, and the honest position is that the balance shifts over time. For any workflow where a wrong answer costs real money today, the deterministic spine with the LLM in a bounded slot is the version that ships and keeps working.

If someone is selling you an agent that decides where your data comes from, ask them what happens the first time it decides wrong. If you have a problem, if no one else can help, and if you can find them, maybe you can hire Nyyon.