AI knows business. It doesn't know yours.

The advantage is not the LLM

Why the competitive advantage of AI in business doesn't lie in the LLM, but in your own business model.

Let's run an experiment.

Open any frontier model and ask it:

What should a company do if a critical supplier stops delivering for six weeks?

The answer will be good. It will talk about alternative suppliers, prioritizing customers based on profitability, reallocating inventory between distribution centers, renegotiating terms, and comparing the cost of air freight against the cost of a stockout. It will be well-written and completely reasonable.

Now let's ask the question that really matters to us:

What should we do if Supplier X (our critical supplier) stops delivering for six weeks, and what happens in that scenario to our inventory, service level, margin, and cash flow?

This is where the problem begins, and it's not the one you might expect. The LLM won't refuse to answer. It will respond with the same fluency, propose a course of action, and if we ask for numbers, it will give us numbers.

The problem is that neither it nor we have any way of knowing if those numbers are accurate.

Because the model doesn't know our actual costs, our capacity constraints, our lead times, our allocation policies, how our customers behave, or, above all, the specific way all those variables affect each other. It knows a lot about companies. It doesn't know how this one works.

‍

‍

Context is not enough

The instinctive response is to give it better information: connect it to the ERP, the data lake, the procedures, the contracts, and the management reports.

That is useful, and it's worth doing. But it confuses two different things.

Having access to information about a company is not the same as understanding its mechanics. Knowing today's stock, the costs from the last closing, and last month's demand doesn't allow you to answer what would happen if we changed a decision tomorrow. For that, you have to represent the relationships between those variables, not just their values.

If demand changes, inventory changes. If inventory changes, replenishment changes. If the production plan changes, capacity utilization, material requirements, and costs change. And all of that ends up shifting sales, margins, working capital, and cash flow.

Data answers what is. A model answers what if.

And here comes the uncomfortable part, which predates AI by decades.

‍

‍

The knowledge exists, but it doesn't live anywhere

The obstacle isn't just that the LLM doesn't know the business. It's that, in most organizations, no one has that knowledge formalized in an integrated way.

Part of it lives in the managers' experience. Another part lives in spreadsheets built and patched over years, whose logic only one person understands. Another is scattered across the ERP, the forecasting tool, the financial model, and the specific applications used by each area.

Each piece holds a fragment of the business logic. Supply Chain knows the supply constraints. Operations knows the actual capacity, which is not the nominal capacity. Sales understands how customers react to a price change. Finance knows how all of that ends up impacting working capital and cash flow.

But the connections between those pieces—which is exactly where important decisions are made—exist primarily in the heads of the people sitting in the same meeting. There is no single place where you can read "this is how our business works." Much less a mechanism that updates that representation as the organization learns.

Even the flow of information between those pieces is unresolved: exporting, pasting into a spreadsheet, copying assumptions, reconciling versions, waiting for another process to close.

Thus, the company generates experience every day and has no way to convert it into cumulative knowledge. Each planning cycle begins by manually reconstructing an integrated view, a view that evaporates the moment the meeting ends.

Before asking AI to understand our business, we have to solve that.

‍

‍

A computable business model

There is a concept in AI research that is increasingly relevant here: the world model, an internal representation of an environment that allows for anticipating how that environment evolves in response to different actions, rather than just responding based on learned patterns.

In an organization, that world is the business itself. What is needed, then, is a Corporate World Model: an executable representation of how a company functions economically.

In its full scope, for example in an Integrated Business Planning process, it links demand, inventory, supply, production, costs, investments, sales, working capital, cash flow, and financial statements within a single system.

What separates it from a dashboard or a data warehouse is not data coverage, but the nature of the object. A dashboard shows the state of the business. A Corporate World Model contains the rules, constraints, mathematical relationships, and dependencies that cause a decision made at one end of the organization to propagate to the other.

This allows for a change in the verb: you move from observing the business to experimenting with it.

What happens if demand grows by 15%? What inventory level maximizes service without eating up working capital? What combination of production, purchasing, and allocation best protects the margin? What does moving this investment forward do to our cash position?

The term comes from AI research, but the question it answers is the oldest one in management: if I do this, what happens next?

‍

‍

And how do we know the model is correct?

This is the step that usually gets skipped.

Building a business model does not guarantee that the model is accurate. Every representation is a simplification. There are poorly calibrated parameters, undocumented constraints, behaviors that resist formalization, and effects that only emerge under certain conditions.

An LLM running on a flawed model does not produce better decisions. It produces flawed decisions that are better written.

The good news is that the evidence needed to correct it already exists, and the organization generates it every month. It just uses it poorly.

Think about the monthly variance review. Demand wasn't what was expected, the exchange rate shifted, the mix skewed toward lower-margin products. The causes are reviewed, the assumptions for the next cycle are adjusted, and the meeting ends. It is a reasonable ritual, but it only answers one question: Why didn't the future turn out the way we imagined?

There is a second question that is almost never asked: Now that we know exactly what happened, could our business model have explained it?

The first questions our forecast. The second questions our understanding.

‍

‍

Two errors within the same variance

Let's take a deliberately simple case.

The monthly plan projected 100 units at a price of 10, with a variable unit cost of 6 and fixed costs of 250. Expected result: 150.

The month closed with 80 units sold and an actual result of 60. Total variance: –90.

The usual conversation ends there: we sold less than planned. But we can do more. We can re-run the model, replacing the demand assumption with the actual value (80 units) and leaving everything else exactly as it occurred.

Fed in that way, the model returns 70.

That splits the variance into two:

