Vinoo Ganesh

Vinoo Ganesh is the CEO and co-founder of Kepler, an AI platform for financial services built around tracing answers to their source filing, page, and line item. With co-founder John McRaven, he advocates separating AI’s interpretation of a question from the code that retrieves facts and computes numbers. His work also centers on forward deployed engineering: organizing customer-facing engineers so that what they learn changes the shared product.[2][3][5]

In their January 30, 2026 Kepler launch essay, Ganesh and McRaven describe a deliberate division of labor: AI interprets intent, while deterministic code retrieves data and performs calculations. Their formulation is: “The AI interprets. Code executes. They never cross lanes.” The design aims to make figures traceable and answers reproducible by keeping numerical execution outside the model’s generated output.[3]

Ganesh’s model-selection judgment emphasizes maintaining constraints and surfacing ambiguity. In Anthropic’s account of Kepler, published April 30, 2026, he says Claude consistently maintained long, interdependent plans on the company’s workloads. He particularly values asking an analyst to resolve a term with multiple meanings instead of silently choosing one: “One wrong assumption early in a financial analysis breaks everything downstream.” These are his assessments of Kepler’s workloads.[4]

The team’s implementation gives that reasoning a defined financial context. Anthropic describes an ontology mapping financial concepts to definitions and formulas, deterministic execution environments for calculations and fiscal-period resolution, and access restrictions enforced throughout the pipeline. An inventory-days-outstanding question, for example, requires identifying the formula, the relevant quarters, and any restatements. McRaven explains the system boundary: the model is one stage in a pipeline, supplied with the information it needs for that stage.[4]

According to the same account, Kepler tests prompt changes, model upgrades, and context modifications against thousands of cases before production. Evaluations check both structured plans and computed results against known-correct answers, helping distinguish reasoning failures from context or execution failures. Analysts can trace figures in their Excel output to highlighted source line items. Together, these practices make verification part of the workflow rather than leaving it to the plausibility of an answer.[4]

At Kepler, the forward deployed engineering function sits inside product rather than sales. In his September 12, 2026 essay on the role, Ganesh says the team established that structure from the beginning. He argues that an FDE should solve customer problems to discover what the platform needs to support, then bring that insight back into capabilities available to future customers. A successful local fix alone does not meet his definition of the role.[5]

Ganesh advises FDEs to learn a business’s “nouns and verbs”: the objects people work with and the operations that move them. Two funds can use the same name for a return calculation while disagreeing about its denominator. For Kepler, he argues, provenance should expose those differences and reveal where the platform cannot yet express a customer’s operating model. He locates the durable advantage in accumulated, current, verified understanding, writing: “The draft is not the asset. Knowing which parts of it are wrong is the asset, and that only comes from having been corrected.”[5]

Ganesh grounds this view in earlier work at Palantir, where he began in product development before taking on customer deployments and leading Project Frontline, a rotation that trained software engineers as forward deployed engineers. He reports that around 250 people went through the program.[5]

In 2013, Ganesh worked on Palantir’s Phoenix transaction store. He recalls a bank deployment where a missing timestamp defaulted to January 1, 1970, causing retention logic to request ten-minute buckets across decades and exhaust memory. The system had behaved as specified in controlled environments; production data exposed a gap those tests had missed. Ganesh subsequently traveled to repair deployments and worked directly with Palantir’s FDEs. In his account, their later use of Phoenix for cybersecurity, know-your-customer, and anti-money-laundering work created new demands on the shared platform.[5]

Another recollection concerns an unnamed startup where a customer resisted migrating from CSV to Parquet. An FDE observed that the customer’s data-quality engineer downloaded CSV files to a Windows laptop and visually inspected their rows; the migration would remove her inspection tool. Ganesh’s team built a Parquet viewer, and he reports that the customer approved the migration two days later, with that pipeline’s runtime falling from about seventeen hours to two. The decisive discovery came from observing her work.[5]

Ganesh also recounts writing a temporary Groovy data-retention script that became a lasting customer dependency. The team maintained it for years without incorporating the fix into the product. He uses the episode to explain why field engineers must decide which fixes belong in the platform and which temporary solutions should be retired.[5]

His other historical responsibilities include Palantir’s search and indexing backend and Spark/YARN compute platform, the CTO role at geospatial data startup Veraset, and Head of Business Engineering for Ashler at Citadel. At Citadel, his team built data and software products for portfolio managers. Ganesh also teaches data engineering, dbt, AI engineering, and forward deployed engineering on LinkedIn Learning.[2][5]