Enterprise AI has spent the last few years chasing a simple objective: make the model better.
More context. Better reasoning. Longer tool chains. Larger models. More agents. More tokens.
That made sense when the main constraint was whether AI could produce useful work at all. But that constraint is starting to move. The harder problem now is not whether AI can produce a financial model, write code, summarize a contract, analyze an earnings call, or prepare an investment memo. It increasingly can. The harder problem is determining whether the output is correct enough to act on and proving how it was produced.
Generating work has become dramatically easier. Verifying the resulting volume of work has not. That distinction may define the next generation of enterprise AI architecture.
The winning system may not be the one with the most accurate model. It may be the one designed so the model is never trusted where correctness matters.
Macro Context: Generation Is Becoming Cheap. Verification Is Not.
Large language models are probability machines. That is not a criticism. It is the reason they are useful.
A deterministic system generally follows the same predefined path for the same input. An LLM can interpret ambiguity, plan a sequence of actions, infer intent, synthesize information, and generate something that did not previously exist.
That flexibility is exactly what makes the technology powerful. It is also what makes it difficult to trust.
Kepler describes building a model that achieved roughly 94% accuracy at extracting financial information. That sounds excellent in a benchmark. It becomes much less impressive when the wrong 6% may flow into a valuation, investment decision, regulatory filing, or risk calculation. The problem is not solved by asking another model to check the first model.
A probabilistic system validating another probabilistic system can improve confidence. It does not create determinism. Enterprise systems already understand this distinction elsewhere.
Software engineers write code, but they do not simply declare it correct. Compilers, unit tests, integration tests, CI pipelines, policy checks, code review, and production monitoring surround the developer. Pilots have copilots. Physicians write prescriptions that pharmacists verify. Financial institutions reconcile transactions rather than assuming every upstream system behaved correctly.
The deeper issue may be that we initially deployed AI without building the equivalent control plane around it. We treated intelligence as the product. Increasingly, intelligence looks like only one component.
The Model Should Decide What to Do, Not Necessarily Do It
One of the strongest ideas in Kepler’s architecture is the separation between reasoning and execution.The model can decide what calculation is required. It does not have to perform the calculation.
If a system needs net margin, the LLM can determine that it needs revenue and net income. But a deterministic parser can retrieve those values. A database can persist them. Conventional code can calculate the ratio. A validation layer can verify that the inputs came from approved sources.
The model orchestrates the process rather than impersonating the entire computer. That sounds obvious when stated plainly, yet much of the current AI stack still does the opposite. We routinely ask a multi-billion-parameter model to perform operations that traditional software can execute exactly, cheaply, and repeatably.
The incentives partly explain why. The first phase of enterprise AI rewarded usage. More employees using copilots looked like adoption. More tokens looked like engagement. Larger models looked like greater capability. But once CFOs and infrastructure teams start measuring the economics of these systems, token consumption becomes a cost center rather than a success metric.
The architecture changes accordingly. Use intelligence where intelligence is necessary. Use software everywhere else.
From Citations to Provenance
Citation systems were an important step toward trustworthy AI. They tell the user where an answer supposedly came from. But a citation answers only one question: what document contributed to this output?
It does not necessarily tell us how a specific data point was extracted, whether that extraction was correct, what transformations were performed, or which assumptions were applied. Kepler’s model uses what it calls atomic provenance.
Instead of allowing the model to freely read, transform, and reproduce numerical information, the model references the location of the information. Deterministic systems then handle the retrieval and persistence of the actual value. If the system cannot independently verify the number, the value does not propagate downstream.
That is a meaningful architectural change. The model stops being the database. It stops being the calculator. It stops being the source of truth. It becomes an intelligent participant operating against systems that maintain the truth. The same pattern can extend well beyond financial data.
A legal system could maintain deterministic references to cases and statutes rather than allowing a model to invent citations. A healthcare system could maintain structured references to clinical observations, medications, or research data.
An engineering system could require every generated configuration change to trace back to a specification, repository state, policy, and validation result. What matters operationally is not merely whether the model generated the right answer. It is whether the system can reconstruct why that answer exists.
Derivation Chains May Become More Valuable Than Outputs
Some enterprise work has no single ground truth.
Two analysts can start with the same financial statements and calculate enterprise value differently. Two engineering organizations can interpret the same reliability requirement differently. Two companies can apply different risk thresholds to the same underlying event.
In these cases, verification does not mean proving that one universal answer is correct. It means proving that the output followed the organization’s rules. Kepler calls this a derivation chain: a replayable sequence showing which inputs were used, which transformations occurred, and which rules produced the final result.
That concept may become foundational for enterprise agents. The valuable artifact is no longer just:
Answer: 17.4%
It becomes:
Source → extraction → transformation → organizational rule → calculation → validation → output
Now the output can be audited. More importantly, it can be reproduced. This is where AI begins to look less like software assistance and more like an operational system. The enterprise does not have to trust the agent’s internal reasoning. It has to trust the rails the agent runs on.
The Labor Impact Is More Specific Than “AI Replaces Knowledge Workers”
This architecture also produces a more useful way to think about labor.
In the presentation, Kepler describes customers wanting an AI analyst rather than an AI portfolio manager. That distinction matters. The immediate opportunity is not necessarily replacing the person making the highest-value judgment. It is removing the mechanical work surrounding that judgment.
Opening fifteen filings.
Extracting numbers.
Building the first version of a model.
Listening through earnings calls.
Reconciling data.
Preparing repetitive work product.
These tasks exist across nearly every knowledge-work organization. The infrastructure layer is becoming capable of absorbing more of them because AI can handle the ambiguous parts while deterministic software handles the parts that cannot be wrong.
That combination is materially different from the chatbot model. The likely unit of automation becomes the workflow rather than the worker. And that means organizational impact will depend heavily on how much of each workflow can be decomposed into reasoning, deterministic execution, and validation.
The Real Moat May Move Outside the Model
There is a larger strategic implication. If capable models continue becoming more interchangeable, the defensible part of enterprise AI moves outward.
The model may matter less than:
which sources the organization trusts;
what rules it applies;
what calculations it considers authoritative;
what risk thresholds it enforces;
how provenance is stored;
what actions agents are permitted to take;
how outputs are independently verified;
and whether every critical decision can be replayed.
Those systems encode institutional knowledge. A model provider can sell intelligence.
It cannot easily reproduce the accumulated operating logic of a bank, manufacturer, insurer, logistics company, healthcare system, or software organization. This suggests that the enterprise AI platform of the future may look less like a collection of prompts and more like a policy-controlled execution environment. Models will be replaceable components inside it.
The durable asset will be the deterministic substrate surrounding them.
Implications
The first implication is architectural.
Enterprises should stop treating the LLM as the whole system. Models should reason and plan, while databases, code, workflow engines, parsers, APIs, and policy systems execute deterministic operations.
The second implication is economic.
The token-maxing phase of AI adoption will eventually collide with infrastructure economics. Once organizations measure AI in cost per completed business process rather than tokens consumed, routing simple work away from large models becomes an obvious optimization.
The third implication is organizational.
Verification, provenance, and workflow design will become increasingly important engineering disciplines. AI teams may find themselves working much more closely with platform engineering, data governance, security, risk, and operations than with traditional application development alone.
And the fourth implication is strategic.
Better models will continue to matter. But model quality may cease to be the dominant differentiator for many enterprise applications.
The question shifts from:
How intelligent is the model?
to:
How much authority can the system safely give it?
Conclusion
The first generation of enterprise AI asked models to produce useful answers. The next generation will build systems capable of deciding when those answers deserve to exist.
That requires a different mental model.
The LLM does not need to be a perfect accountant, programmer, lawyer, analyst, or operator. It needs to understand enough to decide what should happen next. The surrounding system can retrieve the facts, execute the calculation, enforce the policy, record the provenance, and verify the result. That may sound like limiting AI. It is probably what allows AI to do much more consequential work.
The model doesn’t need to be right every time. The system around it does.