# Kepler

> Enterprise intelligence for high-stakes industries, starting with investment firms. AI that knows your firm's data and cites every number.

Kepler (kepler.ai) is based in New York and was founded in 2025 by engineers from Palantir. Kepler for Finance is live with investment teams, and Kepler also works with firms in law and manufacturing.

## Why Kepler exists

There is a trust gap in enterprise AI. Frontier models keep getting smarter, but they are probabilistic: they can hallucinate, and you can't tell when. They also don't know a firm's data structure, definitions, or relationships. When one wrong number can cost millions, that means checking everything by hand.

Kepler splits the work. The model does what it is good at: understanding the question and writing the answer. Code extracts and computes every fact and figure, with a citation path back to the source. Kepler's engineers deploy deep into each firm: they pre-process the firm's whole data corpus, build an ontology on top, and run the platform on that. The team built this kind of data layer before at Palantir.

## How Kepler works

The Kepler stack, from the source documents up to the screen:

- **Primary sources:** Every source is captured whole: SEC filings with their full text and XBRL, earnings call transcripts, investor presentations, market data, and the firm's own documents.
- **Ontology:** Kepler builds an ontology from each firm's own data, so every company, fund, person, and document resolves to one record, with the firm's definitions written once in code and a source behind every relationship. The ontology drafts itself from the firm's documents for engineers to review, keeps itself current as new documents arrive, and corrects itself: agents re-check every edge as new documents arrive, propose new types when documents describe something new, and turn each correction into a rule applied everywhere the same mistake appears. Each relationship is a claim carrying its verbatim sentence, how it is known (stated, inferred, or derived), how many sources back it, whether they agree, and two clocks (when it was true and when it was recorded), so the graph can be queried as of any date. It starts from the first public equities ontology, built claim by claim from SEC filings, earnings calls, and regulatory dockets. [More on the ontology](https://kepler.ai/ontology/)
- **Deterministic engine:** Financial statements are assembled from the filings' own XBRL with no model in the path. Every calculation runs as code over cited inputs, and its citation carries the formula.
- **Citations:** Every number is written with its source attached and checked against that source while the answer streams. A citation that doesn't match is removed before anyone sees it.
- **Agent runtime:** Every request starts with a plan. Agents run as state machines with tools gated at each step, and specialist agents read filings, transcripts, exhibits, and decks in parallel.
- **Skills and rules:** Built-in skills encode how finance work is done (adjusted EBITDA, enterprise value, fully diluted shares). A firm can write its own skills, which are compiled and reviewed before they apply.
- **Surfaces:** The Kepler app (chat, workbooks, and a citation sidebar), Excel and PowerPoint, a verified connector for Claude, and the Kepler MCP and API for a firm's own agents and systems.
- **Security and tenancy:** Each firm's work is scoped to its organization, customer data and market data live in separate stores, and agent execution runs on a private network.

## Products

