The Vision: One LLM to Rule Them All

SaaS vendors all want to call their own LLM, and enterprise IT hates it.

Why is MS Copilot ubiquitous, even though it nerfs the models it runs on? (Requiring permissions, won't take action on its own, etc. Next to a tool like Claude Code the difference is night and day.) Because the goal of large businesses is to not make mistakes. So when Microsoft comes to meet with the CIO, they can say "we know you're worried about risk with these tools, so let us handle that for you."

Walk into any large enterprise right now and you'll see IT and data leadership are putting a wall around 1 or 2 sanctioned LLM providers where they can enforce use policy. The real concern now is the explosion happening outside that wall. Every SaaS vendor on the market now ships an "AI-powered" feature, which means every vendor is quietly calling some LLM on the backend.

We started getting increasingly onerous, specialized IT security questionnaires this year, created for any company with "AI" in its name. We had considered adding an LLM into River, but this made us change our minds. Enterprise IT is clearly trying to force AI centralization. Which, frankly, is the right decision.

LLMs are good at data analysis; LLMs are bad at data analysis

You've got a central LLM! Now what?

1. LLMs are incredible at straightforward data analysis. They can write 20 SQL queries and apply a novel ML method from a single prompt. Watching an LLM complete an analysis is jaw-dropping.
2. LLMs are terrible at end-to-end analysis of raw business data. In order to do that much analysis in 2 minutes, an LLM makes a lot of assumptions. For a good human analyst, reasonable assumptions are based on a holistic understanding of business processes, plus years-long context and battle scars. But the LLM doesn't know that one data set's definition of "week" is 6 days and another is 7 days. It doesn't know that the stated sales figures are entered by hand and therefore more prone to error than the inventory values. It doesn't know you tried to run a similar analysis 3 years ago, and it failed for some specific reason it's now trying to work through again. The analysis is competent, the answer is wrong, and it reads as authoritative either way. A better model can't fix this, because the context is massive, distributed across the organization, and isn't written down anywhere.
3. LLMs are stochastic. When we were building our MCP server (a layer that tells an LLM how to use River), it kept misinterpreting the full data sets we were giving it. Sometimes it would do math that was wrong because it did not understand the data. Sometimes it would sum over things that shouldn't be summed. But worst of all, the answer to the same query was different every time. LLMs have to invent their own analytic methods and assumptions. If the leash is long enough, the answers will be different. You can't have the SVP of Supply Chain get a different number for Out-of-Stock risk than the VP of Planning.

The winning formula is to build deterministic tools that don't just expose the business's data, but encode its logic as something the central LLM can run, query, and modify.

This is not a new observation. There is a whole category of software (dbt, Cube, Looker, etc.) that exists so that "revenue" means the same thing everywhere in a business. But a knowledge graph, RAG, governed metrics layers, etc. all just let the LLM look things up.

To make a real decision, the LLM has to act on the business's logic. We need tools that encode the business logic, so the LLM can run a simulation, ask a what-if, weigh alternatives, optimize against a goal, etc.

On the complex end, a tool like Pillar AI's River builds a probabilistic simulation of a company's supply chain flows. Instead of looking at the raw planned inventory data and inventing a new analysis, the LLM queries River, gets a probability of a stockout, changes an assumption, and re-runs the simulation to see what happens.

Let the LLM be creative about what to analyze and how to compose the analysis. Don't let it be creative about the analytical machinery the business depends on.

Triaging five thousand SKUs.

Put several of these tools together. Suppose you ask your central LLM to figure out which of your underperforming SKUs can be fixed and which should be rationalized. It's a real strategic question, and exactly the kind of thing that gets a bad reputation as a use case for LLMs today.

Here's how it could go.

1. The LLM pulls your strategic segmentation (the one your leadership team aligned on) and identifies SKUs with weak commercial performance and poor operational execution. Let's say five thousand candidates.
2. For each one, the LLM queries your supply chain simulation, running roughly a hundred thousand simulations to ask whether service can be improved while reducing working capital, and at what cost.
3. Then it goes to your price elasticity simulation, another deterministic tool, and runs another hundred thousand simulations to evaluate pricing and distribution levers.
4. Finally, it synthesizes across all of it, grouping the five thousand SKUs into buckets: fixable operationally, fixable commercially, fixable through a combination, or genuinely worth rationalizing.

The LLM did not build a segmentation. It did not estimate elasticities on its own. It did not simulate the supply chain in its head.

But the LLM did do something no human analyst could have done in a reasonable timeframe: it composed the workflow, drove two hundred thousand simulations across five thousand SKUs, and turned the results into a structured recommendation. That's a real contribution to a real strategic decision, and it's only possible because the deterministic tools were in place.

The future of enterprise AI isn't a bigger model. It's a better-equipped one.

The enterprises that get the most out of their central LLM over the next few years will start making its surrounding tooling richer. The LLM is a remarkable interface. It is not a remarkable analyst, at least not for the decisions where consistency and defensibility matter most.