Kepler CEO: Why Bigger Models Aren't the Answer to Trustworthy AI

In an era of relentless AI breakthroughs, a core tension is emerging: the more powerful models become, the less people dare to trust them in critical scenarios. Kepler CEO Vinoo Ganesh sat down with The Daily Context ahead of the AIE New York conference to share his thoughts on trustworthy AI systems—and why he believes "bigger models" simply can't solve the problem.

From Palantir to Kepler: A Bunch of "Accuracy Fanatics"

Vinoo Ganesh's career trajectory is rather unusual. He spent seven years at Palantir, leading Spark and compute-side operations, then founded an alternative data company and successfully sold it, followed by a stint at Citadel as head of business engineering, building software and data products for portfolio managers. Now at the helm of Kepler, his team is practically a "Palantir alumni association"—Sarah was one of the engineering leads for Palantir Ontology, Chris spent 15 years at Palantir focused on optimization problems, plus members from Meta, Goldman, Reflection AI, and others.

What's the common trait of this team? Ganesh's answer is clear: they've all built products in environments where information accuracy was paramount. This background determined that Kepler chose a different path from mainstream AI startups from day one—not chasing bigger models, but building infrastructure that makes AI truly trustworthy.

Three Reasons That Attract Talent

Poaching from companies like Palantir and Citadel isn't easy. Ganesh admits that Kepler's ability to attract top engineers comes down to three things: the technical depth of the problem (in a world full of "ChatGPT wrappers," genuinely deep technical challenges are highly appealing to engineers), the significance of the problem to humanity ("trustworthy AI" is one of the last milestones that can generate alpha), and the compounding effect of talent itself.

How Kepler Makes AI "Not Write Numbers"

Kepler's most striking technical promise is: the model never writes numbers. This sounds like marketing speak, but the engineering behind it is quite solid.

Preprocessing and the Provenance Ledger

Kepler's approach differs from "real-time citation verification." According to Ganesh, the platform runs large-scale preprocessing steps to extract "facts"—including numbers, entities, people, places, etc.—and annotates each fact with metadata (relationships, magnitude, units, etc.). This data is persisted through provenance records, and the platform and Agent are architected to continuously write to a provenance ledger that records every judgment and deterministic change made by the LLM. If two numbers are added or multiplied, the system persists the output and shows the complete transformation chain the numbers went through.

In other words, Kepler is more like a database than a vertical application.

Provenance Ledger is a core concept in data engineering and compliance, referring to tamper-proof records of data from creation through flow to final use. In traditional data governance, it's used to meet audit and regulatory requirements (such as SEC/FINRA compliance in finance); in the LLM context, it's been given a new mission—recording the input sources, transformation logic, and output results of every model judgment. Kepler's design of the ledger as a continuously-written architecture means that the final presentation of any number can be traced back to the original fact and all intermediate computation steps. Unlike blockchain's immutability, this is closer to a database's WAL (Write-Ahead Log) plus version control. The core value is: when regulators or users question a number, the system can immediately provide a complete chain of evidence rather than relying on the model's "self-explanation."

MCP's Security Isolation in Claude

Kepler has a connector (MCP) in Claude, which Anthropic proactively requested. But there's a natural contradiction here: if running through MCP, the model could still hallucinate or pull the wrong numbers.

Ganesh's explanation: Kepler appears as an application within Claude, and what users see is the rendered application interface, not Claude's text output. This rendered application has full auditability and traceability. All Claude does is output a code block or visualization blob—essentially similar to an API call. By assigning identifiers to facts during preprocessing, the model can only retrieve these facts through deterministic tools—like a getter and setter mechanism. If the model can't match its output to a lookup table, that fact won't appear in the output.

When conflicting information arises—say, a number mentioned on an earnings call doesn't match the 10-K filing—the model doesn't arbitrarily choose, but presents the conflict itself to the user. Ganesh points out that this conflict is sometimes alpha itself.

MCP (Model Context Protocol) is an open protocol launched by Anthropic in late 2024, designed to standardize how LLMs connect with external tools and data sources. It allows models to invoke external capabilities (such as database queries, API calls) in a client-server mode while keeping the model itself isolated from sensitive data. In Kepler's integration, MCP serves as the invocation channel for "deterministic tools": the model doesn't directly generate numbers, but triggers Kepler's getter/setter interfaces through MCP, with the backend completing fact retrieval and returning the rendered application view. The key to this design is the permission boundary—the model can only request, not modify or fabricate data. Compared to traditional Function Calling, MCP provides clearer tool descriptions and session context management, making audit trails more complete, but it also requires developers to strictly define each tool's capability scope to prevent the model from exceeding its authority.

