Explore

State machine runs the plan with fixed-schema model calls

Once a plan is approved, a state machine runs it: it picks every step and records every result. When a step needs judgment, it makes one fixed-schema model call (compose an email, judge a reply, spot missing values, extract fields, verify a document); the answer comes back typed and the state machine decides what to do with it. Side effects get a lifecycle of their own: preparing, dispatching, succeeded, or — when the world doesn't answer cleanly — outcome unknown and manual review. There are no automatic retries on side effects. A chat message can approve a step or answer a question, but it can't change an already approved plan. The model steers; it never drives.

AI Engineer · Reliable, Smart Workflows for Finance, Wealth and Insurance — Karthic Rao, Perpetual

Deterministic compiler turns the graph into an execution plan or fails closed

The graph goes to a compiler that never calls a model; in 11 deterministic stages it turns the graph into an execution plan or fails closed. The compiler produces only three verdicts: valid, needs clarification, or refused. Ambiguity like 'which Harper' comes back as a question, not a guess. The compiled plan is immutable and pinned by its hash. The compiler checks the plan against a grammar: the vocabulary of what the firm is allowed to do — 42 typed action contracts across forms, documents, email, e-signature, calendar, and human steps. Each action the planner asks for must match a contract; if the planner asks for an action not in the grammar or wires one up wrong, the compiler refuses. There are about 40 ways to fail closed, from a cycle in the graph to an unsupported action.

AI Engineer · Reliable, Smart Workflows for Finance, Wealth and Insurance — Karthic Rao, Perpetual

Small typed judgments don't need frontier intelligence

Outside the planner, the judgments are small and typed (is this reply complete? does this document match? which field is which?) and don't need frontier intelligence. A fast small model (the flash tier) can handle the small typed judgments; in an illustrative run of 20 decisions, 19 went to the flash tier and one went to the frontier. Design for about 95% of model decisions in a workflow never needing a frontier model. The flash tier can run on hardware you control; only the genuinely hard cases go to a frontier model.

AI Engineer · Reliable, Smart Workflows for Finance, Wealth and Insurance — Karthic Rao, Perpetual

Treat every customer as guaranteed to churn until X, then design delivery around X

Snyder thinks of delivery post-sale as: everybody who buys is guaranteed to churn until X, in which case they are weird to churn. All delivery is about figuring out what X is and designing a bullet train so every customer gets there. Keep asking customers whether they are going to churn to find the moment they realize they cannot live without the product.

Lenny's Podcast · How to find product-market fit (but, actually) | Rob Snyder (Author, The Power of Pull)

Your perfect fit customer is the hell yes customer — find clones

Rob Snyder says your perfect fit customer is the hell yes customer — your job is just to find more who are basically clones of them.

Lenny's Podcast · How to find product-market fit (but, actually) | Rob Snyder (Author, The Power of Pull)

Once you have pull, the pitch is small and simple

Once you have pull, your pitch is quite simple — you're not trying to describe a massive product vision or your theory of the problem. When you know the prospect is trying to do X but blocked because of Y, you already have what you need: the pitch follows from their stated pull. Describe the product in a small and simple way, and when the prospect responds with 'How exactly does that work? Tell me more,' they are pulling more information out of you — that's when you know you're onto something. The 'pull' name itself is a reminder: something pulling you, like a boulder pulling you down a hill, versus wind pushing you.

None stated.

Lenny's Podcast · How to find product-market fit (but, actually) | Rob Snyder (Author, The Power of Pull)

The pull framework is simple: show to people, see if they pull

Rob Snyder says the pull framework is simple: show to people, see if they pull. Just use the pull framework: sell, see if they try to buy, and think less in that process — it will get you there.

Lenny's Podcast · How to find product-market fit (but, actually) | Rob Snyder (Author, The Power of Pull)

Pull comes from priorities, not pain points or value props

What causes someone to pull a product out of your hands is a certain kind of priority — a person stuck trying to do something — not pain points or value propositions.

Lenny's Podcast · How to find product-market fit (but, actually) | Rob Snyder (Author, The Power of Pull)

Hell yes customers are weird not to buy and weird to churn; find clones of them

What matters in a hell yes customer is that they are weird not to buy and weird to churn, and the process is mostly them pulling rather than you pushing. Once you find one, your job is just to find more who are basically clones of them.