• –80 is a forecast error. We failed to anticipate the demand. This is a problem of information about the future, and it will always exist.
• –10 is a model error. Even knowing every external variable perfectly, our representation of the business fails to reproduce what reality produced. There is something about how the company works that is not in the model.

That second number is the interesting one. Investigating it reveals, for example, that producing 80 instead of 100 left the plant below the utilization level where performance degrades, and the actual variable cost was 6.125 instead of 6. The model assumed a constant unit cost. It is not.

Ten monetary units seem small compared to ninety. But the asymmetry between the two errors is the core of the argument:

The forecast error is random and dies with the period. The model error is systematic and contaminates every future decision.

That constant cost assumption didn't just fail this month. It is silently biasing every low-volume scenario the model evaluates: the analysis of a promotion, the decision to accept a marginal order, the evaluation of discontinuing a line, the break-even calculation. Every answer the model has given and will give in that area is wrong in the same direction.

Improving the forecast improves a plan. Improving the model potentially improves every decision made about that business.

‍

‍

The learning cycle

The way to turn this into a process is a learning cycle: a cycle in which the model not only produces plans but also corrects itself against what reality returns.

Its central step is to re-run a closed period within the model, replacing each assumption with the value that actually occurred: actual demand, actual prices, actual exchange rates, actual lead times, actual costs, and—this is essential—the decisions that were actually made, not those proposed by the plan.

Then, what the model says should have happened is compared with what actually happened.

If they match, the model represents that part of the business reasonably well, and the deviation was just a forecasting issue. If they don't match, we have found something more valuable than a budget variance: we have found an area of the business we don't yet understand.

Every gap in the re-run is a hypothesis waiting to be tested. Perhaps price elasticity isn't what we assumed. Perhaps that lead time depends on a variable we are ignoring. Perhaps a production constraint behaves differently above a certain utilization level. Perhaps a commercial policy produces a second-order effect that the model never contemplated.

The complete cycle looks like this:

Model → Plan → Decide → Execute → Observe → Re-run → Compare → Learn → Improve

Planning ceases to be just an instrument for anticipating the future. It becomes a systematic mechanism for better understanding the business.

There is an operational requirement worth stating out loud, because it is the one that usually fails: the learning cycle requires recording decisions, not just results. If the system records that 80 units were sold but not that inventory was reallocated between two distribution centers in week 3, the re-run will compare against a history that never happened. A good part of the initial work in this discipline consists, simply, of starting to leave a trail.

‍

‍

Now, where does the LLM come in?

With this architecture, the role of the language model changes quite cleanly.

It stops being the place where we expect all the answers to live. It becomes the interface that interprets the question, formulates the hypothesis, triggers the calculation, compares scenarios, and explains the result in business terms.

The LLM understands the question. The Corporate World Model simulates the consequences.

Let's go back to the supplier that stops delivering for six weeks: the question is asked in natural language, but the answer no longer comes from what the model read about supply chains in general. It comes from running that disruption against a representation of our own operation, with our capabilities, our contracts, and our mix.

But there is a second role, less obvious and just as interesting: the LLM can read the residuals from the re-run.

A model gap is, essentially, a table of differences between what was calculated and what actually occurred, broken down by product, plant, period, and income statement line. Interpreting that pattern—filtering out the noise, noticing that the differences are concentrated in months of low utilization, conjecturing that the unit cost is not constant—is exactly the type of inductive reasoning on structured data that these systems excel at.

That is where the cycle truly closes: the model produces predictions, reality produces evidence, the LLM proposes structural revisions, and the team decides which ones to adopt. The decision remains human, but detecting and conjecturing no longer depend on someone having the time to look.

‍

‍

What a skeptical reader will ask

"We already have a model: the spreadsheet." True, and that is precisely the point. The spreadsheet is already a business model; what it lacks is traceability, integration between departments, the ability to run scenarios in series, and any memory of its own errors. The difference isn't between having a model or not. It's about having one that learns.

"This is overfitting the model to the noise." Yes, if you correct the structure after every single-period gap. The criteria must be the opposite of traditional variance analysis: an isolated gap is ignored; a gap that repeats with the same sign under the same conditions is a signal. Re-runs should be read in series, not one by one.

"There are things that cannot be modeled." That is also true. A competitor's move, a regulatory decision, how a key account reacts to a change in account manager. The goal is not a complete model of the world, but one that explains the structural part of the business and is explicit about where it ends.

It is worth adding that none of this is a recent invention. Control engineers call it system identification, and industrial digital twins have worked this way for years. What is new is applying it to the economic layer of the company—not to a machine, but to the entire business—and coupling it to an interface capable of discussing the results.

‍

‍

The asset that capitalizes itself

LLMs will continue to improve and become increasingly accessible. Precisely for that reason, they will differentiate less and less. If a competitor can license the same model tomorrow, the model is not an advantage.

What cannot be bought or replicated in a quarter is a computable representation of how a specific company works, corrected against reality cycle after cycle for years. Each period generates evidence. Each gap reveals something we didn't understand. Each turn of the cycle improves the representation. And every improvement propagates to all future decisions.

It is an unusual type of asset: one that accumulates value with use.

Let's go back to the beginning. AI knows business, but it doesn't know yours, and a larger model won't solve that: the LLMs of the future will know even more about companies in general, and exactly the same amount about yours.

What does solve it is coupling them to a model of your business that learns from reality cycle after cycle. That combination cannot be bought. It is built, and it takes time.

That is why the question is not which LLM you will use next year. It is how many learning cycles your model will have had by then.

‍