DEV Community

Kara Silverman for Daily Context

Posted on with Vinoo Ganesh

Kepler's Vinoo Ganesh on Building AI You Can Trust

AI Engineer Conference Coverage

Vinoo Ganesh is the CEO of Kepler, which builds AI for industries where accuracy matters, starting with finance. Before Kepler, he spent seven years at Palantir, built and sold an alt data company, and led business engineering at Citadel.

Ahead of his AIE New York sessions, including a fireside chat with Jack Woodroffe on Tuesday at 2:55 PM, he sat down with The Daily Context to talk about building AI people can trust, why Kepler's model never writes a number, and why he doesn't believe a bigger model is the answer.

This interview has been edited for length and clarity.

The team, the talk, and New York

The Daily Context: Tell us a little about your background and about Kepler.

Vinoo Ganesh: I'm Vinoo, Kepler's CEO. I spent seven years at Palantir leading Spark and the compute side there. Then I built an alt data company, grew it, and it got acquired. After that, I was Head of Business Engineering at Citadel and really focused on how we build software products and data products for portfolio managers, which, ironically, is very similar to what Kepler is doing now.

It's a heavy ex-Palantir team. Sarah was one of the engineering leads for the Palantir Ontology. Chris was at Palantir for 15 years, doing a lot of optimization. We have folks from Meta, Reflection AI, Datavant, Goldman, Oddity, you name it. So, it's a team that has spent a lot of time building products in environments where the accuracy and fidelity of information and data matter.

The Daily Context: That's an incredible pedigree, but it's also hard to convince people to walk away from those companies. How do you approach recruiting?

Vinoo Ganesh: We've been very lucky in that there are people who trust us, who've worked with us before, and who feel very positive about joining us again. But honestly, I make Eddie's job very hard at times, because I'm always saying, "Let's recruit these insanely talented people."

Ultimately, it comes down to a few things. First, the problems we solve are super technically deep. In a world where there are things that look like ChatGPT wrappers, a very deep set of technical problems is super appealing to engineers who are motivated by that.

Second, we're really lucky that our problem space has a huge element of importance to humanity. Yes, we started in finance, but AI you can trust, or enterprise intelligence you can codify, is kind of the last remaining alpha-generating milestone. Kepler is really powerful in that sense: if everyone has the same access to the same tools, what alpha or uniqueness remains? It turns out that's an existential question for a lot of folks.

Third, talent compounds. We have a really strong pedigree team, and people like working with very strong engineers. We have an insanely high bar for talent; you can ask Adil about that. We try to be very fair in our interview process, but we do have people who are intimidated by the backgrounds. We've gotten that feedback: "Do I want to work for an ex-Palantir, ex-Citadel team? Sounds scary." I think we're approachable and reasonable.

The Daily Context: What is your personal relationship to AI?

Vinoo Ganesh: I think "cautious consumers" is probably the best way to describe us. AI is really helpful for vast synthesis of information, especially in non-deterministic ways. If I have a bunch of queries I just want to understand at a high level, or get a vibe for, AI has been very powerful for that.

The challenges come in when people use AI in ways it shouldn't be used, like deterministic work, or work where accuracy is materially important. AI is very positive in a number of ways, but it also agrees with the vast majority of things you say. It doesn't follow steps, even when you ask it to. And it's a moving target. When models are being released at a pace of roughly one a day, keeping up with that rapidly changing environment is super hard. So it's a powerful tool and accelerant when it's deployed in the right way.

The Daily Context: What is your AIE New York talk about?

Vinoo Ganesh: We see the promise of AI so clearly because we're deep in it every day. The simple reality, though, is that deep exposure to and deployment of AI is still in its infancy at most companies. Even the ones that think of themselves as super AI-forward are normally just throwing Copilot on a few queries, and that's it.

Our question is always: why? What's the blocker to getting to the level that we, our team, and our peers use AI at? It comes back to the question of trust. So the talk is about how you build trust in an AI system, and our view on it: to really trust an AI system, you can't just use AI by itself. You need infrastructure around it. That infrastructure uses AI for the right scenarios, uses other tools for the right scenarios, shows proof, and, finally, is deeply embedded in the systems you already work in. How we go from early adopters to people using it in depth, every day, in 95% of cases, is the exciting space we'll talk about and that we're working on in detail.

The Daily Context: Why New York over San Francisco?

Vinoo Ganesh: As a forward-deployed engineer, I've learned that being close to your customers, geographically and emotionally, matters a lot. Our initial customers happen to be based here in New York. Finance is predominantly here, but I also think the urgency and importance of this problem space are uniquely captured in New York, where the speed of development, the speed of technology adoption, being first, and being smarter all matter a lot. SF is really powerful in a number of ways, more on the research side, but at Kepler we're very focused on the applied side, even though we do a good chunk of research ourselves.