Lenny's Podcast · How to find product-market fit (but, actually) | Rob Snyder (Author, The Power of Pull)

Pull is something a person has, not a company

A core mistake is treating pull as a company-level attribute; pull belongs to a specific individual with a project on their to-do list, even in enterprise sales.

Lenny's Podcast · How to find product-market fit (but, actually) | Rob Snyder (Author, The Power of Pull)

Your job is not to produce a hundred different case studies

Rob Snyder says your job as a founder is not to produce a hundred totally different case studies — that's not scalable or repeatable. Instead, build one case study where a customer says hell yes before they buy and after they buy, and repeat that a million times.

Lenny's Podcast · How to find product-market fit (but, actually) | Rob Snyder (Author, The Power of Pull)

Pull means the prospect has a project and it would be weird not to buy now

Snyder defines pull via the PULL acronym: P stands for project — the person has a project on their to-do list, like a job to be done. The real signal of pull is testing whether it feels weird for the prospect NOT to buy right now. Trying to convince people to want your product is very hard, if possible at all.

Lenny's Podcast · How to find product-market fit (but, actually) | Rob Snyder (Author, The Power of Pull)

It should feel weird for a prospect NOT to buy — that's the sign pull is right

With a person who has pull, not buying is the strange outcome; most people most of the time are 'fine,' so weirdness of not buying is the discriminator.

Lenny's Podcast · How to find product-market fit (but, actually) | Rob Snyder (Author, The Power of Pull)

All four PULL elements must exist at once for real pull

Rob Snyder states that all four elements of the PULL framework must be present simultaneously for real pull to exist; if any one is missing, the force isn't there. He extends this to product-market fit: you need all four at once, and if a founder is struggling with their product, it's probably because one of the four elements is missing. He also notes that if you find a project without urgency and with good-enough existing options, people will complain but won't buy.

Lenny's Podcast · How to find product-market fit (but, actually) | Rob Snyder (Author, The Power of Pull)

After finding a pull signal, verify it repeats with others in the same role

Rob Snyder recommends that after finding a pull signal, you talk to five other people in the same role to verify the pull repeats and you're not building for just one person. He notes that pulling — verifying with others — was the really important thing to make sure he wasn't just building a product for one person.

Lenny's Podcast · How to find product-market fit (but, actually) | Rob Snyder (Author, The Power of Pull)

A startup is a case study factory: repeat one hell-yes customer case infinitely

Snyder frames the startup as a system that repeats one successful customer case study infinitely: build one case where a customer says hell yes before and after buying, then repeat it a million times. This radically simplifies how a startup works and shows exactly where to focus at any point in time.

Lenny's Podcast · How to find product-market fit (but, actually) | Rob Snyder (Author, The Power of Pull)

Real pull requires the person's existing options to be not good enough

For real pull, the person must be stuck and blocked — their existing options (including doing it themselves or using a category leader) must be inadequate, otherwise they won't buy.

Lenny's Podcast · How to find product-market fit (but, actually) | Rob Snyder (Author, The Power of Pull)

Arithmetic is pushed to the compute layer, not the model layer

Kepler pushes arithmetic to the compute layer rather than the model layer. When the model is forced to do math or cannot reason through something, Kepler makes that impossible via its post-processing step. The platform becomes structurally incapable of producing hallucinated numbers even though the model itself still hallucinates.

AI Engineer · Do Not Let Models Invent Numbers - Vinoo Ganesh, Kepler

Kepler's core architecture: retrieval finds the source, code does the math, a filter strips unverifiable output

Kepler's architecture has the model cite numbers but never write them. Retrieval finds the right source, code does the math, and a post-processing filter strips unverifiable output — that is the core of the system. The math is done by predetermined, deterministic code written by humans, not by the model.

AI Engineer · Do Not Let Models Invent Numbers - Vinoo Ganesh, Kepler

Kepler verifies every citation and strips unmatched numbers

Kepler verifies every citation against its source. When a number cannot be matched to a verifiable source, it is stripped from the output rather than letting the model fill the gap from its training corpus.

AI Engineer · Do Not Let Models Invent Numbers - Vinoo Ganesh, Kepler