Three Sharp Judgments on the AI Industry

A Probabilistic Machine Will Always Be a Probabilistic Machine

Ganesh is fundamentally skeptical of the "use more tokens to eliminate hallucinations" approach. His exact words: "A probabilistic machine will always be a probabilistic machine, even if the hallucination rate drops to 0.0001%." He used a vivid analogy: driving a Hummer to the grocery store doesn't get you there any better—bigger models don't produce better output.

LLM Hallucination stems from its autoregressive generation mechanism: the model samples token by token based on probability distributions, aiming to generate the "most likely" text rather than the "most true" facts. Even if training data is completely accurate, the model can still produce errors during inference due to sampling randomness, context bias, or missing long-tail knowledge. The industry has tried to reduce hallucination rates through RLHF, Retrieval-Augmented Generation (RAG), Chain-of-Thought (CoT), and other methods, but cannot bring it to zero. Ganesh's "probabilistic machine" argument is based on this mathematical essence: as long as output is a sampling result, there's a non-zero probability of error. Therefore, Kepler chose to completely separate "fact generation" from "language generation"—letting the model only handle calling deterministic tools and orchestrating workflows, while numbers and facts are provided and verified by external databases. This architecture essentially downgrades the LLM from "knowledge source" to "reasoning engine," thereby bypassing the inherent flaws of probabilistic models.

Data Security Is Severely Overlooked

Ganesh, with his Palantir background, is shocked by how current enterprises send sensitive data to large model labs. He mentioned a major financial institution saying "we signed an agreement, so we can send all customer data to the lab," which he finds "simply unbelievable." His advice is direct: your data is your alpha, and you should deploy models in your own VPC and orchestrate Agents on your own platform.

The Competitive Landscape Has Yet to Take Shape

Ganesh believes it's hard to define competitors for Kepler at this stage, because not many teams in the market are building "harnesses" this way. He prefers to position Kepler as an execution engine rather than a vertical SaaS company.

The Huge Opportunity in "Non-Vibes" Industries

Kepler started with finance, but its technical architecture applies to any regulated industry where accuracy is critical. Ganesh half-jokingly calls them "non-vibes industries": insurance claims, manufacturing, legal (case precedents have natural structure and temporality), defense, FoF, etc.

He positions Kepler as an engine, not SaaS for a specific vertical. He's already seeing pull demand from multiple industries.

Advice for the Next Generation of Engineers

For young people learning engineering and AI engineering, Ganesh's advice is to break out of the fear narrative. He believes AI is just another disruptive technological transformation—the Industrial Revolution and the Internet era didn't end the world. Today's college students have a unique opportunity: to rebuild how the world works through these new technologies. He's curious what an "AI version of McKinsey" and an "AI version of Lazard" would look like.

His personal source of excitement is healthcare—if the accuracy problem can be solved, issues like incorrect prescriptions (such as a patient taking 10x the dose due to a doctor's illegible handwriting) could be systematically eliminated.

One-line Summary

Kepler CEO Vinoo Ganesh believes bigger models can't solve hallucinations, and trustworthy AI requires fact preprocessing and a provenance ledger so models never directly generate numbers.

Paragraph Summary

In an interview, Kepler CEO Vinoo Ganesh argues that the more powerful AI becomes, the scarcer trust is in critical scenarios. He leads a team of Palantir alumni who built trustworthy AI infrastructure centered on "models never write numbers": extracting facts through large-scale preprocessing, annotating metadata, and using a provenance ledger to record every number's transformation chain. In Claude's MCP integration, Kepler outputs as a rendered application, with the model acting merely as an API call, making all numbers auditable and traceable. Ganesh criticizes the "use more tokens to eliminate hallucinations" approach, arguing that a probabilistic machine will always be a probabilistic machine and bigger models don't equal better output. He advises enterprises to deploy models in their own VPC and positions Kepler as a cross-industry execution engine targeting insurance, legal, manufacturing, defense, and other "non-vibes" industries.