- [The Kepler Platform](https://kepler.ai/platform/): The technical stack in ten layers (connect, read, resolve, retrieve, compute, cite, orchestrate, route, learn, deliver) wrapped by governance: models Kepler trains read every document once, an ontology of sourced claims, and code that computes and cites every number, with one question traced through every layer.
- [Kepler for Finance](https://kepler.ai/finance/): For investment teams at hedge funds, asset managers, private equity and private credit firms, investment banks, and equity research. Answers, models, and memos across filings, transcripts, market data, and the firm's own documents, with every figure cited to its source. Coverage: 26M+ SEC filings, 40M+ investor relations documents, and earnings call transcripts for 14,000+ companies, across 120+ countries and 30+ languages.
- [Kepler for Industry](https://kepler.ai/industry/): The same platform on a firm's own systems in law, manufacturing, and other high-stakes work, with every answer cited to the record it came from.
- [Build on Kepler](https://kepler.ai/build/): The Kepler API, on which a firm's own agents, apps and workflows run on the same data, ontology and engine as the Kepler app, with each figure returned with its value, formula and source; and the Kepler MCP, a verified connector in Claude that also works with any MCP client (Claude reasons; Kepler does retrieval and arithmetic on primary sources, and every figure links to its filing; [setup guide](https://kepler.ai/blog/2026/09/02/kepler-in-claude/)).
- [Compare](https://kepler.ai/compare/): How Kepler compares with frontier models on their own and finance AI tools. In both, the model pulls and writes each number and a citation is attached; Kepler's deterministic engine pulls and computes every number from the source with code, every document is read in full and indexed before a question, the firm's definitions live in its ontology, every figure traces to its line with the formula, citations are checked while the answer is written, conflicting sources are shown side by side and flagged, figures are available as filed or as restated on any date, and a firm's engineers can build their own agents and apps on Kepler's data, ontology and engine, where finance AI tools are sealed apps.

## Kepler for Finance: use cases

### Hedge funds: Screens and earnings updates

Screen thousands of companies on metrics and disclosures, and update the model the hour results land. Typical work: Idea screens across filings and metrics; Post-earnings model updates; Thesis tracking and alerts.

Example: "Semiconductor companies whose inventory days rose three quarters in a row"

### Private equity: Diligence and portfolio monitoring

Work through years of filings, footnotes and data-room documents to find what changed and what doesn't add up. Typical work: CIM and data-room diligence; Portfolio company monitoring; Investment committee memos.

Example: "Restatements and off-balance-sheet commitments in the last five 10-Ks"

### Equity research: Earnings models and estimates

Pull segments, margins and share counts from 10-Qs and transcripts, and see exactly what changed when a company files. Typical work: Earnings previews and post-print notes; Segment and margin build-outs; Estimate revisions with sources attached.

Example: "Update FY2026 estimates from Alphabet's latest 10-Q and earnings call"

### Investment banking: Comps, valuation and deal materials

Build comps and precedents where every multiple traces to a line item in a filing. Typical work: Trading comps and precedent transactions; Buyer lists and deal screens; Pitch book pages in your format.

Example: "Trading comps for US cybersecurity, EV/EBITDA on each filer's own adjusted EBITDA"

## Team

The team built this layer before at Palantir. Engineers also come from Citadel, Goldman Sachs, Meta, and AWS, with 50+ combined years at Palantir.

- **Vinoo Ganesh:** CEO and co-founder. 7 years at Palantir leading storage and compute platforms. Built Veraset to $15M ARR (acquired). Citadel's first Head of Business Engineering.
- **Sara Kromwijk:** Founding Engineer. 11 years at Palantir. Architected product enabling Palantir's transition from per-customer to vertical-based engagements. MSc in CS from EPFL.
- **Susannah Meyer:** Founding Engineer. Senior engineer at Meta on big data systems. Head of Engineering at Enigma Labs, scaling to 300k+ users. BS in CS from Stanford.
- **Sean Gorsky:** Founding Engineer. 7 years at MIT Lincoln Laboratory. Head of Data Science at Sync Computing (acquired by Capital One). MS in EE from BU.
- **Dr. Chris Martin:** Founding Engineer. 14 years at Palantir. Built core analytical infrastructure for classified defense and commercial programs. Shipped production AI and math optimization across manufacturing, aviation, finance, healthcare, and insurance. PhD in Aerospace Engineering from UIUC.
- **Michelle Van:** Founding Engineer. ML and data engineer at Velvet FS, previously at several tech startups. MS in Data Science from Duke, MEng from Oxford.
- **Rui Zhang:** Founding Product. 10+ years running $100M+ businesses. PE and portfolio company operations at a $12B private equity firm.
- **Eddie Hammond:** Founding Strategy and Ops. 6 years at ODDITY Tech (NASDAQ: ODD) as Sr. Director of BizOps. Led subscriptions program to global scale, launched SpoiledChild from $0 to $250M+ in 3 years. Mechanical Engineering from Penn.

## Investors

- **Keith Adams** (Pebblebed): Founder, Meta AI Research.
- **Pam Vagata** (Pebblebed): Founder, OpenAI.
- **Jordan Tigani**: Founder, MotherDuck.
- **Tristan Handy**: Founder, dbt Labs.
- **Savin Goyal**: Founder, Outerbounds.
- **Adm. William H. McRaven**: 9th Commander, USSOCOM.
- **Jim McKelvey**: Founder, Square/Block.
- **Scott Sandell**: Chairman, NEA.
- **Jack Woodruff**: Founder, Candlestick Capital.

## Security and compliance

SOC 2 Type II: Audited. GDPR: Compliant. CCPA: Compliant. ISO 27001: In progress. Trust Portal: [trust.kepler.ai](https://trust.kepler.ai/)

- **No training on your data:** Your data never trains models other firms use.
- **Strict data isolation and boundary enforcement:** Every query is scoped to your firm, isolation is enforced at the identity layer, and your search index sits in its own namespace.
- **Least-privilege access and controlled permissions:** Every user, process, and service operates with only the access required. Permissions are scoped, logged, and reviewable.
- **Full auditability of system behavior:** Every query, calculation, and data access is logged with complete lineage. Trace any output back to its source.
- **Deterministic and reproducible outputs:** Every number is computed by code, so the same inputs give the same figures, and any result can be reproduced on demand.
- **Designed to withstand scrutiny:** Built for regulated environments where auditors, compliance teams, and regulators require full transparency.

## Research

- [Anthropic S-1 Breakdown](https://kepler.ai/research/financial/s1-anthropic/) (financial research, 2026-10-26): Anthropic's S-1: $16.3B of H1 2026 revenue (up 1,300%), a Q2 operating profit, and why the $80.7B loss is mostly non-cash. Research note and Excel model.
- [Better language models won't fix hallucination. They'll make it quieter.](https://kepler.ai/research/engineering/quieter-hallucination/) (research note, 2026-09-29): Every upgrade this year made our models smarter, and after every upgrade we gave them less to do. The better they got, the harder their mistakes were to see.
- [Stop Paying to Forget](https://kepler.ai/research/engineering/stop-paying-to-forget/) (research note, 2026-09-25): Most document AI rereads the same pages for every question and keeps almost nothing from the last read. We read each document once, keep every number, name and relationship we can recover from it, and answer the next question with ordinary software.
- [Reclassified to Conform](https://kepler.ai/research/engineering/reclassified-to-conform/) (paper, arXiv 2609.38754, 2026-09-22): Financial statements change their lines from year to year. The paper uses the periods filings repeat to reconstruct those changes and build histories with a source behind every number.
- [Oura S-1 Breakdown](https://kepler.ai/research/financial/s1-oura/) (financial research, 2026-09-03): Inside Oura's S-1: revenue up 123% to $908M in FY2025, 5M paid members, positive free cash flow. Research note plus a model traced to the filing.

## Frequently asked questions

**What is Kepler?**
Kepler builds enterprise intelligence for high-stakes industries, starting with investment firms. Our engineers deploy on your firm's own data and build an ontology from it. Code pulls the data, runs the calculations and cites every number, while the model handles the question and the write-up.

**How is Kepler different from using a frontier model directly?**
A frontier model on its own reads the few passages it retrieves, writes its own numbers and doesn't know your firm's definitions. On Kepler, every document has been read in full, your definitions live in an ontology, and code pulls and computes each number. Ask the same question twice and you get the same answer, with the same sources.

**Who is Kepler built for?**
Investment firms first: hedge funds, asset managers, private equity, private credit, investment banks and equity research. The same platform runs for legal, manufacturing, insurance and healthcare teams.

**Does Kepler replace my existing tools?**
No. Kepler works on top of the data you already have, from filings and market data to your own research and systems, and its answers land in Excel, PowerPoint and Claude, and in your own systems through the Kepler MCP and API.

**What does it mean that every number is traced?**
Click any figure and you land on the exact source it came from, down to the page and line of a filing. Calculated figures show the formula and every input. Ask the same question again and you get the same answer, with the same sources.

**What is the ontology?**
The ontology is the map of your firm's world: companies, funds, people, documents, your definitions and how they all connect. It resolves every spelling of a company to one record and ships with an ontology of public companies built from SEC filings. When you ask about adjusted EBITDA or Q3, Kepler uses your firm's definition.

**Which AI model does Kepler use?**
The right one for each job. Small models we train read every document and pull out its facts, and a frontier model reads your question and writes the answer. We swap in better models as they ship. Either way, code pulls and computes the numbers, not the model.

**Can our own agents and tools use Kepler?**
Yes. Through our API and MCP, your agents and systems work from the same data, definitions and citations, and Kepler runs inside Claude as a connector. Outputs also go straight into Excel and PowerPoint.

**How does an engagement start?**
With a working session with our engineers on your workflows. Public data is ready on day one. In the first week we connect your own sources, index every document and build your firm's ontology on top.

**What data does Kepler cover?**
26M+ SEC filings, 40M+ investor relations documents and earnings call transcripts for 14,000+ companies, plus market data and news, across 120+ countries and 30+ languages. Our engineers then connect your firm's own sources, such as internal research, models, your CRM, SharePoint and drives.

**Can I use Kepler for non-US companies?**
Yes. Alongside SEC filings for US companies, Kepler covers annual reports and exchange disclosures across 120+ countries, in 30+ languages, with every figure traced to its source document.

**How does Kepler handle security?**
Kepler is SOC 2 Type II audited and GDPR and CCPA compliant. Each firm's data is isolated from every other customer's, every query and calculation is logged with its lineage, and your data never trains models other firms use. Our security documentation is at trust.kepler.ai.

**Who built Kepler?**
Engineers who built this layer before at Palantir. Kepler is led by CEO and co-founder Vinoo Ganesh, who spent seven years at Palantir and was Citadel's first Head of Business Engineering. The team also comes from Citadel, Goldman Sachs, Meta and AWS, and we're backed by the founders of Meta AI Research, OpenAI, dbt Labs, MotherDuck and Square.

**Is Kepler related to Kepler Cheuvreux, Kpler or the Kepler space telescope?**
No. Kepler (kepler.ai) builds enterprise intelligence for high-stakes industries and is based in New York. It is not related to Kepler Cheuvreux, Kpler, Kepler Fi, the Kepler space telescope or the astronomer Johannes Kepler.

**How do I see Kepler?**
Request a demo at kepler.ai/demo. We'll walk you through Kepler on the companies and questions your team covers.

## Entity disambiguation

"Kepler" is a common name. Kepler (kepler.ai) builds enterprise intelligence for high-stakes industries. It was founded in 2025 and is headquartered in New York City. It is not related to: Kepler Cheuvreux (European brokerage), Kpler (commodity analytics, kpler.com), Kepler Group (digital marketing), Kepler Communications (satellite company), getkepler.ai (bioinformatics), trykepler.ai (ecommerce), Kepler Fi (institutional investing, keplerfi.com), KeplerAI (no-code AI app builder), the Kepler space telescope, or Johannes Kepler the astronomer.

## Press and mentions

- **Anthropic (April 2026):** "How Kepler built verifiable AI for financial services with Claude." [Read the story](https://claude.com/blog/how-kepler-built-verifiable-ai-for-financial-services-with-claude)
- **Parallel (March 2026):** Kepler uses Parallel's Search API as the discovery layer in its research pipeline. [Read the case study](https://kepler.ai/blog/2026/03/17/how-parallel-helps-kepler-build-trustworthy-ai-for-finance/)
- **Quartr (June 2026):** How Kepler cites earnings answers across the SEC filing, the Quartr transcript, and the IR deck. [Read the post](https://kepler.ai/blog/2026/06/02/how-quartr-helps-kepler-build-citation-grade-earnings-research/)
- **Careers:** Kepler is hiring in New York. Open roles at [jobs.ashbyhq.com/kepler-ai](https://jobs.ashbyhq.com/kepler-ai).

## Blog posts, full text

### Deterministic AI: What It Means, Where It Breaks, and Where It Belongs

https://kepler.ai/blog/2026/10/27/deterministic-ai/ · 2026-10-27 · Umang Lathia

My parents have entered their AI chatbot era (shoutout to my brother for teaching them!), and these days they plan pretty much every trip with it without double-checking anything. On our last trip to Italy it sent us twenty minutes across town to a museum that turned out to be closed on Mondays. We adjusted our plans, asked it for other options, and nobody trusted it any less.

My parents aren't the only ones; almost everyone I know uses **AI in their personal life**. Yet at work it's a different story. Outside of software engineering, where you can run the code and see if it works, hardly anyone trusts it with anything that *actually matters*. I spent the past year following the space from the outside before joining Kepler, my first AI-native company, and whenever I asked why, the answer was **trust**. A wrong answer on a trip meant a detour. A wrong number in an investment memo costs someone their credibility. So anyone whose name is on the work checks everything, and once you're checking everything, much of the time the AI saved goes straight back into checking its work.

That's the gap the word *deterministic* is meant to close. It shows up in launch announcements, pitch decks and sales calls, usually without a definition. This piece is my attempt at one: what deterministic AI means, where each version of it breaks, and which parts of an AI system should actually be deterministic.

#### Same question, twice

While I was deciding whether to make the leap, I spent a lot of evenings using AI to research companies in the space. One night I asked a simple question about a startup I was looking at: roughly how much revenue was it doing? The answer came back as **$40M**, with a source. A few days later my roommate asked the *exact same question* and got **$25M**, also with a source.

There was no glitch. The two sources disagreed: one was an older article quoting an early estimate, the other a more recent interview with a different figure. Each time, the AI found one of them, picked it, and presented it with complete confidence. It never mentioned the other.

That's the part that stuck with me. Both answers were sourced, both looked *totally fine*, and the system made a judgment call (which source to trust) without telling either of us it had made one. If my roommate hadn't asked, I'd never have known there was another number.

#### Deterministic vs probabilistic AI

A **deterministic** system gives the same output for the same input, every time. A calculator, a spreadsheet formula, a database query, these are all deterministic: ask for revenue divided by headcount and you get one answer, and you can rerun it a thousand times to prove it.

A **probabilistic** system produces outputs from a range of possibilities. Large language models work this way. At each step, a model estimates how likely every possible next word is and picks one, which is what makes them so good at reading messy questions, summarizing documents and writing fluent explanations. It's also why the same question can come back with a different answer.

Neither is better. They're built for different jobs. The real question isn't whether an AI system is deterministic or probabilistic (every useful one is both), but which job each part of it is doing.

#### Five things people mean by "deterministic"

Look closely at the claims and "deterministic AI" turns out to mean at least five different things. Each one guarantees something real, and each one breaks somewhere.

1\. **Consistent answers:** The same question returns the same answer every time, either word for word or with the same facts in different wording. It guarantees repeatability; you can rerun a question and expect the same result, which makes a system easier to test and debug. It **does not** guarantee *correctness*. A system that's wrong the same way every time is arguably worse than one that varies, because nobody thinks to check it. In my case, consistency would have hidden the disagreement between sources instead of exposing it.

2\. **Guaranteed format:** The output always comes back in the same structure, like a table with the same columns or data that other software can read without errors. It guarantees reliability for whatever sits downstream; if answers feed into a spreadsheet or another system, a predictable shape matters. It **does not** guarantee the *content* is right. The table will always have a revenue column, but whether the number in it is correct is a separate question. In my case, both answers came back in exactly the same shape: one number, one source.

3\. **Fixed workflows and rules:** Every request runs through the same steps in the same order, within a set of written rules (only use these sources, always show a citation, never answer questions about X). It guarantees a predictable process, which makes a system easier to audit and govern. It **does not** guarantee a correct *result*, because any step that relies on a model can still get it wrong, and rules only catch the mistakes someone saw coming. In my case, the same steps likely ran both times (search, find a source, pull a number, cite it) and still produced two different numbers.

4\. **Double-checked answers:** A second pass reviews the first answer before it reaches you, usually another model asked to check the first one's work. It guarantees fewer obvious mistakes, like unsupported claims, formatting slips and answers that don't match the question. It **does not** guarantee an *independent* check. When one probabilistic model checks another, the check is probabilistic too, and the two often share blind spots. In my case, a reviewer checking $40M against its article would have passed it, because the number matched. The problem was the other source it never looked at.

5\. **Traceable answers:** Every number links back to where it came from: a specific document, page or line. It guarantees accountability; you can follow any figure back to its source instead of taking the system's word for it. It **does not** guarantee the *right source*. A citation tells you where a number came from, not whether it was the right place to look, or whether another source said something different. In my case, both answers were cited and both citations checked out. They just pointed to different places.

#### Is temperature 0 deterministic?

There's one more fix people reach for first: set the temperature to zero. Temperature controls how much randomness the model uses when it picks the next word, and at zero it always picks the single most likely option.

In theory, that should make the output deterministic. In practice, it doesn't, and the major model providers don't promise identical outputs even at zero. When the AI research lab Thinking Machines [dug into why](https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/), it sent one prompt to the same model 1,000 times at temperature zero and got back 80 different answers. The main cause wasn't the model at all but the servers running it. Requests get grouped into batches that change size depending on how busy the server is, and that small change in the order of the arithmetic can be enough to flip which word comes out on top. Fixing it means changing how the model runs under the hood, and it makes everything slower.

And even a perfectly repeatable model only solves half the problem. Temperature zero could have given me $40M or $25M every time. It wouldn't have told me the sources disagreed.

#### So which parts should be deterministic?

Run my revenue question back through all five, or through temperature zero, and none of them would have fixed it on its own. That's because the problem was never that the AI was probabilistic. The problem was that the probabilistic part was doing a job that should have been deterministic: finding the numbers. A model-only system finds one number and stops.

The useful line isn't between deterministic and probabilistic AI. It's between the jobs inside an AI system:

* **Make it deterministic** wherever numbers are found and calculated: searching every source, every time, pulling each figure out, calculating with it, and linking it back to exactly where it came from. Ask about that startup's revenue and both $40M and $25M come back, every time.
* **Keep it probabilistic** where judgment and flexibility are the point: understanding a messy question, weighing sources that disagree, and explaining the result in plain language. The model can say which figure it trusts more and why, as long as both are shown.

Put simply, deterministic code should find every number, and the model should weigh them in the open. That's the line we draw at Kepler: deterministic code retrieves, calculates and cites every figure, and language models interpret the question, weigh what comes back and write the answer. Determinism isn't the goal by itself. It's how you get to answers that are **verifiable**.

#### Questions to ask about any "deterministic" AI system

Almost any vendor will say yes to "is it deterministic?" These questions get you further:

* **Which parts are deterministic, and which aren't?** Look for a specific answer about how numbers are retrieved and calculated, not a general claim about the whole system.
* **What happens when sources disagree?** The right answer is that the system shows you, not that it picks one.
* **How long does it take me to check an answer?** If verifying a number takes as long as finding it yourself, the AI hasn't saved you any time.

#### Back to my parents

My parents don't need deterministic AI, because when it gets something wrong, they just change plans. A wrong revenue number nearly fed into my career decision, and inside most companies a wrong number costs far more than that, which is why so much of the important work still gets done by hand.

The fix isn't to make AI less probabilistic. It's to put determinism where the numbers are, so that every figure can be traced, rerun and checked faster than you could have produced it yourself. That's the problem I joined Kepler to work on.

---

### The Compiler That Never Says No

https://kepler.ai/blog/2026/10/06/the-compiler-that-never-says-no/ · 2026-10-06 · Eddie Hammond

*"Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer." - Edsger Dijkstra, 1975*

Last week I read a New York Times guest essay by Joe Cruz, who chairs the philosophy department at Williams College, and it bothered me. Titled ["I'm a College Professor. Writing Isn't as Important as We Think."](https://www.nytimes.com/2026/09/29/opinion/writing-thinking-college-ai.html), it went on to argue "What if we are mistaken in treating writing as the highest cultivation of thought?" "The evidence that supports this belief is thin at best."

Cruz is asking how students learn to think, but he misses a much broader question. How do we most effectively translate thoughts into structured arguments, and ultimately use that to communicate? We work in very different fields, but I, too, spend my days wrestling with this problem. Since large language models went mainstream, people have debated about how much prompt engineering, which is mostly the art of communicating clearly, improves results. Today this question occupies a good deal of my wandering mind.

Those reflections began, as most of mine do, in a fit of mild exasperation. It had taken me five drafts to coax Claude into writing a succinct 150-word technical post.

On the surface, none of these five drafts was bad. Each was a fluent, confident answer to the request I had made. But with each new prompt, the request I gave changed, because I hadn’t decided precisely what the post was meant to communicate. As a result, the drafts did not improve in the linear fashion I had expected. At every step along the way, Claude encouraged me along, never pausing to complain that my brief was unclear. It wrote something plausible each time and waited for my next note. The drafts improved only as my own thought process iterated on the idea of the post, and could explain its goals more sharply.

Blaise Pascal described this same problem in 1656, apologizing to the reader of one of his [*Provincial Letters*](https://www.gutenberg.org/ebooks/73959): "The present letter is a very long one, simply because I had no leisure to make it shorter." Shortening takes time because it forces you to decide what matters. A model can give you unlimited drafts, but it can't make that decision for you, and my five drafts were the time it took me to make it.

Since then, I’ve paid deliberately close attention to the writing that crosses my desk, and I have come to suspect that Professor Cruz has the matter almost exactly backwards. Working with AI has made writing part of programming, and the link between fast, productive engineering work and an ability to write well has never been stronger. To understand why, it helps to take a brief historical detour.

#### Every rung promised the end of the hard part

The history of programming is a ladder of abstraction. Machine code gave way to assembly, assembly to FORTRAN and the other early high-level languages, and those to the languages most software is written in today. Each rung let a programmer say more with less, and each arrived with a promise that the hard part was about to disappear. IBM's [1954 report](https://softwarepreservation.computerhistory.org/FORTRAN/BackusEtAl-Preliminary%20Report-1954.pdf) proposing FORTRAN said that "FORTRAN should virtually eliminate coding and debugging." In 1981 a British magazine introduced a program called The Last One as ["a program which could become the last one ever written by a human being."](https://www.tebbo.com/archive/pw8102.htm)

Neither came true. Each rung removed a kind of work, but the hard part simply moved further up the ladder with the programmer. FORTRAN freed people from managing the machine and left them the more challenging job of stating the problem precisely. John Backus, who led the FORTRAN team, looked back in 1978 and admitted they had been "hopelessly optimistic in 1954 about the problems of debugging FORTRAN programs."

Grace Hopper wanted the top rung to be English. "What I was after in beginning English language," she said in a [1980 oral history](http://archive.computerhistory.org/resources/text/Oral_History/Hopper_Grace/102702026.05.01.pdf), "was to bring another whole group of people able to use the computer easily. The people that used English, not symbols." Her FLOW-MATIC replaced symbols with English words and became one of the ancestors of COBOL. She met resistance for years. "I had a running compiler and nobody would touch it," she [recalled in 1986](https://news.yale.edu/2015/12/09/happy-109th-birthday-yale-alumna-grace-hopper-pioneer-computer-science), "because, they carefully told me, computers could only do arithmetic, they could not write programs."

Edsger Dijkstra, never one to keep an opinion to himself, thought the whole project a mistake. In a 1975 list he called ["How do we tell truths that might hurt?"](https://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html), he wrote that "the use of COBOL cripples the mind" and that "projects promoting programming in 'natural language' are intrinsically doomed to fail." Yet tucked into the very same list is the line I stole for this essay’s epigraph.

Those claims seem to contradict each other until you see what Dijkstra was worried about. His target was the idea that English-looking syntax would make programming easy. He thought the hard part of programming was knowing exactly what you meant, and that only people with real command of a language could do that reliably. Formal languages, he argued three years later in ["On the foolishness of 'natural language programming'"](https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667.html), are "an amazingly effective tool for ruling out all sorts of nonsense that, when we use our native tongues, are almost impossible to avoid."

In January 2023, Andrej Karpathy [posted](https://x.com/karpathy/status/1617979122625712128): "The hottest new programming language is English". On the question of whether this rung could be built, Dijkstra, clearly, has lost. On the question of what it would demand of those who climb it, I suspect he will be proved right.

#### The first compiler that never says no

For most of its history the computer was a fussy correspondent: every compiler sent back what it could not understand, and every formal language carried a subtler discipline within it. A compiler couldn't tell whether a program did what you meant. But a formal language couldn't take a gesture in place of a decision. There was no way to tell C to handle the edge cases sensibly. Any case you wanted handled had to be written out, and writing it out meant deciding on what you wanted.

A large language model is a more obliging correspondent: it never refuses, and it takes the vague version without complaint. Hand it an ambiguous instruction and it returns the most plausible program, analysis or essay it can, written with the same confidence as if it were given a precise one. Ambiguity no longer fails loudly. It resolves silently into a default, and the default is whatever is most typical of the material the model learned from: roughly speaking, the average of everyone who has written something similar.

The ladder has also turned over. The top rung now composes and writes the lower ones: describe a system in English and a model will write it in Rust. The compiler underneath still refuses malformed code, but it can't tell that the code isn't what you meant.

#### The gap nobody can see

It will be objected that I overstate the case, since models grow more sophisticated at asking clarifying questions every month. That is true, so far as it goes. But a question requires someone to notice a gap in the first place.

To a model, missing context registers as a default. A model will ask about ambiguities it recognizes, like which quarter you meant, because those are ambiguous for everyone. It won't ask about the ones specific to you: that your team defines churn its own way, that the customer already rejected the obvious answer, that the audience has read your last three memos. It has no way of knowing those facts exist, so it has no reason to ask. It fills the space with the likeliest answer and moves on, and nothing in the output tells you it did.

Part of the problem is shared context, which linguists call common ground. Herbert Clark and Susan Brennan observed that in conversation, people "[cannot even begin to coordinate on content without assuming a vast amount of shared information or common ground](https://web.stanford.edu/~clark/1990s/Clark,%20H.H.%20_%20Brennan,%20S.E.%20_Grounding%20in%20communication_%201991.pdf)." Between colleagues, "do the usual cut" can carry a paragraph of meaning, because it’s an experience lived multiple times by both parties. Between you and a model, the only shared context is what you have written down. Writing for a model means decompressing: putting on the page everything you would normally leave to shared history.

Closing that gap with technology would require two things we don't have. The first is a record of the context that mostly never gets written down. Scanning the world’s written materials was hard, but at least the books existed. Most of what a team knows lives in people's heads. The philosopher Michael Polanyi argued in 1966 that much of it can't even be fully put into words: "[we can know more than we can tell](https://press.uchicago.edu/ucp/books/book/chicago/T/bo6035368.html)." The second challenge is the depth of context that can be held. The frontier models from Anthropic, OpenAI and Google top out around one million tokens, roughly 550,000 to 800,000 words. Researchers estimate that a child has heard [up to 100 million words by age 13](https://aclanthology.org/2023.conll-babylm.1.pdf), on the order of a hundred times that, and [Anthropic's own documentation](https://platform.claude.com/docs/en/build-with-claude/context-windows) warns that "as token count grows, accuracy and recall degrade."

#### Why files and rules don't fix it

The obvious remedy is to write everything down once and be done with it, your context codified. I have tried. I keep a 200-line file that tells Claude who is on our team, what we're building and how I like things written, and a separate file of about 90 lines of writing rules. They help, though not quite as much as I had hoped.

Context files go stale, and a model can't tell. One of our engineers put it well in our engineering guide: "An AGENTS.md that describes code that no longer exists is worse than no file, because an agent will act on it confidently." A context file describes the world on the day it was written, and the model treats it as true today.

Rules pile up like case law. Each of my writing rules fixed a specific past mistake. Together they collide: be concise but specific, cut the dashes but keep the rhythm. A model applies them literally and all at once, and some drafts now bend around my rules in ways no person would. The rules record what I disliked but say much less about what I want.

Armies learned this long ago. Detailed orders break on contact with events, so U.S. Army [doctrine](https://irp.fas.org/doddir/army/adp6_0.pdf) asks commanders for intent: a concise statement of purpose that helps subordinates "act to achieve the commander's desired results without further orders, even when the operation does not unfold as planned." A rulebook is a list of old orders. What a model needs for each piece of work is the intent: what this is for, who it's for and what good looks like. Files can supply the background but the intent must be provided fresh for each new task, and it can only come from the human who writes it.

#### Why managers are good at this

If files cannot close the gap, it must instead be the writer. The last few weeks have convinced me that some of us were trained for this task long ago without knowing. Those people have spent years writing for readers who don’t share their full context, who had to be corrected regularly (and therefore benefited from improved instructions), and who would act confidently on tasks once they were given them (regardless of whether they should have been confident). For most of working history, two groups got that practice.

The first is managers. Management is a job built around handing intent to someone who doesn't share your head, over and over, and living with the result. A vague request to a person doesn't stay hidden for long: the wrong deliverable comes back a week later, and you learn what you left out. A good manager states the goal, the reason behind it, what good looks like and what to ignore.

Ethan Mollick, who teaches at Wharton, [saw this](https://www.oneusefulthing.org/p/management-as-ai-superpower) in a class he taught this January. He gave his students four days to build a startup with AI. Most were executive MBAs working as doctors, managers and company leaders, and few had ever coded. He wrote that "in figuring out how to give these instructions to the AI, it turns out you are basically reinventing management," and concluded: "My students figured this out in four days. Not because they were AI natives, but because they already knew how to manage." Anthropic's [prompting guide](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices#be-clear-and-direct) makes the same point from the other side, telling you to "think of Claude as a brilliant but new employee who lacks context on your norms and workflows."

The second group is engineers, who got the same training through a different loop. Formal languages made them write out every decision, and code reviewers kept asking what a function was for until the answer was obvious from the code. That is the practice Dijkstra had in mind when he ranked command of one's native tongue above nearly everything else.

People who never had either loop are at a disadvantage they may never notice, because the model hides it from them. Their vague briefs come back as fluent drafts, and nothing tells them the draft is an average rather than an answer.

#### What a clear brief does

Four disciplines separate a brief that works from one that returns an average. None of them is new; a competent Victorian civil servant would have recognized (and indeed maybe even excelled at) all four.

**It decides the point before any writing starts.** In practice, you can state the argument or the decision in two sentences before you write anything for the model. This matters because a model will commit to some point whether or not you have chosen one, and it will choose the most common one. Skip it and the first draft becomes the thinking: you end up editing toward an idea you haven't formed, which is how I spent five drafts on 150 words. None of this rules out using a model to stress-test the idea first. Just keep that conversation separate from the brief.

**It gives an example before an abstraction.** An adjective gives a model nothing to aim at. "Make it more sophisticated" was one of my earlier notes to Claude, and I got a kind of sophistication I didn't want. One sample of the output you want carries context that a paragraph of description can't, and if you can't produce the example, you probably don't understand the request yet.

**It uses one name for each idea.** A model, like any new reader, can take two words to mean two things. Call someone a customer in one paragraph and a client in the next, and a model may treat them as separate or invent a distinction you never meant. Engineers learn this as naming discipline in code, and it holds just as well for prose.

**It says what the writer doesn't know.** A brief that marks its open questions lets the reader treat them as open. A brief that doesn't gets its gaps filled with confident defaults. The same habit earns trust from human readers. Our engineers' pull requests often say what a change doesn't fix, and it makes the rest of the description easier to believe.

One test covers all four, and Anthropic's guide calls it the golden rule: "Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too."

#### How to write now

The best company rule I've seen on writing with AI is Clay's [AI writing policy](https://www.clay.com/blog/ai-writing-policy), which went viral in August. It allows AI for drafting, requires that "you must stand behind every idea and every sentence in your docs," and holds that "more time should be spent authoring a document than consuming it." It even, I was pleased to see, quotes Pascal. Its most revealing line is almost an aside: "If you are producing a longer piece of writing from a shorter prompt, consider instead just sharing the prompt itself."

I'd take the prompt line further than Clay does. If the brief carries all the decisions, the brief is the document, and it deserves the care we used to give the draft. I've mostly stopped writing first drafts. I write briefs that follow the four disciplines above. Then I ask the model to attack the brief. It can only find the gaps anyone would notice, but answering its questions makes me reread the brief as a stranger would, and that is usually when I find the gaps specific to my work. I revise, let the model draft, and then edit hard. Pascal's step still belongs to me: the cut is where I find out whether the brief really decided what matters.

The strongest objection is that the first draft is where the thinking happens. Ted Chiang [put it memorably](https://www.newyorker.com/culture/the-weekend-essay/why-ai-isnt-going-to-make-art): "Using ChatGPT to complete assignments is like bringing a forklift into the weight room; you will never improve your cognitive fitness that way." Mollick, as enthusiastic about AI as anyone, still writes every post as ["a full draft entirely without any AI use at all."](https://www.oneusefulthing.org/p/against-brain-damage) Chiang is right that the lifting has to happen somewhere. I think it happens in the brief, for students as much as for anyone, because a brief has nowhere to hide an undecided idea, and a draft can cover one with a good paragraph.

That is where I part ways with how most universities have responded. Nearly every student now uses AI: a [2026 survey](https://www.hepi.ac.uk/reports/student-generative-ai-survey-2026/) of UK undergraduates found that 94% use generative AI to help with assessed work. Schools have answered by moving assessment back into the room, in what Cruz calls an "arms race of countermeasures." Cruz himself tried something better. Last semester he let students use AI on their final essays, then gave each of them a 45-minute oral exam, and found that "at least half of the class was more agile, more reflective and clearer during oral exams than they were in their papers." He reads that as a sign that writing matters less. I am not convinced. To me, it is the result you’d get from students who had worked their thoughts out on the page first.

#### What comes next

In a twist of fate Cruz did not expect, we are about to see this battle between speaking and writing play out in the world. Voice tools like Wispr Flow let people speak their briefs instead of typing them, and speaking is fast: in [one controlled study](https://doi.org/10.1145/3161187), people entered English text nearly three times faster by voice than on a keyboard. Spoken briefs will inevitably carry more context, since talking is how we are used to explaining things to people. However, I expect their content to be looser, because speech leans on a listener who can interrupt, and a model won't. The first study I've found on spoken prompts, [published this summer](https://doi.org/10.1145/3816046.3816224), reports that input modality "significantly influenced prompting behaviour but did not lead to measurable differences in subjective evaluations." Which will prevail?

Professor Cruz enlists Socrates on his side, so it is worth recalling what Socrates actually complained of. Writing, he told Phaedrus, is like painting: its creations have "[the attitude of life, and yet if you ask them a question they preserve a solemn silence](https://www.gutenberg.org/ebooks/1636)." The page cannot explain itself, so the writer has always had to do the explaining in advance. Language models make that burden heavier, because for the first time we are writing for a reader that acts on what we say and seldom stops to ask what we meant.

Professor Cruz thinks we have overrated writing. I think we are about to find it rather more important than we thought.

#### Sources

- Edsger W. Dijkstra, ["How do we tell truths that might hurt?"](https://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html) (EWD498), 1975.
- Joe Cruz, ["I'm a College Professor. Writing Isn't as Important as We Think."](https://www.nytimes.com/2026/09/29/opinion/writing-thinking-college-ai.html), *The New York Times*, September 29, 2026.
- Blaise Pascal, [*The Provincial Letters*](https://www.gutenberg.org/ebooks/73959), Letter XVI, December 4, 1656.
- John Backus et al., ["Preliminary Report: Specifications for the IBM Mathematical FORmula TRANslating System, FORTRAN"](https://softwarepreservation.computerhistory.org/FORTRAN/BackusEtAl-Preliminary%20Report-1954.pdf), IBM, 1954.
- David Tebbutt, ["The Last One"](https://www.tebbo.com/archive/pw8102.htm), *Personal Computer World*, February 1981.
- John Backus, ["The History of FORTRAN I, II, and III"](https://softwarepreservation.computerhistory.org/FORTRAN/paper/p165-backus.pdf), ACM History of Programming Languages conference, 1978.
- Grace Hopper, [oral history](http://archive.computerhistory.org/resources/text/Oral_History/Hopper_Grace/102702026.05.01.pdf) interviewed by Angeline Pantages, Computer History Museum, 1980.
- Grace Hopper, interview with *The New York Times*, 1986, quoted in ["Happy 109th birthday to Yale alumna Grace Hopper, a pioneer in computer science"](https://news.yale.edu/2015/12/09/happy-109th-birthday-yale-alumna-grace-hopper-pioneer-computer-science), *Yale News*, December 9, 2015.
- Edsger W. Dijkstra, ["On the foolishness of 'natural language programming'"](https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667.html) (EWD667), 1978.
- Andrej Karpathy, [post on X](https://x.com/karpathy/status/1617979122625712128), January 24, 2023.
- Herbert H. Clark and Susan E. Brennan, ["Grounding in Communication"](https://web.stanford.edu/~clark/1990s/Clark,%20H.H.%20_%20Brennan,%20S.E.%20_Grounding%20in%20communication_%201991.pdf), in *Perspectives on Socially Shared Cognition*, APA, 1991.
- Michael Polanyi, [*The Tacit Dimension*](https://press.uchicago.edu/ucp/books/book/chicago/T/bo6035368.html), 1966.
- Warstadt et al., ["Findings of the BabyLM Challenge: Sample-Efficient Pretraining on Developmentally Plausible Corpora"](https://aclanthology.org/2023.conll-babylm.1.pdf), CoNLL 2023.
- Anthropic, ["Context windows"](https://platform.claude.com/docs/en/build-with-claude/context-windows), Claude Platform Docs.
- U.S. Army, [ADP 6-0, *Mission Command: Command and Control of Army Forces*](https://irp.fas.org/doddir/army/adp6_0.pdf), July 2019.
- Ethan Mollick, ["Management as AI superpower"](https://www.oneusefulthing.org/p/management-as-ai-superpower), *One Useful Thing*, January 27, 2026.
- Anthropic, ["Prompting best practices"](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices), Claude Platform Docs.
- Sophie Alpert, ["Why Clay Has an AI Writing Policy"](https://www.clay.com/blog/ai-writing-policy), Clay, August 19, 2026.
- Ted Chiang, ["Why A.I. Isn't Going to Make Art"](https://www.newyorker.com/culture/the-weekend-essay/why-ai-isnt-going-to-make-art), *The New Yorker*, August 31, 2024.
- Ethan Mollick, ["Against 'Brain Damage'"](https://www.oneusefulthing.org/p/against-brain-damage), *One Useful Thing*, July 7, 2025.
- Rose Stephenson and Charlotte Armstrong, ["Student Generative Artificial Intelligence Survey 2026"](https://www.hepi.ac.uk/reports/student-generative-ai-survey-2026/), HEPI, March 12, 2026.
- Ruan et al., ["Comparing Speech and Keyboard Text Entry for Short Messages in Two Languages on Touchscreen Phones"](https://doi.org/10.1145/3161187), *Proceedings of the ACM on Interactive, Mobile, Wearable and Ubiquitous Technologies*, 2018.
- Rathore, Billakanti, Ceha and Henderson, ["A Comparison of Speech and Typing Input for Creative Generative AI Tasks"](https://doi.org/10.1145/3816046.3816224), CUI 2026, July 2026.
- Plato, [*Phaedrus*](https://www.gutenberg.org/ebooks/1636), translated by Benjamin Jowett.

---

### Your Mistakes Are a Dataset

https://kepler.ai/blog/2026/10/01/your-mistakes-are-a-dataset/ · 2026-10-01 · Michelle Van

When a system gets something right for the 10,000th time, you don't learn much. When it gets something wrong for the first time, you might have found something nobody knew to test for.

I've been thinking about this a lot while building at Kepler. Working with messy, real-world information forces you to get pretty specific about what "wrong" actually means.

**There are a lot of ways these systems can fail without obviously looking broken.** Sometimes a system retrieves exactly the right number, just from the wrong period. Or it identifies every entity correctly but gets the relationship between them wrong. Or it finds the right source, gives the right answer, and somehow the citation still doesn't support the claim. Public-market data has a million versions of this: an actual, management guidance and an analyst estimate can all refer to "revenue," all be legitimate numbers, and all mean completely different things. Retrieval isn't really the problem there. You need to know what the number is.

Relationships are even easier to get subtly wrong. A researcher, a company and a university can show up repeatedly across the same set of documents, and a system can identify all three perfectly while incorrectly inferring that the researcher works for the company. Nothing has been made up. Every entity exists, every source is real, and you can still end up with a false picture of what happened.

I find these failures much more useful than obvious hallucinations because they expose assumptions you didn't realize you were making. And once you find one, why throw it away?

**We've started treating these cases as things worth keeping.** Save what went in, what was retrieved, what came out, what should have happened and why it was wrong. That failure can become an eval, a hard negative, a regression case, maybe training data. Sometimes it just tells you that you've designed something badly. Not every bad output means the model needs fixing either. Plenty of "model problems" turn out to be retrieval problems, stale context, entity resolution, a bad assumption upstream, or perfectly good evidence being combined badly.

Agents make this messier. Once a system is doing more than returning an answer, you have the whole path to care about. It can retrieve the right things, make sensible tool calls and still end up somewhere you didn't want it to go. It can also take a terrible path and somehow arrive at the correct answer. Looking only at the final output hides both.

So lately I've cared less about whether a system can pass the same test again and more about what happens when it surprises us for the first time. Can we turn that surprise into a case it never gets to surprise us with again? Do that for long enough and your eval set starts looking less like a benchmark and more like a history of everything you've learned the hard way: the weird query someone spent half a day debugging, the relationship nobody thought would be ambiguous, the tool call that looked completely reasonable until you saw what happened three steps later.

It's basically organizational scar tissue you can run.

**I also think these eval sets are becoming a competitive advantage.** Models change, infrastructure changes, and a lot of the stack is available to everyone. A good eval set isn't. It accumulates slowly from production: edge cases, user corrections, failures nobody anticipated and distinctions that only become obvious after enough time in a domain. Two teams can use roughly the same models and tooling and end up with very different systems because one has spent years turning those surprises into tests. In that sense, an eval set starts to look a lot like proprietary data.

Playing with Jev has made me think about the other side of this: if these failure sets are valuable, what should actually be open-source? Open-source AI shares plenty of models, frameworks, datasets and infrastructure, but not many of the embarrassing bits. Most failures get fixed, turned into an internal test if we're disciplined, and disappear into a repo or Slack thread. There are good reasons for that. A collection of failures is accumulated domain knowledge, and giving all of that away isn't obviously smart. But the opposite is also kind of absurd: how many teams have independently discovered the same retrieval failure or built the same regression test?

I'd genuinely like to see an open dataset that's just a graveyard of things that broke good systems.

Give me the weird query that fooled every retriever you tried, the relationship every model confidently got wrong, the citation that looked perfect until someone actually read it, the agent run where every step looked fine and the result was a disaster. For each one: here's what happened, here's why it looked reasonable, and here's why it was wrong.

Every tombstone is a test somebody else doesn't have to discover the expensive way.

I'm not convinced all of this should be open. Failures specific to your domain may be some of your most useful proprietary data. But there are plenty of general failures where keeping them private mostly guarantees that somebody else wastes a Tuesday discovering the same thing.

That's also why static benchmarks only tell me so much. By definition, somebody already knew which questions to put on the test. The production failures I care about are the ones that weren't on the test because nobody knew to ask the question yet. As systems get better, those should get rarer and weirder, which is exactly why I want to keep them.

**Your mistakes are a dataset. Treat them like one.**

---

### Kepler in Claude: A Working Guide for Analysts

https://kepler.ai/blog/2026/09/02/kepler-in-claude/ · 2026-09-02 · Rui Zhang

Let's be honest: almost everyone uses Claude in the investment research process now, and nobody wants to go back to how this worked two years ago. It sits open in a tab next to the Excel model, it pulls the segment number out of a 300-page 10-K faster than you can scroll to the footnote, and it drafts an industry overview good enough to edit rather than rewrite.

Then you reach the part where an analysis has to go into an investment memo that will be sent to the PM. You did the responsible thing. You asked Claude to double-check the figure, you asked for the link, and you got a link. The number is formatted correctly, the logic reads well, and the source is a real document. It is probably right.

"Probably" is carrying a lot of weight in that sentence, and the memo has your name on it. So you spot check one figure against the source, and it is off. Every other number in the answer is now a maybe, and you are back to opening the 10-Qs, transcripts, presentations and punching the figures in by hand. The assistant saved you the search and none of the checking. An assistant you trust 85% of the time still costs you 100% of the verification, because you never know in advance which 15% you are sitting in.

#### What the Kepler MCP for Claude is

The Kepler MCP for Claude removes that last step by splitting the work in two. Claude keeps doing the reasoning, and Kepler does the retrieval and the arithmetic against the source documents, including your private documents, SEC filings, earnings call transcripts, investor event transcripts and presentations, and market data, along with the street's view of the name in consensus estimates, sell-side ratings, and the bull and bear cases.

Every figure Kepler returns comes from a primary source and carries a link to it, so checking a number takes one click. The link opens the Kepler app on the source fact, with the workbook and the full citation view next to it, while the research and the writing stay in your Claude conversation. Every calculation runs as deterministic code rather than through a language model, and every number traces back to the document it came from.

None of that requires a migration or a new interface. It is the same chat, the same plain-language question, the same half-formed thought typed between meetings with the spelling to match, and the output underneath is now work you can put your name on.

##### Setting it up

Kepler is a verified connector in Claude and can be added directly from Claude's connector directory. Connect it once, authenticate with your Kepler account, and it is available in every chat on desktop, web, and mobile. There is nothing to install locally and no API key to manage.


*Kepler in Claude's connector directory: connect once, and it is there in every chat.*

##### What a finished run looks like

The answer arrives as a Kepler card in your chat, with Claude's read of it underneath.

The card leads with Kepler's full answer, collapsed so it does not swamp the thread. Expand it and you get the worked analysis: tables where every figure is a link, quotes attributed to the executive who said them, and each number clicking through to the filing fact or transcript line it came from.

Under that sits the sources block, listing the documents the answer rests on, with a badge telling you whether every figure in the response was cited.

An "Open in Kepler" link sits on the card for when you want the full citation view and the workbook.

Claude's summary comes last, in plain prose in the chat, with a link back to the full run and its citation count. It reads the verified work and tells you what actually matters in it, and it is usually the part that ends up in your note. What makes it different from a normal Claude answer is what it is sitting on top of, which is a set of numbers that have already been checked against the filings.


*The card collapsed: the full answer, the sources it rests on, and the badge confirming every figure is cited.*

#### Getting the most out of it

Here are three real examples on live tickers, run in Claude with the connector on.

##### 1. Read the quarter on the day it prints

Kepler picks up documents as soon as they hit EDGAR, so the 8-K with the earnings release is queryable, with the same sourcing and the same citations as everything else, while you are still reading the headline. That matters in the twenty minutes after a print, when the choice is otherwise between waiting until the next morning for a data provider to ingest it and copying the numbers into your model by hand, at the exact moment you have the least attention to spare.

The prompt: summarize key earnings highlights from NVIDIA's newest earnings release. Kepler worked from the Item 2.02 press release filed with the 8-K on August 26, 2026 and returned the quarter with 26 citations, every figure traceable to the line it came from.

Two things in it are why you read a release closely. The Q3 guide assumes no China Data Center compute revenue, and beginning in Q1 FY2027 the non-GAAP figures no longer exclude stock-based compensation, with historical periods restated to match. That second one quietly breaks any year-over-year non-GAAP comparison built on older numbers.

Kepler carries the street's side of the quarter too, so the same conversation can set the print against consensus and show where ratings and the bull and bear cases sit.


*The quarter, minutes after it printed, with each figure linked to the Item 2.02 press release it came from.*

##### 2. Build a model that ties out, then keep pushing on it

A three-statement model for NVIDIA across FY2024 to FY2029 came back as a workbook, income statement, balance sheet and cash flow, with every historical cell sourced to the filing behind it. Refining it is a sentence: rebuild it on NVIDIA's own filing presentation, break out segment revenue, add a year. Where a filing does not disclose something, the cell stays empty and the run tells you why rather than filling it with something plausible.

Nothing about the way you already use Claude has to change here. Keep asking it to build the workbook, chart the trend, lay out the comps sheet the way your team likes it, and draft the section of the note that goes around the table, because Claude is good at all of that and stays good at it. The one thing it cannot do on its own is stand behind the numbers, and that is the gap Kepler fills.

You get Claude's flexibility on the shape of the analysis with Kepler's numbers underneath every cell. If a figure is in there, it came from a source you can open.


*The workbook comes back ready to open or download, with the filings behind it listed on the card.*

##### 3. Push on the calculation people get wrong

Some numbers you can look up. Others have to be built, and enterprise value is one of them, starting with a fully diluted share count that no filing states outright. It gets assembled by hand from several parts of the same document and rebuilt every quarter.

The prompt was the one you would actually type: use Kepler, calculate Palantir's fully diluted share count and enterprise value as of the most recent 10-Q, using today's stock price. What came back was the whole bridge, basic shares through each award type to fully diluted, then equity value down to enterprise value, with the judgment calls written where you can see them: which date the share counts come from, how the stock appreciation rights were treated, the operating lease liability sitting outside the bridge with its number attached in case your house counts leases as debt.

Those are the places you might disagree, and naming them is what lets you overrule them. Two things make the number itself trustworthy. Every input came from exactly the place you would have gone yourself, the cover page, the equity footnote, the balance sheet, each one linking back to that spot in the filing. And no language model touched the arithmetic, because the treasury stock method and the walk down to enterprise value run as deterministic code. A model is good at reasoning about what belongs in an enterprise value and unreliable at executing it, so Kepler never asks one to.


*The share count built step by step, with the dates it rests on stated up front and every input linked back to the 10-Q.*

#### The point

Go back to the memo at the top of this piece. The reason any of us reached for AI tools such as Claude was to get the grunt work off the desk, the extraction, the tie-outs, the share count rebuilt for the fourth quarter running, so the hours go to the part that pays the highest returns: the idea, the variant view, the thing nobody else in the market has noticed yet.

That trade only works if the grunt work comes back done. When you cannot trust the numbers, you do them again yourself, and a tool that was supposed to take work off your plate quietly demotes itself to a summary machine.

That is what changes here with the Kepler MCP in Claude. The extraction and the arithmetic come back finished, sourced, and one click from the filing, inside the same Claude chat you already work in. You stop re-deriving and start building on top, and the speed shows up across the whole workflow rather than in the twenty minutes at the front of it.

Worth saying plainly that the MCP is the narrow end of Kepler. What comes through it is the determinism, retrieval and arithmetic you can trace back to the source, which is what makes an answer defensible in the first place. The platform underneath adds two more layers. It carries an ontology and a search index, so it reasons across filings, transcripts, and your own internal sources when you connect them, as one connected picture rather than one document at a time. And the models are tuned on financial work rather than general text, which lifts the quality of the answer itself and not only its provenance. Most people who start with the MCP end up wanting the rest.

Get in touch and we will get you set up.

---

### From Zero Context to Shipping

https://kepler.ai/blog/2026/08/24/from-zero-context-to-shipping/ · 2026-08-24 · Michelle Van

*What AI changes about understanding unfamiliar systems*

I spent a morning reasoning carefully about a code path that could never run.

The explanation was clean. The types lined up, the downstream logic made sense, and I had enough evidence to keep going. I was also wrong.

This was shortly after I joined Kepler. Joining a new engineering organization has always come with a context tax: you need a model of where state lives, how data moves, which boundaries matter, and which assumptions are intentional. Traditionally, that model accumulates over weeks of reading code, shipping changes, and talking to the people who built it. This time, much of that context accumulated alongside the work. I was moving across Rust services, Python data pipelines, agent infrastructure, and Kepler-specific orchestration while still building my model of how they interacted. AI didn't give me that model. It made it cheaper to construct and test one as I went.

The obvious use of AI here is code generation, and yes, it can write plenty of code. But that turned out to be one of the less interesting sources of leverage. I found it more useful for interrogating the system: trace this value back to where it originated. Show me every path that transforms it. What consumes this downstream? Where is this property actually enforced? If the representation changes here, what assumptions break later? Questions that once required manually tracing several paths through the repository became cheap enough to ask continuously.

**I saw this clearly while tracing provenance through our citation infrastructure.** At Kepler, we want every claim an agent makes to remain traceable to the underlying financial evidence, so provenance has to survive the entire path from source data to answer. Certain XBRL labels were producing malformed citations, so I used AI to trace the representation backwards: every place citations were constructed, the callers that fed them, and the assumptions each path made about source data. Nothing was wrong with the financial data itself. Characters perfectly valid in an XBRL label also had structural meaning inside our citation format. Several construction paths allowed source data to enter that representation without preserving the distinction. The answer could still look right while the provenance attached to it was wrong. The immediate failure was narrow, but the property it touched wasn't: source data should never be able to change the semantics of the mechanism used to prove where it came from. Enumerating the construction paths and tracing their callers was the easy part. The harder question was where to enforce that property once, rather than depend on every caller getting it right.

**The same speed made it easy to run with a good explanation too early.** While tracing how we handled Anthropic API failures, I asked AI to walk the path end to end. The explanation was convincing: the provider returned an error, our error type deserialized it, and the resulting status drove retry and fallback behavior. I spent the morning reasoning from that model. It held until I compared it against an actual provider response. The payload was nested differently from the type we were deserializing it into, which meant real provider errors could fail before ever reaching the retry and fallback logic I had been reasoning about. The type existed. The downstream code existed. AI had connected them correctly. **What neither of us had established was that the contract at the boundary was real.**

AI hadn't invented an API or hallucinated a call path. It had produced a coherent explanation from code that was actually there. It was still wrong about the system's behavior because one plausible assumption had quietly been promoted to fact. **Coherent wasn't the same as established.** And I don't think that failure is separate from the speedup. The same synthesis that let me reconstruct an unfamiliar execution path quickly also made it easier to miss where the evidence stopped. Reading the code manually would have been slower, but I would have had to establish each transition myself. AI could hand me the whole path at once, including the transition it had inferred. **Some of the friction, it turns out, was doing epistemic work.**

I started keeping a mental distinction between what I'd **observed** in code, tests, state, or runtime behavior, what I'd **inferred**, and what remained **unknown**. **AI is very good at making inferred feel like observed.** The type existed: observed. The downstream code behaved a certain way: observed. That real provider responses matched the type: inferred. It also changed the questions I asked. Instead of asking AI only to explain the system, I started asking it to attack the explanation: *Show me the actual external contract. Find another path where this assumption doesn't hold. Show me where this property is enforced — the actual line, not the intent. What would make this explanation wrong?* Nothing moved from inferred to observed because an explanation sounded convincing. It moved when I saw the code, ran the test, inspected the state, or watched the behavior.

**Once I started looking at the boundary this way, other distinctions became harder to ignore.** A streaming response could stop partway through generation and travel through the same completion path as a successful one. From downstream, a half-written answer could look finished. I followed the event forward through our Rust types, deserialization, stream handling, retries, and event propagation. Then I worked backwards: given the state we observed at the end, what paths could have produced it? That exposed other places where information was being collapsed. An unparseable error could acquire a status the provider had never returned. Different termination conditions could converge on the same application state. The problem wasn't that a model provider could fail. That was expected. **The problem was losing the information that told us how it had failed.** AI made those paths faster to reconstruct. Which distinctions belonged in the contract was still an engineering decision. A partial stream, a provider error, and a clean completion aren't implementation details if downstream behavior depends on telling them apart.

**The parallel to what we're building at Kepler was hard to miss.** A fact pulled from a filing, a financial metric calculated from known inputs, and an agent's interpretation of *why* that metric changed can all appear in the same answer. A model can make them sound equally certain. They aren't. The fact needs provenance, the calculation should be reproducible, and the interpretation needs to remain grounded in the evidence underneath it. I was applying the same standard to AI's explanations of the codebase: what was grounded in something I could inspect, and what merely followed convincingly from everything around it?

I expected AI to make me faster at writing software, and it did. What I didn't expect was how quickly it could get me from unfamiliar code to the question of **where a property should be enforced once.** The speed is real; the question is which parts of the path I've actually established and which arrived already assembled for me. The distance from zero context to shipping is getting shorter. **Knowing what should ship is still the hard part.**

---

### Two Forms of a Table

https://kepler.ai/blog/2026/06/30/two-forms-of-table/ · 2026-06-30 · Chris Martin

A table in a document is already an answer to a question — just not yours.

When someone laid it out, they were answering "how do I show this clearly?" They chose which numbers to put side by side, what to nest under what, which cells to leave blank because the value was obvious from context. The arrangement is a communication decision, optimized for a human reading. It is genuinely good at that. It is not, for that same reason, good at much else.

The trouble starts when you ask the table a question it wasn't arranged to answer. *What's the average of this column? Which row has the highest margin? How did this figure change year over year?* The layout that made the table easy to read does nothing for these — and sometimes actively fights them.

Take Table 3 from the original Transformer paper, *Attention Is All You Need*. It lists twenty variations of a model, and its caption gives the rule that makes it readable: "Unlisted values are identical to those of the base model." So the base row is filled in, and almost every row below it is mostly blank — each one shows only the one or two hyperparameters it changed.


For a human, this is perfect: you see at a glance exactly what each experiment varied. The blanks *are* the message.

Now ask it something quantitative, say the average model dimension (`dmodel`) across the (C) group. Suddenly the blanks are the problem. Of the seven rows in that group, five leave `dmodel` blank; their value is implied, inherited from the base row near the top by a rule stated in prose. So "what is the value in this cell," the simplest question you can ask a table, has no answer on the page at all. You have to reconstruct it before you can compute anything.

We tried exactly this. We handed the table as printed to three models, Claude Haiku, Sonnet, and Opus, and asked each for that average. The true answer, once the blanks are resolved to the base value of 512, is 548.57. Sonnet got it right. Haiku answered 640: it had averaged only the two `dmodel` values actually printed in the group and ignored the five blank cells entirely. Opus answered 512, and on a second run visibly thrashed in its reasoning over whether the group had five, six, or seven rows before settling somewhere else. Three models, three different answers, and the disagreement had nothing to do with arithmetic. They split on what a blank cell meant and on which rows even belonged to the group.

Two more details make the point sharper. First, stating the inheritance rule explicitly in the prompt, spelling out that blank means "same as base," barely changed the results; the hard part was never knowing the convention, it was applying it to a layout that encodes group membership by position. Second, when we asked the same models to average two cells whose values were *actually printed* on the page, every one of them answered correctly, every time. The failure tracked the blanks, not the calculation. And the deeper point holds regardless of how good any model is at arithmetic: even if the computation were performed flawlessly, by deterministic code that never rounds wrong or drops a digit, it would still be running on the wrong inputs. The form doesn't just risk a bad calculation. It hides what the calculation is supposed to run on.

This isn't a limitation specific to machines. The table's layout is built to show what changed from one period to the next, so a person scanning it reads off those deltas effortlessly, the blanks never trip them up. But ask that same person to average the numbers, and they hit exactly the issue the models did. The form was never meant to answer "what's the average?"; it answers "what changed?".

A column with a merged header, a subtotal tucked between detail rows, a blank cell that means "same as above," a number whose units live three rows up in a section label: none of that is a problem for a person scanning the page, and all of it is a problem for a clean computation. The form was chosen to convey, not to compute.

So to answer questions you have to turn the table into something else — flat, typed, every implicit value made explicit. The blank `dmodel` cells get filled with 512. The group label that appeared once gets attached to every row it governs. The abbreviations get expanded — `100K` becomes `100000`, and a `params` count printed as `65` under a "×10⁶" header becomes `65000000`, because to a machine `65` and `65 million` are not the same number and nothing on the row says which one is meant. What was a layout becomes a grid where every cell stands on its own and a query can reach any of them without first decoding the arrangement:

<figure class="blog-table">
<table class="numeric-table dense">
  <thead>
    <tr>
      <th scope="col">group</th>
      <th scope="col">N</th>
      <th scope="col">d<sub>model</sub></th>
      <th scope="col">d<sub>ff</sub></th>
      <th scope="col">h</th>
      <th scope="col">d<sub>k</sub></th>
      <th scope="col">d<sub>v</sub></th>
      <th scope="col">P<sub>drop</sub></th>
      <th scope="col">eps<sub>ls</sub></th>
      <th scope="col">steps</th>
      <th scope="col">PPL</th>
      <th scope="col">BLEU</th>
      <th scope="col">params</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">C</th><td>2</td><td>512</td><td>2048</td><td>8</td><td>64</td><td>64</td><td>0.1</td><td>0.1</td><td>100000</td><td>6.11</td><td>23.7</td><td>36000000</td>
    </tr>
    <tr>
      <th scope="row">C</th><td>4</td><td>512</td><td>2048</td><td>8</td><td>64</td><td>64</td><td>0.1</td><td>0.1</td><td>100000</td><td>5.19</td><td>25.3</td><td>50000000</td>
    </tr>
    <tr>
      <th scope="row">C</th><td>8</td><td>512</td><td>2048</td><td>8</td><td>64</td><td>64</td><td>0.1</td><td>0.1</td><td>100000</td><td>4.88</td><td>25.5</td><td>80000000</td>
    </tr>
    <tr>
      <th scope="row">C</th><td>6</td><td>256</td><td>2048</td><td>8</td><td>32</td><td>32</td><td>0.1</td><td>0.1</td><td>100000</td><td>5.75</td><td>24.5</td><td>28000000</td>
    </tr>
    <tr>
      <th scope="row">C</th><td>6</td><td>1024</td><td>2048</td><td>8</td><td>128</td><td>128</td><td>0.1</td><td>0.1</td><td>100000</td><td>4.66</td><td>26.0</td><td>168000000</td>
    </tr>
    <tr>
      <th scope="row">C</th><td>6</td><td>512</td><td>1024</td><td>8</td><td>64</td><td>64</td><td>0.1</td><td>0.1</td><td>100000</td><td>5.12</td><td>25.4</td><td>53000000</td>
    </tr>
    <tr>
      <th scope="row">C</th><td>6</td><td>512</td><td>4096</td><td>8</td><td>64</td><td>64</td><td>0.1</td><td>0.1</td><td>100000</td><td>4.75</td><td>26.2</td><td>90000000</td>
    </tr>
  </tbody>
</table>
<figcaption>The working form of Table 3's (C) group: blank cells resolved to the base value of 512, abbreviations expanded (100K → 100000), and parameter counts multiplied out.</figcaption>
</figure>

Call it the working form. It's the thing you actually run a computation against, and it's almost never shaped like the table in the document. Set it beside the original: where the sparse table showed three changes at a glance, this one is a wall of repeated 512s and 100000s and tells you nothing at a glance. That's the trade. `AVG(dmodel)` is now unambiguous, and the cell that had no answer on the page (`dmodel` where `dff=1024`) plainly reads 512 — bought with redundancy that makes the form unreadable.

Which is fine, because it was never supposed to read well. You shouldn't expect any one form to be best at everything. The form that answers "average this column" is not the form that answers "trace this total to its parts," and neither is the form that reads well on a page. This isn't special to tables; it's the ordinary state of things. Optimization theory states a hard version of it as the No Free Lunch theorem: no method beats every other across all possible problems, because an edge on one class of problems is paid for by a deficit on the rest. The consumer packaged goods version is friendlier. When Howard Moskowitz went looking for the perfect spaghetti sauce, he found there wasn't one, only the best sauce for each kind of eater. A table's layout is tuned to win at reading. That is exactly why it isn't tuned to win at computing.

There's a second thing worth being clear about, and it's the part that's easy to skip: the working form cannot be the only thing you keep.

Because the moment you give someone an answer, an average, a flagged row, a computed change, the next question is *where did that come from?* And the working form can't answer that. It's a derivation, a step or two removed from anything the reader recognizes. If you tell an analyst the average `dmodel` for that group is 548.57 and they ask to see it, pointing at your flattened grid with the blanks filled in shows them your intermediate state, not the paper.

And it asks them to trust two things at once: that your transformation was faithful, with blanks resolved right, rows grouped right, nothing dropped, *and* that the source underneath says what you claim it does. Bundled together like that, neither is checkable. If the number looks off, they can't tell whether your pipeline mangled it or the document really says that. Showing the original separates the two: they verify the source against something they recognize, and your transformation becomes a thing they can check against it rather than take on faith. A derivation can be perfectly correct and still not be evidence, because evidence has to be verifiable by the person who doubts it, and they can only verify against the form they already trust.

So the thing they can check is the table as it appeared, the sparse one, with the blanks, in the arrangement they'd find if they opened the document themselves. That original form is useless for the math and essential for the trust. You computed on the version you built; you have to be able to point back at the version they recognize, because it's the one artifact in the loop you didn't produce.

Keeping both is the easy part to state. The hard part is everything in the middle: the bridge between the two forms. Going from the document to the working form means recovering structure that was never written down. The base row this table inherits from is named in a caption. In most real documents the rule is in no caption at all, only implied by indentation, a spanning header, a line of whitespace, the fact that one number is bold. You have to infer the convention, apply it, expand the abbreviations and units, and carry an unbroken thread from every resolved cell back to the exact place on the page it came from, so the answer stays traceable. Do that for one clean table from a famous paper and it's a puzzle. Do it for a document built by someone who was thinking about a printed page and not about you, across thousands of tables that each improvise their own conventions, and the puzzle is most of the problem.

Three modern models couldn't agree on the average of a column in **this** table, the tidy one, with the rule spelled out in the caption. That is the measure of how unsolved the general version is. The bridge between the readable form and the computable one, built so the answer comes out both correct and defensible, is the part nobody has finished. It is also the part most worth working on.

The mistake isn't choosing the wrong form. It's thinking there's one form that has to serve both jobs. There isn't. The table you show and the table you compute on are two different things, and a system that can answer questions from documents *and* show its work is one that knows to keep them both: the original because that's where the answer came from, the derived because that's the only place the answer could be found.

If this is the kind of problem you want to work on, [we're hiring](https://kepler.ai/careers/).

---

*Table 3 reproduced from Vaswani et al., "Attention Is All You Need" (2017). https://arxiv.org/abs/1706.03762*

---

### The Real Painkiller for Financial Analysts: Kepler on the GameStop-eBay Deal

https://kepler.ai/blog/2026/06/17/painkiller-gamestop-ebay/ · 2026-06-17 · Rui Zhang

In early May 2026, GameStop made an unsolicited $55 billion bid for eBay. On May 12th, eBay's board rejected it as "neither credible nor attractive." Somewhere in those ten days, every covering analyst on the street probably got the same email from their PM: give me a view on this deal by end of day.

If you're one of them and you don't already cover the names, you're starting from a blank page on a deal that's already moving: a mountain of quantitative data and qualitative claims to work through, a deadline measured in hours, and no room for a single wrong number. We put Kepler through the four workflows that cause analysts the most pain in exactly this situation, and we show each step with real screenshots, so you can see how it takes you from blank page to a defensible view. This is the difference between a supplement and a painkiller: the tools you have now are nice to have, but here are the four places Kepler actually stops the pain.

Here are the four workflows we'll walk through:

1. **Get smart on the deal:** a cited, verifiable briefing on offer terms, premium math, financing structure, timeline, and where each side stands from trustworthy sources.
2. **Pull eBay's financials for the last decade:** as-reported, three-statement data pulled straight from SEC filings into a workbook where every figure links back to its source so you have a solid foundation to work with.
3. **Mine a decade of earnings calls for insights:** management's strategic narrative on marketing spend, active buyers, GMV growth, and take rate, assembled chronologically with every claim hyperlinked to the transcript.
4. **Map the change-of-control economics:** a side-by-side of what each company's executives stand to gain in a deal, every figure traced to the proxy.

#### Workflow 1: Get smart on the deal

*Summarize the GameStop - eBay deal. Include offer terms, premium math, financing structure, deal timeline, and key statements from both sides.*

Before you can do any real analysis, you need to know the basics: what's being offered, at what price, how it's being financed, and where each side stands. Most analysts would Google it, or type the question into ChatGPT or Claude, and there's nothing wrong with that instinct. The problem is what you do with the answer. You can't put it in front of your PM unless you're sure every fact is real, not hallucinated, and not pulled from some random corner of the internet.

Kepler runs a broad web search, the same way you're used to from other AI chat tools, but with a few things that make a real difference for finance work. We don't pull from random sites just because they show up in the index. We make sure every conclusion we draw is directly linked to underlying evidence through our system, so the hallucination problem that makes other tools unusable for real work doesn't exist here. **And like everything else on Kepler, every fact is cited and traced back to its source, so you never have to wonder whether we got it right.**


*Workflow 1: a cited deal summary, with every claim traceable back to its original source in one click.*

#### Workflow 2: Pull eBay's financial statements for the last decade

*Pull eBay's financial statements for the last 10 years*

This is the foundation of every diligence process, and it's also one of the most tedious things an analyst does. As-reported three-statement financials pulled directly from SEC filings, formatted into a workbook you can actually build off of. Done manually, it's the kind of work that can take the better part of a day, especially if you're being careful about getting the line item hierarchy right and not silently restating anything.

The strange thing is that most analysts still do it manually even though half a dozen data providers will sell you exactly this. CapIQ, FactSet, Bloomberg, all of them have it. The reason analysts ignore those feeds and copy-paste from 10-Ks themselves is simple: it's the only way they know for sure that the number on their model matches the number the company actually reported. Standardized data feeds restate, reclassify, and occasionally just get things wrong, and when your PM asks why your revenue number is $40 million off from the 10-K, "that's what FactSet had" is not an answer.

**That's why at Kepler we don't take the shortcut of buying this data from a vendor. We pull it directly from the SEC.** Kepler identifies eBay's ticker, pulls the 10-Ks from FY2016 through FY2025, and extracts and consolidates every line item across the three statements, all from the original filings.

The output is a clean, downloadable Excel workbook. Click any number and Kepler highlights the exact source in the original filing on the side bar, so you can see at a glance that the figure on your screen matches the figure on the page. No black box, and no guessing whether the model got it right.


*Workflow 2: a clean three-statement workbook for eBay, FY2016 through FY2025, with every cell clickable back to the line in the original 10-K.*

#### Workflow 3: Mine eBay historical earnings call transcripts for the strategic narrative

*Mine eBay's earnings calls from Q1 2018 through the most recent quarter and analyze the following topics: 1. sales and marketing spend, customer acquisition cost, and marketing efficiency 2. active buyer trends 3. focus categories strategy 4. GMV growth and take rate, including segment or geographic breakdowns where discussed*

To build a real view on a deal, you have to understand the target's strategic narrative as told by its own management. What have they said about the business over time? What have they promised? What have they actually delivered? The answer to those questions doesn't live in one quarter's earnings call or one investor day. It lives across years of management commentary, and you can't form a defensible view without going back through all of it.

For eBay, that means roughly 33 quarterly earnings calls of meaningful data. Done by hand, the work is exactly what it sounds like: download every transcript, ctrl-F your way through each one for mentions of marketing spend, active buyers, GMV growth, take rate, and the focus-category strategy, then try to assemble a coherent narrative from thousands of pages of text. It's the kind of project that usually gets half-finished.

Kepler reads every available transcript in full and organizes the findings into a chronological narrative across the themes you specified. Every specific number, every named program, every claim about what management said is hyperlinked back to the exact passage in the source transcript. Click +120 bps YoY and you land on the actual line from the Q1 2018 call where the exec said it.

This is where Kepler is doing something other LLM tools can't. The synthesis is real, but the synthesis is grounded in source material that you can verify in one click. When your PM asks "where did they say that?" for any specific number, any claim, any piece of color in the analysis, the answer is one click away.


*Workflow 3: a chronological narrative across eight years of eBay earnings calls, with every number and quote hyperlinked to the exact line in the source transcript.*

#### Workflow 4: Map the change-of-control economics for eBay's management

*Pull the most recent DEF 14A for eBay and GameStop. For each named executive officer, extract base salary, target bonus, unvested equity, and change-of-control terms (cash severance, equity acceleration, 280G gross-ups).*

In any contested or hostile situation, management incentives matter as much as the underlying financials. The single biggest predictor of how a board will respond to an unsolicited offer isn't the strategic logic of the deal or even the price. It's what the executives personally stand to gain or lose. Before you take a view on whether a target's board is likely to engage or fight, you need to know what its executives would receive in a change of control.

That information lives across each company's most recent DEF 14A and the underlying employment agreements it references. A typical proxy runs eighty to a hundred pages, and the relevant disclosures are scattered across half a dozen sections that don't always cross-reference each other cleanly. Done by hand, you'd work through the Summary Compensation Table, the Outstanding Equity Awards table, and the "Potential Payments Upon Termination or Change in Control" section, then cross-reference the employment agreements for severance multiples and equity acceleration triggers. It's the kind of analysis that often gets skipped entirely when the deadline is the close.

Kepler reads both proxies in full and produces a side-by-side view of change-of-control economics for the named executive officers at each company. For the target, it calculates the dollar value of equity acceleration at the offer price using the share counts from the Outstanding Equity Awards table.

With that side-by-side in front of you, you can answer the questions that actually drive board behavior. What does the CEO walk away with at the deal price? How does that compare to what they'd earn over the next three years on a standalone basis? Does the acquirer's team stand to make significantly more or less than the target's? You stop guessing at the board's motivation and start having a real read on it.

Every figure is clickable, traceable back to the proxy footnote or filing it came from. You're not betting your credibility on the AI, you're using it to help you with the work and then verifying what matters.


*Workflow 4: a side-by-side view of change-of-control economics for eBay and GameStop named executive officers, with every figure traceable back to the proxy footnote it came from.*

#### The point

None of the work above is novel. Every covering analyst at every shop is doing some version of it all the time. What's different is that today, almost all of it gets done by hand, because no analyst is going to put an unverified AI output in front of their PM and keep their job for long.

That's the gap Kepler closes, and it's why Kepler is a painkiller and not another supplement. The tools analysts have today are nice to have; they don't touch the pain that keeps you at your desk at 4AM. Kepler does, because every number, every quote, and every assumption in these four workflows is checkable in one click. Not probably right. Provably right.

If you have a deal landing on your desk this week, or a name you need to get smart on fast, [request a demo](https://kepler.ai/demo/).

---

### Elegant and Wrong

https://kepler.ai/blog/2026/06/03/elegant-and-wrong/ · 2026-06-03 · Susannah Meyer

Before a company can go public, it files an S-1. SpaceX's ran more than 350 pages, and the data underneath was denser still: eleven megabytes of HTML, 160 tables, more than twelve thousand cells. The form is heavily regulated, down to how the financial statements are presented and audited. If rules alone could make data clean, an S-1 is where it would show.

They can't. Open the HTML and 49.8% of those cells are empty: blank spacer cells that align dollar signs and digits. Row labels trail off in runs of dots, Revenue............. That much you can strip and forget. The table is still a picture of data, not data, and the picture is where the trouble starts.

<figure>


<figcaption>SpaceX's S-1 income statement displayed in Kepler's document viewer.</figcaption>
</figure>

This is the lesson real data keeps teaching, and the one that shaped how we built citations. The clean, generic data model you reach for first is a hypothesis, not a fact, and the data is free to reject it.

#### You can't trust the table

Take SpaceX's income statement. It's really two tables sharing one column of labels. As the HTML carries it, the header is two stacked rows:

<figure class="blog-table">
<table class="numeric-table">
  <thead>
    <tr>
      <th></th>
      <th colspan="2">Three Months Ended March 31</th>
      <th colspan="3">Year Ended December 31</th>
    </tr>
    <tr>
      <th></th>
      <th>2026</th>
      <th>2025</th>
      <th>2025</th>
      <th>2024</th>
      <th>2023</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th>Revenue</th>
      <td>$4,694</td>
      <td>$4,067</td>
      <td>$18,674</td>
      <td>$14,015</td>
      <td>$10,387</td>
    </tr>
  </tbody>
</table>
<figcaption>From SpaceX's S-1, spacer columns stripped. Two date ranges, one row of labels, and "2025" stamped on two different columns.</figcaption>
</figure>

An income statement reports a company's revenue and costs over a period, and filings show several periods at once: the most recent quarter beside the last few full years. The header is the only thing telling those columns apart, and it stamps "2025" on two of them, the three months ending March 31 and the full year ending December 31. So the filing carries two different 2025 revenues: $4,067 million for the quarter and $18,674 million for the year. Ask for "2025 revenue" and one answer is more than four times the other, with nothing in the cell to say which you got.

Reading down a single column is no safer. One parenthetical, "(in millions, except per share data)," sets the scale, and the scale changes line to line:

| In the full-year column | The cell says | It means |
| :-- | :-- | :-- |
| Revenue | 18,674 | $18.674 billion |
| Basic | (1.69) | −$1.69 per share |
| Basic | 2,926 | 2.926 billion shares |

One column, three units, and "Basic" labeling two unrelated rows, earnings per share and the share count used to compute earnings per share, told apart only by the section heading above each. The difficulty was never the dots or the blank cells. It is that the table encodes a schema it never states, and the display is the only copy you get.

The document also doesn't sit still. SpaceX filed this S-1 on May 20 and amended it twelve days later. In those twelve days, completed Starship flight tests went from 11 to 12, and the operating metrics gained a new value. Once SpaceX is public, these same numbers will reappear every year in a 10-K, its annual report, this time carrying clean XBRL tags, the machine-readable layer the SEC requires on those reports. Every version is a real source someone might cite, and they don't always agree. Clean is not a finish line. It is one more version of the fact to reconcile with the rest.

#### Every source is a picture of data

This messiness isn't unique: it's characteristic. Every income statement does some version of it, which is the point. We stopped calling these edge cases, because when the edges are most of what you meet, they are not edges. They are the distribution, and you build for the distribution you have.

And all of it is one kind of problem, in one table, in one form, of one source. SEC filings are the most structured input we get, and that is what they look like underneath. Every other source has to be just as citeable, down to the single number, and none of them are cleaner. An earnings-call transcript is speech: someone says "five billion," and you recover five billion of what, in which currency, for which segment. An investor deck buries the figure in a chart, as pixels. News rounds it and rounds it again. Market data looks clean until a split or a dividend adjustment means the price on the screen is not the price you need.

A single abstraction over all of that would have shattered on the second source, so we never built one. Instead of unifying the sources, we unified one level up. Each source decides, on its own terms, what makes one of its facts addressable: a cell in a table, a moment in a transcript, a mark on a chart. Sources stay messy. Citations stay uniform. A new source only has to solve its own fact location and schema.

#### A citation is a place

Inside one filing the problem inverts: not too many kinds of a fact, but too many copies of it. SpaceX's $18,674 million of 2025 revenue appears ten times across the S-1, in the statements, the selected-financials table, the management discussion (MD&A), a line of prose. Sometimes it is the first column, sometimes the third. Search for the value and you find all ten, with no way to know which one the model meant, because nothing in the text marks one as right. Patch that with heuristics and looser matching and the fallback path soon grows faster than the happy path. That is the tell that you're solving the wrong problem.

So a citation stopped being a value and became a place: a specific cell, in a specific table, in a specific section with meaning. The model emits an address or table reference along with the number, and a check confirms the cell at that address holds what the model claimed. The citation is verifiable, not just plausible. Because the address can be recomputed, the system can always verify a citation still points where it should, so the data changing underneath gets caught instead of quietly going wrong.

<figure>


<figcaption>A Kepler chat extracting SpaceX's income statement, each figure cited back to the filing.</figcaption>
</figure>

The addresses were there the whole time, in the structure that first looked like noise.

> Markdown is what engineers want to standardize on: clean and readable. HTML is what actually preserves a filing's meaning, the merged headers and column spans that pin each number to a period and a scale.

It is old and ugly, and it keeps the guarantees the prettier format throws away. The work was to stop flattening that structure into something readable and wrong, and to trust the addresses already in it. The fuzzy-matching fallbacks we had piled up stopped mattering, and we deleted them.

#### Following the data

Our namesake, Johannes Kepler, spent years on a problem like this. He inherited Tycho Brahe's observations, the most precise measurements of the sky anyone had yet made, and tried to fit the orbit of Mars to a circle, because for two thousand years everyone knew the heavens moved in circles. His best circle missed Brahe's data by eight arcminutes, a gap most would have written off as error. He refused to. The circles never fit; the ellipse did.

That is the whole job, four hundred years apart. The elegant model is the circle; the data is the ellipse. We keep the ellipse because the goal underneath all of this comes down to one sentence: every number Kepler shows can be traced to where it came from, whether that is a cell in a filing or the calculation that produced it. That is what verifiable AI requires, and no model is clever enough to skip it.

You earn it by handling the data the world actually files. Kepler runs at decision points and in work that goes in front of clients and regulators, where a confident wrong number costs far more than an honest "not yet."

Sara recently wrote about what happens after an answer exists: [how do you grade it](https://kepler.ai/blog/2026/05/20/the-yardstick-problem/)? This is about what has to be true first. You can't grade, or trust, a number you can't trace to where it came from.

If this is the kind of problem you want to work on, [we're hiring](https://kepler.ai/careers/).

---

### How Quartr Helps Kepler Build Citation-Grade Earnings Research

https://kepler.ai/blog/2026/06/02/how-quartr-helps-kepler-build-citation-grade-earnings-research/ · 2026-06-02 · Vinoo Ganesh

*This post was originally published on [Quartr's blog](https://quartr.com/customers/how-kepler-made-every-ai-answer-traceable-to-a-primary-source-powered-by-quartr).*

---

A research analyst's job is unforgiving. Every number in a model has to survive a PM pointing at it and asking where it came from. Every line of management commentary has to survive the same person pulling up the transcript. Every slide reference has to survive someone opening the deck to that page. Credibility compounds over years and erodes in seconds.

That is the work Kepler is built to do.

Kepler is the verifiability layer for AI. Kepler for Finance, our first product, lets analysts at hedge funds, PE shops, and investment banks query SEC filings, earnings calls, and IR materials together, and trace every number, quote, and slide reference back to its exact source. The goal is research the analyst can defend in the room they work in.

This post is about how we make that possible across the earnings event, and where Quartr fits.

#### AI interprets. Code executes. They never cross lanes.

The defining design decision in Kepler is that the language model never touches the numbers.

When an analyst asks Kepler a question, the AI layer does what language models are good at. It parses what the analyst meant, decomposes the question into sub-problems, decides which sources and which calculations are needed, and writes the narrative answer at the end. It interprets, plans, and composes.

The numbers themselves come from a different layer. Every figure that appears in a Kepler answer is fetched by deterministic code from a pre-extracted, provenance-tracked store. Every derived metric is computed by deterministic code using a fixed formula. Every citation is a pointer to a specific filing, page, line item, transcript passage, or slide phrase, attached at the moment the underlying data was extracted, not generated after the fact.

A proprietary financial ontology mediates between the two layers, so the language model and the retrieval layer speak the same vocabulary of companies, filings, line items, and events.

That single property is what makes the platform auditable. Same question, same underlying data, same answer, every time. If a number is wrong, the cause is in the extraction pipeline or the formula, and both are inspectable.

#### Where Quartr fits

Three sources matter for a typical earnings event question, and Kepler pre-extracts all three.

The SEC filing tells you what happened. The earnings call transcript tells you why, and what management thinks happens next. The IR slide deck tells you what management wants the market to see.

We pull the transcript and the slide deck from Quartr. Their API gives us first-party IR content across 15,000+ companies and 65+ markets, structured and ready for retrieval. Our pipeline ingests each transcript, segments prepared remarks from Q&A, tags speakers, and timestamps passages. It extracts slide content at the phrase level with page and bounding-box coordinates, so a citation can land on the exact line of the right slide, not just on the deck as a whole.

Standing up that layer without a partner like Quartr would have meant either running our own transcription and IR-scraping operation at that scale, or relying on aggregators with quality and timeliness gaps we would compensate for downstream. Neither cleared our bar. Quartr did.

We extract once, normalize, store, and serve from our own infrastructure. The analyst is never waiting on a fresh fetch.

#### What this looks like in a real query

Consider a question we see often: "Walk me through the bridge between management's tone on margin pressure this quarter, what they reported in the income statement, and what they put on the IR deck."

Kepler returns a single cited synthesis pulling from the 10-Q, the Quartr transcript, and the Quartr IR deck for the same period. Every figure, quote, and slide reference is click-through: a number opens the 10-Q at the cited line item, a quote opens the Quartr transcript at the timestamp and speaker, a slide reference opens the IR deck on the cited page with the phrase highlighted.

What used to be tens of minutes of reconciling tabs, scrolling transcripts, and screenshotting slides becomes a few seconds of work the analyst can verify line by line before sending it on. The verification step is the point.


*A Kepler answer in flight. Every cited claim links back to the exact transcript passage and speaker.*

#### Why this is the standard

The standard hallucination story is incomplete. Wrong-and-obvious is not the dangerous failure mode in finance. Wrong-and-plausible is, and it is the architectural consequence of letting the language model produce the numbers.

Kepler removes that mode at the design level. Numbers are fetched, not generated. Computations run as fixed formulas in deterministic code. Citations are pointers attached to a figure at extraction time. The model can still get the interpretation wrong, and we have ways to catch that, but it cannot produce a confidently incorrect number, because it does not produce numbers.

That is the standard we hold ourselves to. Verifiably correct, not likely correct.

#### From Quartr

We asked Oscar Küntzel, Quartr's co-founder and CEO, for his take on the partnership.

> "Financial AI has had a foundational problem from day one. Earnings calls, transcripts, and filings, the primary inputs in company research, were built for humans to read one at a time, not for AI to query across thousands of companies. Kepler is one of the sharpest teams we've seen building on top of Quartr API, turning clean, first-party IR data into analyst workflows that are trustworthy and fully verifiable. We're proud to be the infrastructure they're building on."
>
> — Oscar Küntzel, co-founder and CEO, Quartr

#### Where this goes

Kepler's corpus already runs to 26 million SEC filings, 50 million additional public documents, and over 1 million private documents, across 14,000 companies in 27 global markets. The 2026 roadmap extends that across more sources, more markets, and adjacent regulated domains.

The architecture is built for finance, but it is not specific to finance. The provenance guarantees we hold ourselves to for an earnings transcript apply just as cleanly to a clinical trial transcript, a court ruling, a regulatory filing, or a procurement record. Finance is the proving ground. The architecture is general.

---

If your team is running point on earnings season, [request a demo](https://kepler.ai/demo/).

---

### Why Data Pipelines Need Stronger Guardrails in the AI Era

https://kepler.ai/blog/2026/05/28/developing-pipelines-faster-in-the-ai-era/ · 2026-05-28 · Sean Gorsky

"Move fast and break things" is a startup mantra for good reason. Spending months hardening something whose value you haven't proven is its own kind of failure. But as a former coworker liked to remind me, it's "move fast and break things, not move fast and drive off a cliff." That distinction has never mattered more. AI has increased how fast a small team can ship, but it has also increased how quickly you can introduce silent, structural damage you won't catch until much later.

That asymmetry bites harder in data pipelines. Pipelines sit as far upstream as it gets, and every table, dashboard, and AI-generated answer downstream inherits whatever they produce. A single corrupted column can break trust with a user whose report suddenly shows incorrect revenue, and that kind of damage is exactly what Kepler is built to prevent. When a frontend deploy breaks, users see a 500 and you ship a fix in an hour. When a pipeline silently corrupts data, you might not notice for a week, and the cleanup takes days of careful backfills. Bigger blast radius, longer feedback loop.

Most recently, following these principles enabled us to rewrite our SEC document processing pipeline, cutting `filing -> processed` time from over an hour to just 30 seconds. We were able to tackle what was effectively major surgery on our pipeline in just two days, with confidence that the result was working and safe.

The question isn't whether to use AI to move fast. That ship has sailed; in a hot space, you don't get to opt out. The question is how to set yourself up so AI accelerates you safely. Two things have mattered most in building Kepler's pipeline from scratch: code quality and testing. Neither is a new topic, but both look different when an agent is doing a lot of the writing.


#### Code Quality

Humans and AI are fundamentally good at the same thing: pattern matching. That fact alone means code quality matters more in the AI era than ever before. The patterns in the structure of your code (naming conventions, boundaries, abstractions) are signals an agent reads just like a human does. When that signal is noisy, the agent's output gets noisier with it.

*Naming consistency*. If you use a coding agent like Claude Code, you'll watch it grep constantly to locate where a function or variable is used. Inconsistent naming makes the agent work harder at best, and miss relevant call sites at worst. It also corrupts what the agent writes next: consistent conventions dramatically increase the odds the agent matches the pattern when introducing new code. This sounds like a nit, but it compounds. Every new piece of code either reinforces the convention or muddies it, and codebases that drift become harder for any agent to reason about.

*Organic abstraction*. Coding agents know shared logic should be factored out; it's programming 101. But they don't consistently apply that knowledge during organic growth. You build implementation A. Later you ask the agent to add implementation B, and more often than not it writes B as a parallel copy of A rather than refactoring both behind a shared abstraction. Here's the interesting part: if you already have a well-abstracted A and B, then ask the agent to add a C, it will notice the pattern ('ah! There's a shape to match here') and organically add the new component in a clean way. The abstraction lives where the agent can see it just as a human would. The secret here is that your agent may not consider the initial abstraction opportunity when adding B; it's on you to pay attention and coerce good structure as the agent goes.

#### Testing

Testing earns a special place early in the development cycle. During ideation, you're wandering in a fog of ideas. As you experiment, that fog slowly coalesces into more coherent pieces that fit together to form something meaningful. Those pieces change so dramatically and so often that, for a while, tests aren't even worth it. However, those same pieces will often be important and serving early customers before they're fully baked. At that point, you'll want testing in place to ensure those customers stay happy as you continue whittling away at the pipeline. When agents are driving most of this implementation, it's important to have the right testing philosophy to ensure development is safe and the codebase is moving in a direction of improved quality.

- A proper staging environment: This is the single most important investment for pipeline work, and AI makes it more important, not less. An agent can produce a change that looks correct, passes review, and passes unit tests, but still breaks the pipeline or taints the data. A staging pipeline that mirrors production on separate infra is the only reliable check against that class of failure. It's especially valuable during major surgery or refactoring, when smaller tests carry little weight. Agents are also very proficient at doing A/B comparisons between staging and prod datastores, a task that would normally be tedious and slow for a person. For example, you can direct an agent to "compare table entries between Table-X in prod and staging to determine the impact of our change," and it will produce a comprehensive comparison for you in just a few moments.

- Integration tests: By the time you're serving real customers, you should have a coarse shape of your pipeline components even if they're rough around the edges. At that point, integration tests (tests that capture the ins and outs of those components without caring much about implementation details) are the most valuable. When you commit work, the changes to those tests show you how the *shape* and *intent* of the code have changed, which at this stage is the heart of what you're working on. If you focus on a handful of integration tests, those tests carry huge weight and consideration when committing. Agents will also take note of this and give more consideration to integration tests, especially if their significance is called out in comments.

- Unit tests: They still have their place, but sparingly. They earn their keep on small, load-bearing functions where the behavior is the contract. String normalization is the canonical example in our codebase. A handful of input/output examples is as useful to an agent as it is to a human. The trap is letting an agent generate dozens of unit tests for every code path, which devalues the integration tests that are the real weight-bearing tests. When you're directing your agent to refactor the boundary components, you want the integration tests to carry the weight, not the unit tests.

#### Closing

None of this is about slowing down. It's about not driving off the cliff while you're moving fast. Code quality and a meaningful testing framework are what let an agent write three days of code in an afternoon without leaving you a week of cleanup later. They're not brakes; they're guardrails that keep you on the road during pipeline work, and they help you move faster than ever before.

These are the principles that allow us to build data pipelines that surface new reports dropped within 30 seconds, giving the analysts on our platform a massive competitive advantage.

If this is the kind of problem you want to work on, [we're hiring](https://kepler.ai/careers/).

---

### The Yardstick Problem

https://kepler.ai/blog/2026/05/20/the-yardstick-problem/ · 2026-05-20 · Sara Kromwijk

You can't unit-test a probability distribution. Run the same prompt twice, you might get two different outputs. Run it on next quarter's model and you definitely will. Somewhere in there, the product is either getting better or getting worse, and you're supposed to know which.

This is the problem every team shipping LLM-based products has to solve, and most don't solve it well. We didn't either, at first.

#### The ground keeps moving

The naive picture of an LLM is a function: input goes in, output comes out. The picture is wrong in two directions. Same input, same model, two runs: different outputs, by design.[^1] Same input, new model version: also different outputs, because each release is in some sense a different function.

The second one is sneakier. When Sonnet 4.5 became Sonnet 4.6, we quietly inherited a new default: more emojis. In a chat assistant, that's just a bit of personality. In a product whose deliverable is a board-ready financial memo, an emoji on a debt-to-equity line item is unacceptable. The instruction to avoid them was still in the prompt. The model was just less inclined to follow it.

This is the second-order version of the failure mode the [Trust post](https://kepler.ai/blog/2026/02/10/trust-in-the-age-of-ai/) described: the model drifting toward "things it simply knows" rather than things it can cite. Earlier it was prompt-following degrading inside a session. Here it's prompt-following degrading across releases. Both have the same shape: a behavior that used to be reliable is now slightly less so, and nothing on the surface tells you, until a customer does.

Emojis are the easy case. The hard case is when the model gets the numbers right but takes a shortcut on the reasoning: pads a citation with common knowledge, declines to flag uncertainty, recalls a figure it "semi-remembers" from training rather than retrieving it. The output looks the same. The product is quietly worse. This is also why smarter models aren't automatically better: the more internalized knowledge they have, the more likely they are to use it. While this is the right trade-off when latency is critical (e.g. when chatting), it really isn't when it comes to sourcing. [^2]

#### You can't grade essays with a unit test

The standard testing playbook breaks down here. Software tests work because the right answer is a single value and the wrong answer is anything else. An LLM-generated report is not a value. It's a paragraph, and "is this paragraph good" is not a function you can write.

Some of it is, though. *Is the revenue number correct.* *Is it cited.* *Does the cited page actually contain that figure.* *Are there other documents in the corpus that should have been cited and weren't.* Those are functions you can write. They're boring. They're also the load-bearing ones.

The rest: is the explanation well-connected, does the answer actually address the question, did we wander off into speculation the user didn't ask for, are we emitting jargon nobody outside the SEC cares about[^3]. Those aren't expressible as code. They require judgment. They look like the kind of thing only a human can grade.

For a while, that's what we did. It didn't scale.

#### Double-entry, applied

The trick of double-entry bookkeeping isn't that the numbers are right. It's that wrongness can't hide. Every transaction is recorded twice, in two independent ledgers, and the two have to agree. If they don't, you know something is wrong before you know what.

Our eval system is double-entry. Every output runs through two independent paths, and the two have to agree.

The first path is **hard checks**: deterministic code asking deterministic questions. Does the spreadsheet contain the right numbers, extracted formatting-agnostically and matched against a known-correct fixture using normalization and stable matching, so a layout tweak doesn't blow up the comparison? Are the load-bearing figures present at all? Do the citations resolve to documents that actually contain the claimed values? Are there documents in the corpus we *should* have cited and didn't? This is code. It's not opinionated. It either passes or it fails.

The second path is **soft checks**: an LLM grading another LLM's output. The recursion is the obvious objection, and it would be a strong one if we used soft checks to grade the numbers. We don't. Soft checks grade things code can't see: is the prose actually addressing the question the user asked, are the steps logically connected, does the response stay inside the scope the user defined, is the tone professional, is the model leaking jargon the user shouldn't have to learn. Tone and relevance are exactly the things LLMs are good at evaluating. Numbers are exactly the things they're bad at evaluating. We assign each layer the job it's actually competent at.

That's the same principle the product is built on, one floor up. Code handles the data. AI handles the language. At runtime, and at test time.

When both paths agree, we have something close to certainty. When they disagree, we have a finding. Most of the value is in the disagreements.

There's a third leg to the stool, which the previous paragraphs have been quietly assuming: ground truth itself. Both paths are checking work against fixtures, and the fixtures don't build themselves: domain experts assemble them, case by case. The interesting wrinkle is that the relationship runs in both directions. Experts build the fixtures, and the system, in turn, flags back to them when the world has moved underneath those fixtures. Restatements, amended filings, numbers that quietly stop being canonical. The next story is one of those.

#### A representative disagreement

A real one, lightly anonymized.

One of the companies we use for our deeper internal evaluations changed an accounting standard mid-year and restated several years of prior figures to match. The latest version of a long-running report we generated picked up the new filing and appended its column, exactly as designed. The earlier columns were the old, pre-restatement numbers. On the surface, the report looked clean: every cell traced to a real filing, every citation resolved, every check at the level of an individual claim passed.

The hard checks flagged it anyway. The eval had ingested both the original and the restated filings, and the cross-document consistency check noticed that we had two different revenue figures for the same fiscal year coming from the same issuer. The report didn't contradict any individual source. It contradicted the universe of sources, taken together.

The flag did two things at once. It kept the report from going out, and it told the analyst who maintains that issuer's fixtures that there was a decision to make: restate the historical column to match the new standard, or preserve the original figures as a record of what was known at the time. Neither answer is automatic. Both need a human.

This is the class of failure no per-cell test would catch and no model is reliably going to surface on its own, because each individual claim is grounded. The error lives between the claims, in the implicit assumption that they belong in the same row.

#### Making evals load-bearing

A passing test that nobody ever reads is the same as no test. A lot of the work in building an eval system is the unglamorous part: making sure the results show up where the work is happening.

Ours emit JUnit XML, which means CI tooling treats them like any other test suite: failures block merges, regressions surface in the same place ordinary flakiness does. They integrate with our internal debugger so when a check fails, an engineer can step backward through the run and inspect the model's intermediate states. And every run generates a portable report: a self-contained artifact you can attach to a ticket, send to a reviewer, or archive against a release. Evals that live in a separate dashboard nobody opens are evals that don't exist.

#### What this buys

Two things, mostly.

The first is that we can change models without holding our breath. When a new frontier model lands, the question isn't "does it feel better" (a question with no good answer) but "does the suite get worse." If it doesn't, we ship the upgrade. If it does, we know exactly where, and we can fix the scaffolding before our users see it. That's how we've moved across model generations without any of our customers noticing, except that things got faster.

The second is that we can refactor with the same confidence. Large changes to our agent architecture used to be terrifying. Now they're routine, which doesn't mean they're safe by default. It means we have a reliable way of finding out whether they are.

The yardstick problem isn't fully solved. You don't solve probability; you build infrastructure around it. But the difference between a system you can measure and one you can't is the difference between an engineering discipline and an art form. We are building a product that has to stand up in front of regulators, auditors, and MDs about to walk into a board meeting. Art form isn't an option.

If this is the kind of problem you want to work on, [we're hiring](https://kepler.ai/careers/).

---

[^1]: Temperature can be turned down. In practice it doesn't go to zero, and even if it did, plenty of the model's run-to-run variability comes from sources upstream of sampling.

[^2]: The [Trust post](https://kepler.ai/blog/2026/02/10/trust-in-the-age-of-ai/) has a simple example: Netflix's November 2025 stock split was not within the knowledge boundary. In our testing, the smarter the model the more steering/prompting it required to not just "remember" the stock price/count.

[^3]: XBRL is the SEC's structured-data format for financial filings. We use it internally because it's the most reliable way to pull numbers out of US filings. We don't use it in user-facing copy. The model occasionally needs reminding.[^4]

[^4]: Yes, our own website mentions XBRL. The website is talking to a different audience than the product is.

---

### Eagerness solves most problems. Judgement solves the ones we work on.

https://kepler.ai/blog/2026/05/18/eagerness-vs-judgement/ · 2026-05-18 · Eddie Hammond

#### Sunday scaries

Every analyst remembers the first big mistake they made with a model. Mine nearly killed a deal.

When I was 21 and six months out of college, I owned subscription analytics at the consumer startup I joined as my first job. We were raising a round and wanted to show the strength of our retention numbers in the deck. The work landed on my desk. I had no experience with fundraising or with subscription retention modeling at the depth the deck required, just a mechanical engineering degree and six months of on-the-job pattern matching. None of this was unusual. At a small growing startup, lots of new terrain and a lot of green analysts learning by doing. The deal you make as a new grad is straightforward: throw eagerness at the problem, learn fast, ship.

So I did. I sprinted. First drafts were weak, I revised them, my bosses pushed back, I revised again. Deadlines closed in. Long nights were fueled by Loacker Quadratini chocolate wafers. Eventually we locked the numbers and shipped the deck. The lever worked. It had worked on every problem I'd been handed up to that point, because the stakes were usually low and the decisions reversible.

Then on Sunday morning, 7am, an email from the lead investor: "Can you explain why the numbers on slide 7 don't match what we discussed before?" I had defined retention in a way that misrepresented our cohorts relative to the version they'd seen in a prior conversation. The metric was new and unfamiliar, which meant I had no intuition to sense-check it against. A more experienced eye would have caught it in five minutes. That panicked Sunday I focused on finding it, fixing it, and writing the explanation. The deal didn't die, but the lever had been shaken. When the stakes rose, eagerness stopped being enough.

#### Where the model breaks

Four weeks ago I joined Kepler. The shape of the work looked familiar at first. Eight people, a lot of ground to cover, customers waiting, ship dates that matter. We work long hours. We push hard. That part is the same as every startup I've been part of and I assumed the rest of the lever would carry over too.

It didn't take long to see why it wouldn't.

In my first weeks I sat in on some engineering reviews discussing how to extend our spreadsheet building functionalities, a series of workflows available for our finance users. The obvious place to start was with skills, a set of files that directed the model to run a workflow. A quick afternoon MVP showed some initial progress and we discussed the next steps. The immediate quick win was to keep iterating on the prompts. That's what most teams would do. But it's also what most teams would lose weeks doing before realizing the path was a dead end.

This path would have a hidden flaw in it, unobvious at first. LLMs are built on probability, designed and trained for intent parsing. This step in the workflow required translating intent into process and then executing this process on a regular system, Excel, in a predictable way, so that each time the user ran it the process would repeat exactly: a deterministic outcome. Within the first 10 minutes of the team's discussion one of our engineers immediately flagged this predicament. Forcing this structured behavior on top of LLMs, no matter how much we tuned the prompting, would always be a losing fight.

My previous six years had presented regular small unknowns: new feature ideas, changing behaviors to understand, bugs and initiatives to prioritize. The solution was clear. You picked a route, you ran at it, you learned what worked. It was an approach we encouraged and taught, take an intelligent person with energy and throw them at a problem until it cracks. The problems Kepler tackles aren't like that. They have many possible routes and most lead to dead ends. Eagerness will get you down one of those routes and stuck there. It will not get you to the right one, not fast enough.

That's the shift. Different problems. The work we tackle at Kepler doesn't reward willingness to try. It rewards knowing where to start. The lever had changed.

#### Why judgement becomes critical

The problems Kepler builds for don't yield to trial and error. They are correctness problems, not speed problems, and they sit on top of AI that doesn't behave like traditional engineering. AI is non-deterministic. The same prompt can produce different outputs. A small change in one place can have unpredictable downstream effects, fixing one case while breaking three others. The traditional engineering loop of "try something, see if it breaks, fix it" doesn't survive that. Building deterministic outputs on top of probabilistic models takes more than effort. It requires thought and experience about how these systems actually work.

Take traceability, the thing every Kepler answer is built on. Every number a customer sees has to click through to its source. Every formula has to be explicit. Every conclusion has to reveal its reasoning. This isn't a feature we layered on top. It's the spine of the architecture. Get the spine wrong and nothing downstream can be made right. Get the spine right and the rest of the product compounds.

Or take the semantic layer, the thing that maps natural language to precise data definitions. When a user asks "what was their revenue last quarter," there are usually four or five things they could mean: as-reported revenue, organic revenue, currency-adjusted, the trailing twelve-month derivative. The semantic layer has to know which one to compute and why. If we make the wrong definitional call now, it doesn't fail loudly. It fails quietly, in numbers that look right but mean the wrong thing, in answers a customer trusts and shouldn't.

The same shape repeats across the work. Agent reliability where the same question has to produce the same answer twice. Data lineage where every cell traces to a tagged origin. These are all categories where you can ship something that works in the demo and breaks in the long tail. The cost of getting it wrong isn't a few wasted hours. It's months of unwinding architecture and customer trust you don't get back.

You don't solve this class of problem by trying harder. You solve it by recognizing, at the moment of decision, which route avoids the traps. That recognition isn't just about being smart. It's pattern recognition you can only get from having seen this shape of problem fail before. Junior engineers can be brilliant and hungry. They have not yet seen the failure modes. Senior engineers have, and they avoid them.

Judgement is the lever because the problem class doesn't reward anything else.

#### How that's changed our operating model

This shifts how we hire, how we work, and who we build the team around.

We hire experienced engineers and operators. People who have already shipped systems at scale, made the mistakes, watched the abstractions fail, and learned which routes are the dead ends. Between us, two PhDs, more than five decades of Palantir engineering, time at Meta and Lincoln Lab, several scaled startups and more. Pattern recognition transfers across domains, but you have to have built up patterns first.

We hire people who've seen the AI shift from both sides. Engineers who built systems before LLMs were tools you could lean on, and then learned how to embrace them to move faster. Our work demands both. Without the pre-AI engineering experience, you cargo-cult LLM behavior into places it doesn't belong. Without the AI fluency, you over-build on top of capabilities the models already have. We need both perspectives in the room when decisions get made.

Seniority doesn't win arguments. Pattern recognition does, and it travels in every direction. A less experienced engineer who's seen something the room hasn't can override our CTO, and does. The bar is "have you seen this shape of problem before?" not "what's on your resume?" Our operating principles say this out loud: authority comes from initiative, not titles.

You do not want this if you are early in your career. The eagerness lever works for most problems, and you should go find one of those problems. Throw yourself at it, ship, learn, repeat. That's the right move for the right phase. Come back when the lever changes for you.

If you've felt the lever change already, you'd recognize Kepler within a week. The problems are different. The room is different. The work rewards the thing you've spent your career building.

Eagerness solves most problems. Judgement solves the ones we work on.

---

*If the lever has changed for you, [we're hiring](https://kepler.ai/careers/).*

---

### FDEs in the Dark

https://kepler.ai/blog/2026/04/23/fdes-in-the-dark/ · 2026-04-23 · Vinoo Ganesh

Many years ago, I had the chance to lead Project Frontline at Palantir, a program that sent over 250 software engineers into live customer deployments to become Forward Deployed Engineers. Those engineers are now at OpenAI, Anduril, xAI, and dozens of companies building important things.

I devoted much of my career to this model. But I've been thinking lately about where it breaks, and why.

#### The original problem

The FDE emerged from a specific frustration. For decades, enterprise software followed the same pattern: build the product, close the deal, hand it off, hope for the best. What customers usually got was shelfware, expensive software that never quite fit and eventually got abandoned. The FDE was a correction. Instead of throwing software over the wall, you embedded an engineer inside the customer's environment. They learned the workflows, owned the failures, built the feedback loop that product teams never had.

At Palantir, the best FDEs became indistinguishable from the customer's own team. They weren't there to manage a relationship, but to make the thing actually work.

#### AI made deployment harder, not easier

You can't hand an LLM to a compliance team and walk away. So every serious AI company started hiring FDEs. Made sense. The role was built for exactly this kind of complexity.

Except it wasn't.

**What the role was built for:**

- Software failed in ways that were diagnosable: a bad pipeline, a misconfigured integration, a wrong assumption about how data would arrive
- Trust was relational; a person in the room with real accountability was part of what got purchased
- The feedback loop between builders and users was broken; FDEs closed it

**What's different now:**

- The failure modes are probabilistic, not deterministic. You can't trace a wrong answer the way you'd trace a broken pipeline
- An FDE can watch where outputs fail and iterate. They still can't tell you *why* the model was wrong on a specific query
- Nobody has figured out how to assign accountability when the system can't explain its own reasoning

#### FDEs in the dark

At Palantir, when something broke, the FDE could pull the logs, find the failure, and explain it. That explanation was part of the value. Not just fixing the problem, but being able to say *why* it happened and what you'd changed. That's what built trust over time. The customer saw you diagnose it. They watched you close the loop. They renewed.

That loop is broken in most AI deployments right now. The FDE is in the room, but the room is darker. They're accountable for outcomes they can't fully audit, explaining decisions the system can't articulate.

The role is getting more important and harder to do well at the same time. Someone still needs to own what happens when the product meets reality. But the old debugging toolkit doesn't work. You can watch where outputs fail. You can iterate on prompts. You cannot trace a wrong answer the way you'd trace a bad pipeline.

An FDE without traceability is just another person in the room who can't find the right answer.

---

### How Parallel Helps Kepler Build AI That Finance Professionals Can Actually Trust

https://kepler.ai/blog/2026/03/17/how-parallel-helps-kepler-build-trustworthy-ai-for-finance/ · 2026-03-17 · Vinoo Ganesh

*This post was originally published on [Parallel's blog](https://parallel.ai/blog/case-study-kepler).*

---

Kepler is building AI for work where the answer can't just be plausible — it has to be right.

Our first product, [Kepler for Finance](https://kepler.ai/finance/), helps investment professionals analyze public companies with institutional depth and AI speed. Analysts ask complex questions in natural language and receive answers backed by financial filings, computed metrics, and citations down to the page and line item.

Achieving that level of reliability requires a different architecture from most AI systems. Kepler integrates [Parallel's Search API](https://docs.parallel.ai/search/search-quickstart) as the discovery layer at the top of its analytical pipeline, combining AI's ability to understand open-ended questions with deterministic infrastructure that guarantees accuracy and auditability on the back end.

#### Key impact

- **Landscape discovery in minutes:** Preliminary research that once took analysts days now runs as an automated pipeline step.
- **Expanded product capability:** Kepler now supports competitive landscape and sector-level analysis, not just single-company research.
- **Global coverage:** Discovery across private companies, international players, and niche sectors beyond curated databases.
- **Fully automated workflows:** Parallel search results feed directly into Kepler's deterministic pipeline without manual extraction.

#### In finance, reliability is architectural

Language models are excellent at interpreting questions, understanding context, and structuring answers. They're far less reliable at retrieving precise data or producing the same answer twice. In many applications, that tradeoff is acceptable. In finance, it isn't. A wrong number can mean a blown deal, a compliance issue, or reputational damage that lasts years.

We built the platform around that constraint. The architecture enforces a strict separation between two layers: an AI layer that interprets questions and structures answers, and a deterministic layer that retrieves financial data, computes metrics, and generates citations tracing every number to its source. The two communicate through structured interfaces, but they never blend.

Today, Kepler for Finance covers 10M+ SEC filings, 14K+ companies, and 27 global markets. But even this architecture has a gap at the very top of the funnel.

#### Every analysis starts with discovery, and that requires the open web

Most financial analysis doesn't start with a known list of companies. An analyst working on a deal typically starts with a question:

- What does the competitive landscape look like around this company?
- Which international players matter that a US coverage list might miss?
- Which upstream suppliers could influence risk?

There's no filing to retrieve yet — the analyst first has to determine what the analysis should even cover. Traditionally, that means scanning industry reports, asking colleagues, and searching the web before the real work begins. It's slow, inconsistent, and impossible to scale.

Discovery is the only place in Kepler's architecture where the system permits probabilistic outputs. That makes the quality bar unusually high: if discovery surfaces the wrong companies, the entire downstream pipeline operates on incomplete context.

#### Parallel's Search API met the bar: relevant, broad, and built for machines

We evaluated discovery solutions across three requirements:

- **Relevance:** Discovery has to be accurate enough that the downstream pipeline is always pointed at the right material.
- **Breadth of index:** Our customers increasingly work across areas curated datasets struggle to cover — private companies, international competitors, niche industry segments. Parallel's coverage across the open web lets Kepler discover entities well beyond traditional financial databases.
- **Programmatic design:** Most search products are designed for humans. Kepler needed structured outputs that route directly into its pipeline without manual extraction.

> "We built Kepler to be audit-ready at every step. That standard applies to discovery too. Parallel's accuracy and coverage are what made it the only search API we trusted in that role."
>
> — Vinoo Ganesh, CEO, Kepler

When an analyst asks a landscape-level question, Parallel performs entity discovery using real-time information from the open web. Those results flow directly into Kepler's deterministic pipeline. From that handoff forward, no probabilistic system touches the data. Parallel identifies who matters. Kepler determines what the data says about them.

#### What this unlocked

Before Parallel, Kepler was a research tool that needed to be provided an explicit list of companies — powerful, but limited to situations where analysts already knew which companies to analyze.

- **Competitive landscape analysis.** Analysts can now start with broad questions like "What does the competitive landscape look like in this sector?" Parallel identifies the relevant companies; Kepler analyzes them.
- **Supply chain and sector mapping.** For an analyst researching EV battery manufacturers, the most relevant upstream suppliers — cathode material producers across South Korea or China — often don't appear clearly in US filings. Parallel surfaces these entities so Kepler's pipeline can incorporate them.
- **Comp set construction in unfamiliar sectors.** Investment professionals are frequently staffed on deals outside their primary coverage. Parallel enables Kepler to generate structured company sets dynamically, helping analysts understand the ecosystem around a target much faster.

#### The architecture scales beyond finance

Kepler started in finance, but the architecture is domain-agnostic. Legal research, regulatory compliance, healthcare analysis, procurement intelligence — anywhere professionals need defensible decisions from verified information, the same problems exist. Discovery at the top of the funnel. Verifiability at every step downstream.

We're partnering with Parallel to bring this architecture to every domain where auditability is essential.

---

### The Context Wall

https://kepler.ai/blog/2026/03/05/the-context-wall/ · 2026-03-05 · Sara Kromwijk

**tl;dr:** We're building a grounded, source-cited reasoning tool. The naive approach (one long chat thread) hits four walls in sequence: latency, cost, prompt-following degradation, and then a hard context limit. Solving that forced us to rethink what a "conversation" actually is. Turns out it's just a tree, and a surprisingly malleable one at that. We're building AI that proves it's right. [We're hiring.](https://kepler.ai/careers/)

---

When we started building Kepler, the core promise was simple: every claim the product makes should be traceable to a source. Not "Nvidia is profitable" but "Nvidia is profitable, per this line in this SEC filing." The difference sounds subtle. Technically, it's the difference between a product that earns trust and one that quietly erodes it.

The natural way to build that is a linear chat with smarter prompting. Plant the seed, tend it carefully, and trust it to grow straight. This works fine in demos. It falls apart in production.

The first thing you notice is latency. Spreadsheets are central to what our users do. They're not a nice-to-have, they're the deliverable. We generate code that builds them rather than constructing them cell by cell, which is the right call for reliability and correctness. But for any analysis involving a company's full history, that pipeline routinely adds 30 to 60 seconds to a response. Sometimes more. Users noticed immediately.[^1]

You can reason about why: bigger context, more tokens, more to process before the first line of output. But knowing the reason doesn't make it hurt less when you're watching a spinner.

The second thing you notice is cost. Longer contexts mean more tokens processed on every single call, including all the previous turns you're re-sending. You start doing the math and it doesn't look good.

Both of those are, in principle, tractable. Latency and cost are engineering problems. You can throw compute at them, optimize prompts, cache aggressively. So you do.

What you can't throw compute at is the third thing: the model starts drifting. You've given it careful instructions about how to cite sources, how to ground its claims, when to say it doesn't know. But as the context grows, those instructions get diluted.

Early in a conversation, the model will flatly refuse to speculate. Push it for a view on where a stock is heading and it won't engage, exactly as instructed.[^2] By the time you're approaching 200k tokens, the model capitulates. In between, there's a slow gradient: it starts padding citations with "common sense" reasoning, filling gaps with things it simply knows rather than things it can point to. The instructions are still there in the context. They're just losing the argument.

For a product whose entire value proposition is trustworthy, sourced reasoning, this is not a performance regression. It's an existential one.

And then you hit the wall. Context limits are finite. At some point there are no more workarounds. You've simply run out of room.

---

#### What the wall teaches you

When you're forced to redesign around a hard constraint, you end up thinking more carefully about what you actually needed in the first place.

The linear chat model carries an implicit assumption: that the model needs to hold everything in one place, in one context, all at once. Every prior turn, every retrieved document, every tool result: all of it present, all of the time.

But that's not actually how good reasoning works. A skilled analyst working on a complex report doesn't hold every source document fully in mind simultaneously. They work in focused bursts, pass summaries to themselves and colleagues, keep the central argument clear while the supporting detail lives elsewhere. The full context is accessible when needed, but not all active at once.

LLMs are, at the level of the computation, surprisingly flexible. Given a sequence of tokens, predict the next one. That's it. Which means the shape of "a conversation" is a design choice, not a constraint. Nothing says it has to be a single linear thread. It can branch. It can fork. It can grow.

---

#### Forking: parallel work from a shared root

The first thing this unlocked for us was forking.

Consider a task like building a report with multiple sections, each one analyzing a different aspect of the same company. The naive approach runs these sequentially, one after another, each carrying the full weight of everything that came before. It's slow, expensive, and by the time you're on section three, the model's context is already congested.

But all three sections share a common starting point: the same source documents, the same initial analysis, the same instructions. That shared prefix can be cached. And from that cached point, you can branch: spawn multiple completions in parallel, each working on its own section, each paying only for the tokens it generates beyond the fork point.

The result is faster, cheaper, and more reliable, because each branch is working in a cleaner context, closer to the instructions that matter, without the noise of every other branch's work.

---

#### Communication: keeping the primary context clear

Forking handles parallel work off a common base. The harder problem is what happens when agents need to talk to each other or share state.

The obvious approach is to merge contexts. When agent B returns from a research task, dump everything it found into agent A's thread state. This recreates exactly the problem you were previously trying to solve: one long context, all the noise, degrading prompt-following, escalating cost.

What works better is treating inter-agent communication the way a good team treats it: not full context dumps, but structured summaries. Agent A sends B a specific question. B does its work, potentially running its own sub-tasks and accumulating its own context, then returns the relevant findings compressed. If A needs more, it asks. B's full working context never floods A's window.

This keeps the primary reasoning thread clean. The model doing the high-level synthesis isn't distracted by the raw details of every retrieval task that fed into it. Of course, those details are accessible: B still has them, A can ask follow-up questions, but they're not actively consuming context unless they're needed.

We know what happens when they are. That's how we got here. The Context Wall is unforgiving.

---

#### What this means for the product

These aren't abstract architectural improvements. They're what makes our core promise achievable.

When the context is clean and well-structured, the model follows its sourcing instructions. When the model follows its sourcing instructions, every claim gets traced to a document. When every claim gets traced to a document, the product does what it said it would do.

The Context Wall turned out to be useful. It forced us to stop treating conversations as sacred linear transcripts and start treating them as something more malleable: data structures to be designed, shaped, and managed. Threads that can be forked, agents that communicate through compression rather than flooding, histories that can be edited when the scaffolding has served its purpose.

The chat interface was a reasonable starting point for the industry. For what we're building, it's a constraint we had to think our way out of.

If this is the kind of problem you want to work on, [we're hiring.](https://kepler.ai/careers/)

---

[^1]: There's something funny about this. A user will happily spend three days building a spreadsheet by hand, then grow visibly impatient when the computer takes 45 seconds to do the same thing. Expectations don't scale with capability — they invert.

[^2]: This is a simplification. A closer example: a user is extracting MD&A (Management Discussion & Analysis) from a filing and asking about battery production schedules. If the document doesn't cover it, we should say so and not fill the gap with things we happen to know. That discipline is what degrades as the context grows.

---

### Equity Research in the Age of AI: What Actually Needs to Change

https://kepler.ai/blog/2026/02/27/equity-research-in-the-age-of-ai/ · 2026-02-27 · Luca Daniele Vailati

#### The Reality of the Job: Precision Before Insight

Equity research is often portrayed as bold stock calls and differentiated views. In reality, it is discipline built on precision. Most of my day is spent maintaining complex, multi-tab financial models, reconciling numbers across 10-Ks, 10-Qs, earnings releases, and transcripts, and ensuring that every published figure ties exactly to source disclosures. When you cover 15–20 companies simultaneously, small inconsistencies compound quickly. Segment definitions shift, non-GAAP metrics change, backlog calculations evolve, and management subtly reframes guidance language. Before you can form a differentiated view, you need absolute control over the numbers. I've seen firsthand what happens when that control slips. In one instance early in my career, a consensus data pull did not fully reflect a segment reclassification buried in a filing footnote. The headline growth rate looked fine until we reconciled it manually and realized the comparison was not apples-to-apples. Had that gone into a client-facing note, it would have undermined credibility immediately. Insight is layered on top of infrastructure. Without rigorous numerical accuracy and documentation discipline, no thesis survives scrutiny.

#### Where Current Tools Help and Where They Fail

Traditional platforms like Bloomberg, FactSet, and CapIQ are indispensable for data retrieval and consensus tracking, but they are not foolproof. Data fields do not always reconcile perfectly across systems. Adjustments vary. Segment breakdowns are often standardized in ways that obscure company-specific nuances. Meanwhile, general-purpose AI tools are impressive at summarizing text, yet unreliable with numbers. They infer missing data, approximate figures, and present outputs confidently even when underlying information is incomplete. In equity research, that is a critical flaw. If I cannot trace a number to the exact page and line of a filing, I cannot publish it. I once tested a general AI tool on a company's backlog disclosure. It confidently calculated a growth rate using two figures from different reporting scopes, one included FX adjustments, the other did not. The output looked polished and convincing. It was also wrong. Detecting that required manually going back to the filing and reconstructing the calculation step by step. The standard is not "likely correct." It is "verifiably correct." Current tools may reduce search time, but they do not eliminate verification work. The burden of validation still sits entirely on the analyst and in many cases, that verification workload ends up being heavier than doing everything the traditional way.

#### What AI Can Realistically Improve in the Next Few Years

AI does not need to replace judgment to be transformative. It needs to remove operational drag. Equity research is full of recurring but structured tasks: updating models after earnings, reconciling guidance changes, tracking KPI definitions over time, building preview and recap templates, comparing management language quarter over quarter. These workflows follow patterns, yet require precision every time. A well-designed AI system could extract verified numbers directly from filings, calculate changes transparently, and flag inconsistencies automatically. It could highlight where management adjusted wording around demand, margins, or backlog, and show the exact textual comparison. Importantly, it must pair language modeling with deterministic data extraction and formula transparency. Automation is valuable only when auditability is built in.

#### The Importance of Personalization and Coverage Adaptation

Equity research is not standardized across sectors or even across teams within the same bank. An Industrials team may prioritize backlog conversion, engineering capacity, and book-to-bill trends. A telecom team tracks churn, ARPU, and subscriber additions. A biotech team focuses on trial phases and regulatory timelines. Even formatting conventions, sensitivity tables, and modeling architectures vary significantly. A generic AI overlay cannot meaningfully support this complexity. I have worked on teams where the internal model structure itself was part of the intellectual edge, specific tabs built to track long-cycle revenue conversion, or custom bridges to understand margin inflection. A generic AI overlay that does not understand this structure would create friction rather than value. For AI to be useful, it must adapt to specific coverage universes and internal workflows. It should learn which KPIs matter for a given team, integrate into the existing model architecture, and align with established note formats. The goal is not to impose uniformity, but to enhance each team's existing system.

#### What "Good" Looks Like: Trust as the Core Product

Ultimately, the success of AI in equity research will hinge on trust. A useful platform would guarantee numerical accuracy, provide full traceability to source documents, integrate seamlessly into financial models, and adapt to team-specific workflows. It would function as a consistency auditor, a verified data engine, and a workflow accelerator, not as an autonomous stock picker. It should be conservative when data is incomplete and explicit when assumptions are made. In this profession, credibility compounds over years and can erode in seconds. Analysts will only adopt AI deeply if they are confident that every number can be defended under scrutiny. The future is not about flashy output or faster summaries; it is about building systems that make precision scalable. In equity research, accuracy is the product. Any AI platform that understands that will earn its place.

---

### Context Is the Easy Part

https://kepler.ai/blog/2026/02/13/context-is-the-easy-part/ · 2026-02-13 · Vinoo Ganesh

Everyone's talking about context engineering right now, but most of the conversation is focused on the wrong thing. Read the blog posts, the guides, the thought leadership. They're all asking the same questions: What should I include in the context window? How do I manage tokens efficiently? How do I curate what the model sees?

These are valid questions. They're also the easy part.

The hard part isn't deciding what context to include. It's building systems that deliver that context reliably, with provenance, at scale, every single time. That's not a context problem. That's an engineering problem. And engineering means something specific.

I spent fifteen years building data infrastructure at Palantir and Citadel, working on defense and intelligence systems where wrong answers weren't acceptable. Here's what I learned: knowing what data you need is trivial. Everyone knows what data they need. The hard part is building systems that deliver it validated, traceable, reproducible, and on demand.

The data world spent two decades learning this lesson. You don't solve data problems by choosing the right data. You solve them by building the infrastructure that makes data trustworthy. Context is the same problem wearing different clothes.

Watch how people approach context engineering today. They're selecting documents. Tuning retrieval parameters. Adjusting chunk sizes. Experimenting with what to include and what to leave out. Managing memory hierarchies. Optimizing token usage. This is prompt engineering with more inputs. It's not engineering.

Engineering means provenance: where did this context come from, and can I trace every piece back to its source? If the output is wrong, can I figure out which input caused it?

Engineering means versioning: the context I retrieved yesterday and the context I retrieve today, are they the same, and if not, why? Can I reproduce last week's answer?

Engineering means validation: how do I know the context is accurate before it reaches the model? What checks exist, and what happens when something fails?

Engineering means determinism: same query, same context, every time. Not mostly the same, but exactly the same.

Engineering means observability: when context retrieval breaks, how do I know, how do I debug it, and how do I fix it without guessing?

Most context engineering today has none of this. It's artisanal, manual, and fragile. It works in demos and falls apart in production.

The failure mode is predictable. Someone builds a system that retrieves context and generates answers. It works well enough in testing, so they ship it. Then the context changes. A document gets updated. A source goes stale. A retrieval pipeline silently returns different results. The model keeps generating answers with the same confidence, but now the answers are wrong. Nobody notices until a customer does.

This is the same failure mode the data world lived through. Dashboards that showed numbers nobody could trace. Reports that changed when you refreshed the page. Metrics that meant different things to different teams. We solved it by building infrastructure: pipelines with lineage, transformations with tests, data contracts, observability. The unsexy plumbing that makes data trustworthy. Context needs the same infrastructure, and almost nobody is building it.

The current generation of AI tools is powerful but fragile in ways that aren't obvious. They work until they don't. And when they break, there's no way to diagnose why. The teams treating context engineering as an optimization problem will keep hitting this wall. They'll tune retrieval, adjust chunk sizes, swap embedding models, and still get inconsistent results they can't explain. The teams treating it as an engineering problem will build systems that are auditable, reproducible, and debuggable. They'll know where their context comes from. They'll know when it changes. They'll be able to defend their outputs. One approach scales. The other doesn't.

The term context engineering is new. The problem isn't. It's the same problem the data world faced: how do you build systems that deliver the right information, reliably, at scale? The answer was never "choose the right data." The answer was always "build the infrastructure that makes data trustworthy."

Context is data by another name. The lessons are the same. The question is whether we're going to spend another decade relearning them.

---

*Read more: [Introducing Kepler](https://kepler.ai/blog/2026/01/30/introducing-kepler/) explains how we separate AI interpretation from deterministic execution. [Trust in the Age of AI](https://kepler.ai/blog/2026/02/10/trust-in-the-age-of-ai/) explores how forcing AI to cite sources changes the nature of the output itself.*

---

### Trust in the Age of AI

https://kepler.ai/blog/2026/02/10/trust-in-the-age-of-ai/ · 2026-02-10 · Sara Kromwijk

Trust has always been a moving target. What we trusted yesterday, like a firm handshake, a reputable letterhead, or a recommendation from a colleague, doesn't necessarily hold up today. And now, with AI systems increasingly handling knowledge work, the question of trust has become both more urgent and more complicated.

When we talk about trust in AI, we're really talking about three interrelated things: accuracy (does the output reflect reality?), security (is the system handling sensitive data responsibly?), and credulity (should we believe what it tells us?). Getting any one of these wrong can be costly. Getting all three wrong can be catastrophic.

#### The junior employee analogy

It's tempting to think of AI systems as junior employees. There's something to this comparison: both need oversight, both are expected to handle rote tasks, and both occasionally produce work that makes you wonder if they understood the assignment at all.

But the analogy only goes so far. Junior employees learn institutional knowledge over time. They pick up on context clues. They know when to ask clarifying questions. AI systems don't, at least not in the same way. They can produce remarkably confident outputs even when operating outside the bounds of what they were designed to do.

Still, there's one lesson from managing junior employees that transfers perfectly: their work needs verification. The difference is that systematic verification of human work is expensive enough that most organizations don't bother. Instead, we rely on gut feel, spot checks, and the occasional post-mortem when something goes wrong. This approach saves resources most of the time, but it also means errors compound silently until they surface as full-blown crises.

#### The documentation advantage

Here's where AI actually has an edge over human workers: it doesn't get bored.

Ask an analyst to document the source for every single cell in a spreadsheet, along with a qualitative explanation of how they arrived at each figure, and you'll get pushback. It's tedious work. It slows everything down. So we don't ask for it, and we accept the traceability trade-off.

AI systems have no such objections. They'll happily record provenance for every data point, trace every inference back to its source, and explain their reasoning in exhaustive detail. The marginal cost of documentation drops to nearly zero.

This matters more than it might seem. There's a practice in Japanese rail systems called "pointing and calling." Train conductors physically point at each signal and call out its status aloud. It feels redundant, almost theatrical. But studies have shown it reduces errors by up to 85%. The act of explicit acknowledgment forces attention and prevents the kind of autopilot mistakes that creep in during routine tasks. This has been so successful that other rail systems have now adopted the practice, for example, in the New York subway system.

The same principle applies to AI systems. Forcing a model to explicitly cite its sources and articulate its reasoning isn't just about creating an audit trail for humans. It's about making the system do the cognitive work that prevents errors in the first place. This is similar to how forcing a large language model to generate code to perform arithmetic significantly improves reliability.

#### The edge case problem

This documentation discipline becomes even more critical when you consider how AI systems fail.

Large language models are improving rapidly, but they still exhibit strange edge cases that are difficult to predict. Feed a model a transcript from an earnings call, and it might start unconsciously echoing the CEO's framing rather than analyzing it critically. Ask it to recall a specific figure, and it might produce a number it "semi-remembers," close enough to sound plausible, wrong enough to cause problems.

The challenge is that these failures often look identical to successes. The model doesn't flag uncertainty. It doesn't caveat its responses. It delivers hallucinated data with the same confidence as verified facts. And testing whether a given model can reason reliably about arbitrary inputs is genuinely hard. Even a test harness doesn’t help much in building confidence when the behavior is highly unstable given changing inputs.

To give a concrete example: Netflix announced a 10:1 stock split in October 2025, effective November. This creates a problem. LLMs lag on current data, so they have a 'gut feel' for share counts that's now wildly off. Left unchecked, they'll default to the outdated numbers. And even after learning the new figure, historical queries will present the same problem in reverse. A junior analyst might make that mistake once. LLMs will repeat it on every query.

This is why you have to force the AI to actually do the work: to ground every claim in verifiable sources, to show its reasoning, to make its assumptions explicit. Not because humans will check every single output (they won't), but because the discipline itself changes the nature of the output.

#### Building systems that earn trust

At Kepler, this is the problem we've built our entire approach around.

We force-ground our models, requiring explicit source attribution for every claim. We double-check outputs systematically, not through spot-checks but through structured verification. We use models of different provenance, including specialized systems trained on structured data formats like XBRL, to catch the kind of systematic errors that a single model might consistently get wrong.

The goal isn't to eliminate human oversight. It's to make human oversight actually effective. When an analyst reviews AI-processed data, they should be able to see exactly where each figure came from, understand the reasoning chain that produced it, and quickly identify anything that doesn't hold up. The AI does the exhaustive documentation work that humans won't do; humans provide the judgment and contextual understanding that AI can't reliably provide.

But here's the thing: even if no human ever looks at the source citations, forcing the model to produce them still matters. The act of grounding, of requiring the system to acknowledge specific facts rather than generate plausible-sounding content, is itself a mechanism for maintaining accuracy. It's pointing and calling for the age of AI.

Trust in AI isn't something we achieve once and forget about. It's something we build through systems and processes, through verification and transparency, through acknowledging both what these tools can do and where they still fail. The organizations that figure this out will be the ones that actually capture the value AI promises. The ones that don't will learn some expensive lessons about the cost of misplaced confidence.

---

*Read more: [Introducing Kepler](https://kepler.ai/blog/2026/01/30/introducing-kepler/) describes how we built a system where AI interprets intent while deterministic code handles the numbers. [Context Is the Easy Part](https://kepler.ai/blog/2026/02/13/context-is-the-easy-part/) explains why reliable context delivery is an engineering problem, not a curation problem.*

---

### The AI Era of Finance: A Practitioner's View

https://kepler.ai/blog/2026/02/06/the-ai-era-of-finance/ · 2026-02-06 · Rui Zhang

I've always been fascinated by private equity investment. It's a combination of rigorous analysis, deep thinking, strategic acumen, and sometimes a dash of gut instinct.

A thoughtful investment thesis is never formed in isolation. It takes a village. And it all begins with something that sounds simple but is maddeningly complex and time-consuming: understanding the target company, its industry, and the key drivers across its value chain.

The common thread across all of this work is an overwhelming amount of data. Financial statements, filings, industry reports, diligence materials, expert analyses. The list goes on. The challenge is not access, but synthesis: transforming fragmented information into conclusions that are logical, defensible, and actionable, often under intense time pressure.

That reality became especially clear during my time working in a private equity deal team. Despite operating in a highly digitized world, I was often surprised by how much of the core analytical work remained stubbornly manual.

#### The unavoidable manual work

Take a seemingly straightforward task: consolidating ten years of historical and LTM income statements of a public company. In theory, it sounds trivial. In practice, it can take hours of focused effort.

While deal teams typically have access to tools like Capital IQ, FactSet, BAMSEC, and EDGAR, pulling historical financials still requires caution. A spreadsheet pulled directly from those platforms often includes discrepancies due to mapping, restatements, presentation changes, or simple extraction errors. It isn't always obvious where a specific number came from, and that lack of built-in traceability makes verification labor-intensive. Because these numbers become the foundation for every downstream analysis, accuracy is non-negotiable, and trust is hard to regain once a single data point is questioned. 

The result is a familiar routine: opening 10-Ks and 10-Qs across multiple tabs, scrolling through filings, and manually extracting and validating line items, quarter by quarter, year by year. And that's just the starting point, before repeating the process for every other financial statement critical to the analysis. 

#### Where general-purpose LLMs fall short

When large language models began to mature, I became genuinely curious about how they might change this workflow. On the surface, it felt like the perfect application. LLMs are remarkable at comprehension, summarization, and synthesis. But I quickly noticed that general-purpose models struggle to reliably ground their outputs in source documents, and in finance, being directionally correct is not enough. Small errors compound, and trust is everything.

So I asked a narrower question: if generating an accurate spreadsheet is difficult, could LLMs at least help with comprehension and targeted extraction? Investment professionals often have to review huge volumes of material to form an informed view. If AI could reliably extract a defined category of information across documents, consistently and with citations, it would be a real productivity unlock.

I tested this on a real task: reviewing ten quarterly earnings call transcripts for a public company to understand how management discussed inflation, how it impacted performance, and what it meant for margin expectations. I uploaded the transcripts into a general-purpose LLM and asked for a structured table summarizing the key inflation references and the implied rates and time periods. The result was disappointing. The model struggled to synthesize the transcripts chronologically and couldn't reliably extract context-specific references, especially when inflation came up indirectly or as part of an answer to a different question. After multiple prompt iterations, I ultimately reverted to the familiar approach: manually searching, reviewing, and annotating the transcripts line by line to ensure nothing critical was missed.

That experience is why I'm excited about tools like Kepler, where the promise isn't just speed, but trust. An AI platform that works only from sources you choose and trust, preserves numerical integrity, and makes every conclusion traceable back to its origin fundamentally changes the equation.

There are countless brilliant minds in finance working extraordinarily long hours. With the right tools, that intellectual energy can finally be directed toward the highest-value work: connecting disparate insights, identifying opportunities others miss, engaging thoughtfully with stakeholders, and building businesses that create durable value for shareholders, employees, customers, suppliers, and the communities they operate in.

---

*Read more: [Introducing Kepler](https://kepler.ai/blog/2026/01/30/introducing-kepler/) explains how we separate AI interpretation from deterministic computation. [Trust in the Age of AI](https://kepler.ai/blog/2026/02/10/trust-in-the-age-of-ai/) explores why forcing AI to show its work is itself a mechanism for maintaining accuracy.*

---

### Why I Joined Kepler

https://kepler.ai/blog/2026/02/03/why-i-joined-kepler/ · 2026-02-03 · Susannah Meyer

#### First, a bit about me

Hi! I’m Susannah, Founding Engineer at Kepler. After studying Computer Science at Stanford, I worked as a senior engineer at Facebook on big data problems, which shaped how I think about building reliable systems.

Since then, I’ve joined four seed-stage startups to build and accelerate engineering. I’ve learned what actually matters when building early-stage startups. Every career move I make is extremely intentional, and Kepler is no exception.

Most recently, I was Head of Engineering at Enigma Labs, where I built and led teams across full-stack engineering, data science, computer vision, and mobile. We scaled to over 300k users and built a unique dataset capturing anomalous activity in our skies: real data that demanded careful system design, seamless products, and strong infrastructure.

#### So why Kepler?

A few things made this an easy decision.

First, the founder. I jumped at the chance to work with Vinoo, who is rare in how they think: deeply technical, highly opinionated about quality, and grounded in real product instincts. Beyond years of experience shipping at Palantir, Vinoo has built and exited a startup. That lived experience shows up in the intention behind every decision.

Second, the stage and ownership. I joined Kepler as the first Founding Engineer. That means real ownership across product, infrastructure, and culture. Not just building features, but helping define how the company builds: the technical bar we set, the shortcuts we refuse to take, and the systems we choose to invest in.

Third, the problem itself. Kepler is tackling an unusually hard challenge: building AI systems that are fully traceable, with end-to-end provenance. No black boxes. No hand-waving. Deterministic data. We’re building agentic systems where every output can be inspected, understood, and trusted. While finance is our starting point, the underlying platform we’re designing extends far beyond it, into any industry where precision of the data matters as much as the data itself.

I joined Kepler for the people, the ownership, and the chance to work on a problem that's genuinely hard and genuinely worth solving. If that excites you too, we're hiring.

---

*Read more: In [Introducing Kepler](https://kepler.ai/blog/2026/01/30/introducing-kepler/), our CEO Vinoo shares the founding story and the architecture behind verifiable AI.*

---

### Introducing Kepler

https://kepler.ai/blog/2026/01/30/introducing-kepler/ · 2026-01-30 · Vinoo Ganesh

AI is extraordinary at reasoning. It interprets intent, synthesizes information, and generates language better than any technology in history.

But when it comes to retrieving facts and computing numbers, AI wasn't designed for that job. Ask the same question twice and you might get different answers. A generated number sounds exactly like a verified one. There's no tell.

Every major industry runs on numbers. A misread destroys a patient's diagnosis. A wrong decimal bankrupts a trade. A fabricated source torpedoes a deal. In healthcare, legal, insurance, government, the cost of a wrong number isn't a rounding error. It's a lawsuit, a missed diagnosis, a failed mission. In finance, it's millions of dollars and a career.

Right now, none of these industries can fully trust AI for the decisions that actually matter. Not because AI is bad, but because it's being asked to do things it wasn't built to do.

Over the past year, we talked to 137 financial firms. VPs, MDs, analysts, associates across private equity, hedge funds, and investment banks. Same story everywhere: everyone wants to use AI, nobody trusts it. Impressive demos that fall apart in production. Numbers that look right but aren't. Sources that don't exist.

One MD at a multi-billion dollar fund: "I can't put a number in front of a client if I can't show where it came from."

An associate at a PE firm: "I can't trust what I can't verify."

I'm an EMT. I've worked 12+ hour shifts and watched what happens when someone gets a number wrong. A decimal in the wrong place. A dosage misread. In medicine, bad data hurts people. Sometimes it kills them. Now we're entering an age where AI-generated numbers look identical to verified ones, and there's no built-in way to tell the difference.

Everyone's trying to solve hallucination by making AI smarter. More training data, better retrieval, more guardrails. These approaches reduce errors. They don't eliminate them.

We had a different idea: if the AI doesn't produce numbers, it can't get them wrong.

This isn't about limiting AI. It's about using it for what it's best at. AI is extraordinary at understanding what you're asking: parsing intent, handling ambiguity, interpreting natural language in ways that felt like science fiction five years ago. But retrieving facts and doing math are deterministic tasks, and deterministic tasks deserve deterministic tools. So we let each system do what it does best.

When you ask Kepler a question, AI interprets your intent. Then deterministic code retrieves the data and runs the calculation. The AI doesn't produce numbers. It can't get them wrong. Every figure traces to its source. Every answer is reproducible.

The AI interprets. Code executes. They never cross lanes.

I spent seven years at Palantir building data infrastructure for defense and intelligence, the kind of systems where a wrong number doesn't just cost money, it costs lives and compromises missions. Later, I became Citadel's first Head of Business Engineering. We've been building toward this, in different forms, for fifteen years. We learned the same lesson in every deployment: the magic isn't in the database. It's in the layer between the data and the user.

Our team includes senior engineers from Palantir and Citadel, engineers from Meta, Bloomberg, and Stanford, and financial experts who've built $100M+ businesses. We're backed by people who built the foundational data platforms of the last decade: Jordan Tigani (MotherDuck), Tristan Handy (dbt), Savin Goyal (Outerbounds), and investors from Pebblebed, including the founders of Facebook AI Research and OpenAI.

In 1601, Johannes Kepler inherited twenty years of astronomical observations from Tycho Brahe. The most accurate dataset of planetary motion ever assembled. For centuries, astronomers assumed planets moved in perfect circles. Elegant and wrong. Kepler had data he could trust, so he followed it where it led. The math didn't work for circles. It worked for ellipses.

That's the power of trusted data. It reveals truths that would otherwise stay hidden.

We're building the infrastructure that gives AI the same foundation - to enable everyone to build on top of a platform they can truly trust. Verified data, traceable to its source, precise enough to follow wherever it leads.

What gets discovered next is up to you.

Reach us at hi@kepler.ai

---

*Read more: [Trust in the Age of AI](https://kepler.ai/blog/2026/02/10/trust-in-the-age-of-ai/) explores how forcing AI to show its work changes the nature of the output itself. And in [Context Is the Easy Part](https://kepler.ai/blog/2026/02/13/context-is-the-easy-part/), we explain why context engineering is really an engineering problem.*

## Links

- [Website](https://kepler.ai/)
- [The Kepler Platform](https://kepler.ai/platform/)
- [Kepler for Finance](https://kepler.ai/finance/)
- [Kepler for Industry](https://kepler.ai/industry/)
- [Build on Kepler](https://kepler.ai/build/)
- [Compare](https://kepler.ai/compare/)
- [The Ontology](https://kepler.ai/ontology/)
- [Security](https://kepler.ai/security/)
- [Research](https://kepler.ai/research/)
- [Blog](https://kepler.ai/blog/)
- [FAQ](https://kepler.ai/faq/)
- [About](https://kepler.ai/about/)
- [Careers](https://kepler.ai/careers/)
- [Request Demo](https://kepler.ai/demo/)
- [System Status](https://kepler.ai/status/)
- [Trust Portal](https://trust.kepler.ai/)
- [Privacy Policy](https://kepler.ai/privacy/)
- [Contact](mailto:hi@kepler.ai)