Why Agentic Analysis Needs a Validated Business Reasoning Model—not a Collection of Answers
Two AI-generated analyses can look almost identical.
In Part 1, I decomposed a demand-diagnosis process into different tasks and assigned one of them to an LLM:
Compare possible causes and decide which evidence to examine next.
But what does that task actually involve?
Two AI-generated analyses can look almost identical.
Both may contain SQL, calculations, charts and a polished report. Yet the role played by AI can be fundamentally different.
In one, AI builds the analysis I already have in mind.
In the other, AI investigates the business problem.
That difference is easy to miss because the final reports may look the same.
But one scales analytical construction.
The other expands what the business can discover.
When AI Builds the Analysis I Describe
Suppose I already believe that forecast accuracy deteriorated because demand changed.
I tell AI which products to examine, which periods to compare, which metrics to calculate and how to organize the report.
AI generates SQL, builds calculations, creates charts and drafts the explanation. I review the output, provide feedback and continue refining it.
This can feel like vibe coding applied to analytics.
It is highly valuable. Work that once required repeated coordination among business users, data analysts and developers can now be completed much faster.
But the business reasoning still resides with me.
I defined the problem.
I supplied the hypothesis.
I selected the evidence.
AI helped turn my reasoning into an analytical product.
When AI Investigates the Business Problem
Now consider a different interaction.
I provide the business objective:
Why did Product A’s forecast accuracy deteriorate?
The objective is defined, but the explanation is not.
AI begins with the obvious hypothesis: demand may have changed. It compares the forecast with actual sales and examines the historical error pattern.
But it does not stop there.
It checks inventory availability and discovers that the product was out of stock for nine of the twenty-eight days in the period.
This changes the interpretation.
Actual sales may have been suppressed by the stockout. A simple comparison between forecast and actual sales could therefore misattribute a supply failure to a demand-forecasting failure.
If the business reduced the forecast based on that diagnosis, it could make the shortage worse.
The difference was not the quality of the report.
It was who formed and tested the hypothesis.
When AI participates in business reasoning, it can:
- investigate more cases without requiring an expert to define every analytical path;
- discover explanations the user did not anticipate;
- challenge an initial—but potentially incorrect—problem framing;
- reduce the risk of acting on the wrong diagnosis; and
- apply expert reasoning more consistently across products, customers and locations.
In this example, the benefit is concrete: avoiding a forecast reduction that could have aggravated the shortage.
The first mode scales analytical construction.
The second expands discovery.
These benefits do not come from giving AI unrestricted freedom. They come from giving it validated business context, analytical methods, evidence and tools.
A Collection of Answers Is Not a Reasoning Model
Many enterprise AI projects attempt to improve analysis by collecting more answers.
They gather reports, expert comments, previous cases, decision trees and frequently asked questions. AI retrieves this material and produces a response that resembles what an expert might say.
This can be useful, but it does not necessarily teach AI how to investigate a new case.
A previous report contains the conclusion reached in one situation. It may not reveal which alternatives were considered, which evidence changed the diagnosis or why one explanation was rejected.
A collection of answers captures what experts concluded. A Business Reasoning Model captures how experts investigate.
This distinction reminds me of scenario analysis in consulting.
The reusable asset was rarely the final presentation. It was the method behind it: how we framed the problem, separated symptoms from causes, developed competing scenarios and tested them against evidence.
That method was not yet a Business Reasoning Model.
It became reusable by a system only when its concepts, hypotheses, evidence requirements and tests were made explicit, connected to data and validated against actual cases.
The expert’s role then begins to change—from repeatedly applying the method to every case, to owning, validating and improving the method that AI can apply.
What a Business Reasoning Model Contains
In Part 1, I described a Business Reasoning Model through the problem, relevant entities, states, possible causes, relationships, required evidence, decision criteria and authority.
For implementation, I organize those elements into three connected parts.
1. Business Context
Business Context defines what exists and what the data means.
It includes entities such as product, customer, location, forecast, order and inventory. It also describes their states, events, relationships and governed metrics.
Without this context, AI may retrieve correct data but interpret it incorrectly. For example, actual sales are not always equivalent to unconstrained demand.
2. Analytical Scenarios
Analytical Scenarios describe reusable ways to investigate a problem.
A scenario may state that declining sales could result from a demand change, a stockout, a production constraint, an order shift or a data-quality issue.
For each possibility, it can identify relevant evidence, counterevidence, analytical tests, available tools, potential business impact and the authority required for any resulting action.
These scenarios do not prescribe one fixed sequence.
They provide validated patterns from which AI can form and test hypotheses for the case in front of it.
3. Validated Cases
Validated Cases capture what happened when the reasoning was applied.
They record which hypotheses were considered, which evidence proved useful, which explanations failed, what uncertainty remained and what business outcome followed.
Cases are not stored merely as examples to imitate. They provide feedback on whether the reasoning method actually worked.
The first two parts reorganize the elements introduced in Part 1. The third adds operational evidence so the model can improve through use.
How the Model Connects to the System
A Business Reasoning Model is not implemented as one monolithic AI component.
Its different parts are represented through different technologies.
A Knowledge Graph can represent business concepts, states and relationships. A semantic layer can connect those concepts to governed data and metrics. SQL, analytical programs and existing ML models can test evidence. Agent Skills can expose reusable investigation methods. Validated cases can provide evaluation and feedback.
The model is therefore shared across the architecture rather than stored in a single prompt or document.
At runtime, AI retrieves the relevant business context, scenarios and previous cases. It forms an initial hypothesis, gathers evidence through available tools and revises the investigation when the evidence points elsewhere.
The report comes after that process.
It is built from findings that were tested—not from a conclusion supplied in advance.
AI Does Not Validate Its Own Business Logic
There is still an important limitation.
An AI-generated hypothesis is a proposal, not validated business knowledge.
It must be challenged with domain expertise, data and actual cases. A hypothesis that repeatedly fails should be revised or removed. A useful new pattern may be added to the Business Reasoning Model only after sufficient review.
Runtime experience should also flow back into the model.
Cases the existing model cannot explain reveal missing context, weak scenarios or unavailable evidence. The Business Reasoning Model is therefore not a one-time design artifact. It is an operating knowledge structure that develops through use.
The Shift Is in the Reasoning
AI can already make analytical work dramatically faster.
It can generate SQL, calculations, visualizations and reports from a person’s instructions. That alone is a meaningful improvement.
Agentic Analysis goes further.
It allows AI to apply a validated reasoning method to the business problem itself—to form hypotheses, examine evidence, reconsider the initial framing and construct an explanation that the user did not provide in advance.
AI can build an entire analysis without performing the business reasoning behind it.
The real shift begins when AI can form and test an explanation we did not provide.
But once AI can explore more freely, another question becomes unavoidable:
How much authority should it have over the conclusions and actions that follow?
That is the subject of Part 3:
Constrain AI’s Authority—not Its Imagination.