How Kepler works

The Daily Context: My research suggested Kepler checks citations against sources in real time, while the output is streaming. How does that work?

Vinoo Ganesh: We actually don't do it while streaming or in real time. The way we operate is that there are certain things deterministic tools will always be better at. So we run massive preprocessing steps that extract what we call facts. Those can be numbers, entities, people, places, and things. We annotate those facts with metadata that describes each unique fact. That can be relationships, or, for a number, it can be magnitude, scale, whether it's dollars or pounds, and so on.

The second piece is that we persist all of this data with provenance records. As data flows through the Kepler platform, the platform and agents are architected so they're consistently writing to a provenance ledger that, at any given moment, holds effectively every previous step taken. So we can see every twist, every turn, every determination an LLM makes, and we can even see deterministic changes. If two numbers get added together, we persist that output. If two numbers are multiplied, we persist that product. And we can show you the chain of transformations the number went through.

So a lot of it comes down to very detailed preprocessing and very detailed engineering up front, which then compounds because we can switch between the deterministic and non-deterministic pieces.

The Daily Context: Walk me through Kepler's first public equities ontology. Why was it important to build?

Vinoo Ganesh: Great question. Humans don't think in terms of rows and columns in a database. If you think about your Facebook friends, you probably think in terms of relationships: I am this person's friend; I believe this person is this many years old. We think in these complex, relationship-driven ways.

What's interesting for us, especially in the finance ecosystem, is that being able to codify and entity-resolve even something as simple as company names is a really hard problem. For example, Palantir and PLTR obviously refer to the same thing, but most systems can't easily entity-resolve them. That problem compounds when it's a person saying something. If I'm the CFO of a company and I mention Palantir, and it's transcribed incorrectly, how do I do any kind of canonicalization or entity resolution?

What we realized is that LLMs are really good at thinking through how to solve things, but they're not necessarily as good at doing the solving themselves. Developing the ontology allowed us to do a few things. First, it let us give LLMs tooling to interact with that ontology, so the LLM can do what it does best and the tools can do what they do best.

It also lets us be very mindful from a cost perspective. We're in an era post token-maxing, where using as many tokens as possible is no longer the cool new thing to do. Getting the best ROI out of each dollar you spend on tokens becomes really important. Kepler is predicated on using the right tool for the job, and sometimes a deterministic system, like knowledge graph traversal over an ontology, is a much better solution than a potentially multi-trillion-parameter model trying to do anything and everything. So the ontology lets us represent the preprocessed data in a way that both LLMs and Kepler's own execution engine can traverse pretty easily.

The Daily Context: The applications to finance are super clear. What other industries are a good fit for Kepler?

Vinoo Ganesh: Any industry that's regulated, where material accuracy matters. I've jokingly called these the "non-vibes industries." Think of something like insurance claims adjustment. Insurance is a very interesting potential area of expansion for us. Manufacturing, too. Even legal. Legal is interesting because if you think about the data, like case briefs, there's an inherent structure to it. There's precedent; there are cases like A v. B; and there's a time-based nature to it: this happened before that, so this precedent overrides that one.

So any industry where the accuracy of data matters is a potential opportunity for Kepler. That's why we've positioned Kepler as more of an engine than a particular vertical SaaS play. We now have pull across a bunch of different industries. Defense has been an interesting, more recent area, and fund of funds as well. Any of those spaces.

The Daily Context: Part of Kepler's promise is that the model never writes a number. How does that work? And Kepler has a connector inside Claude. How do you make sure that promise holds when Claude is delivering the last mile?

Vinoo Ganesh: This is probably the best question I have ever gotten, because we are desperate to talk about it, and no one lets us.

A couple of things. Kepler having an MCP was actually a request from Anthropic themselves. It wasn't a deliberate strategic positioning for what Kepler wants to be, because you're right: if Kepler runs through an MCP, the model can still hallucinate. It can pull the wrong number, and a bunch of other things.

Here's how we solve that problem. Kepler in Claude ships with apps, so what you're seeing is a rendered application, not Claude giving you text-based output. That rendered application has full auditability and traceability. We're passing what is effectively a blob of code or a blob of visualization back to Claude, and all Claude does is output it. It's almost like an API call, and the apps feature in Claude renders the Kepler UI. That's what makes every number auditable and traceable.

How do we ensure the model doesn't produce numbers? It's because of the invariant we've built into the platform. By preprocessing data and information, we assign identifiers to facts. What the model knows how to do is use deterministic tools that retrieve those facts. Think of it almost like a getter or a setter: I can do a lookup from a table, and the model substitutes that lookup in.

Right now in finance, the facts we care about are things like company names and numbers. But in law, we could enforce that same idea for court cases, to make sure each case actually exists before the model can return it. So right now, if the model can't resolve its output against the lookup, it rejects it. It can't actually state that fact.

The Daily Context: What does it say when that happens?

Vinoo Ganesh: It isn't included in the output at all. In practice, it looks like facts disagreeing. Say someone from Google said on an earnings call that Google's earnings were $1 last year, and the 10-K reports $100. Those are conflicting facts. Rather than trying to pick one, the model realizes that, upon resolution, it can't identify that number appropriately. So it has to present it to the user and say it's getting conflicting information.

Sometimes that's alpha, and it's right. If someone is saying something different, you could have new sources of information, and that could be alpha in its own right. Sometimes it's actually a mistake.

The state of the industry

The Daily Context: What else do you not get asked about that you really want to talk about?

Vinoo Ganesh: I have one that's more of a comment on the state of the industry. In tech as a whole, there are a lot of waves, and we've seen the first wave of companies raising a lot of capital very quickly. They're in the land grab right now. We're very much in the early innings.

A lot of people ask me who Kepler's competition is, and it's a somewhat challenging question to answer, because, at least to my knowledge, there isn't a set of people out there trying to build this harness or this product in this way. So our competition looks a lot like vertical SaaS companies that have to build the airplane while it's in flight. More importantly, we're still early enough that this is a thesis: here's how we would solve this problem in the data.

I think we'll see a lot of other approaches. There are labs trying to remove hallucination by throwing as many tokens at it as they possibly can. I inherently think that doesn't make sense. A probability machine will continue to be a probability machine, even if the hallucination rate is 0.0001%. Ultimately, we're an execution engine. We look more like a database than a vertical app company.

Other questions are around where we are in this AI cycle, and the desire to use LLMs for everything. I don't think a bigger, badder, more powerful model will result in better output, any more than driving a Hummer from your home to the grocery store gets you to the grocery store in a better way. It doesn't make sense to me.

The last thing people don't seem to care about as much is that a lot of people are very okay sending private information to the labs. That's the weirdest thing to me, because coming from Palantir, data security was the most important thing. I've had meetings with major financial institutions that said, "Well, we signed an agreement, so we're just going to send all the customer data out to the labs," which is mind-blowing to me.

So there's a big question around what the future looks like when everyone is using this technology, and when alpha is much harder to come by. Those are open questions right now. That's exactly what I want Jack and others to talk about, and that's where I think the opportunity really is.

The Daily Context: What do you recommend for companies that want to apply AI to sensitive data?

Vinoo Ganesh: Ultimately, the question is how you maintain your edge. That's the most important thing. My frustration is that a lot of these organizations are digging their own grave, and I don't understand why that's the path they want to go down. Your own data is your alpha.

The Daily Context: More tactically, is there a way for a financial company working with inherently sensitive data to use AI without sending that data to the labs?

Vinoo Ganesh: I would deploy on-prem. The crazy thing is that deploying a model seems like the most insane thing in the world. But you spend two seconds thinking about it and realize you can pretty easily run the model in your VPC and do any kind of editing of these agents on your own platform. It sounds really scary until you do it, and then you realize it's not insane in any way.

The Daily Context: If you were advising a 20- or 21-year-old recent college grad looking at engineering and AI engineering, what would you tell them?

Vinoo Ganesh: In any major technical shift, there's one big driving question. Here, it's whether AI is just another disruptive technology — not the harbinger of the end of the world, just another disruptive technology we all learn to live with. I think that framing makes people feel a lot less scared.

The Industrial Revolution was a huge technological shift. The dot-com era was a huge technological shift. There were a bunch of these material changes, and none of them ended the world. What I did was figure out how to adapt to the new way of doing things and the new set of processes.

My belief is that people in college right now have a very unique opportunity to rebuild the world through the lens of these new technologies. I wonder what the AI version of McKinsey will be. What's the AI version of Lazard? I'm not saying those companies will be gone. It's more that there's a huge opportunity to get very familiar with using a technology to fundamentally rewrite how industry works.

Personally, I'm really excited about medical use cases, if we can solve the accuracy problem. That, to me, is a huge opportunity. How many prescriptions are filled incorrectly because someone can't read a doctor's handwriting, and a patient gets 10x the dosage they should have? Those are all huge opportunities, and I think the next generation has a unique ability to build these future technologies.

Top comments (0)