Kiriti Badam
Formerly Google and Kumo
Where to hear and read about Kiriti Badam1 episode or test
Lenny's PodcastWhy most AI products fail: Lessons from 50+ AI deployments at OpenAI, Google & AmazonKiriti Badam works on Codex at OpenAI and spent a decade building AI and ML infrastructure at Google and Kumo. The thing most worth learning from him is to launch AI products with low autonomy and high human control, then raise autonomy in steps as real user behavior earns trust.
Pain is the new moat.
Why most AI products fail: Lessons from 50+ AI deployments at OpenAI, Google & Amazon
Kiriti Badam: the story and the lessons
1Who Kiriti Badam is
Badam works on Codex at OpenAI after a decade in AI infrastructure. He spent ten years building AI and ML infrastructure at Google and Kumo before Codex.
His co-guest Aishwarya was an early AI researcher at Alexa and Microsoft and has published over 35 research papers.
He and Aishwarya have shipped over 50 enterprise AI products. Their deployments span Amazon, Databricks, OpenAI and Google, in both startups and large enterprises.
The advice comes from hands-on deployments, not theory. The caveat is that the staged-autonomy method rests on their own consulting experience, with no data on how much it improves outcomes or what each stage costs.
Badam calls himself an overthinker and leans on a Steve Jobs line. He cites Jobs: you can only connect the dots looking backwards.
The idea helps him keep experimenting when the best choice is unclear.
2Badam's staged approach to building AI products
Badam says AI products are unpredictable on both the input and the output. Users can phrase intent in endless ways, and LLMs react differently to small wording changes, so you cannot map a fixed path like a booking flow.
"You don't know how the user might behave with your product and you also don't know how the LLM might respond to that."
He starts AI products with low agency and high human control. In customer support, version one routes tickets, version two drafts replies for humans, and version three resolves tickets end to end, later adding refunds and feature requests.
Coding and marketing assistants follow the same ladder. Starting with a full agent makes failures impossible to tabulate, and starting small forces the team to name the problem first.
Badam treats every handover of autonomy as giving up control. The agent has to earn trust first. Autonomy can be limited by number of actions or by topic and risk.
In insurance pre-authorization, AI can approve MRIs and blood tests while invasive surgery stays with humans. A Berkeley and Databricks paper found about 74 to 75% of enterprises named reliability as their biggest problem.
He begins with routing and fixes the data problems it exposes. Routing keeps control high because humans can undo wrong routing, yet enterprise taxonomies are messy and undocumented.
One retail taxonomy put shoes, women's shoes and men's shoes at the same level, plus a node last updated in 2019. A human spots a dead node, but an agent needs that context handed to it.
Logging what humans do in the copilot stage gives free error analysis. Recording how much of the AI draft the human used or changed feeds the improvement flywheel.
The team moves from drafting to full resolution when humans mostly use the drafts as they are.
Writing an expected input and output dataset first aligns the team. Teams often discover they disagree on how the product should behave. PMs and subject matter experts supply the expected behavior.
The dataset is not comprehensive. It only gives the team a place to start.
Badam runs a continuous calibration, continuous development loop. The development half scopes the capability, curates data, sets up the app, designs evaluation metrics, deploys and runs them. The calibration half analyzes unexpected behavior and applies fixes.
The loop came from a customer support agent that was shut down under too many hot fixes. Not every error needs a new metric: a badly defined tool can simply be fixed.
He moves up a stage when calibration stops surprising the team. If a check every day or two shows no new data patterns, little information is left to gain.
Recalibrate after a model swap such as GPT-4o to GPT-5, or when users get bolder. A bank's underwriting assistant worked for about three months, then underwriters began asking what previous underwriters did in similar cases, which forced a rebuild. "It's all about minimizing surprise."
3How Badam thinks about evals and monitoring
Badam says evals and production monitoring catch different failures. Evals encode what you know must not go wrong, such as an agent that should never offer refunds. Monitoring signals show which traces to read, and important failures become new evals.
Implicit signals include a user regenerating an answer. He calls the idea that only one of the two will solve things "completely dismissible".
He wants teams to define what they mean by eval first. The word now covers expert notes, PM-written checks, LLM judges and benchmarks. A quick check of 10 must-not-fail questions already counts as an eval dataset.
One client said it ran evals but had only checked LM Arena and Artificial Analysis, which benchmark models, not the client's own data. His advice: "Don't be obsessed with prescriptions. They're going to change."
On Codex, Badam pairs core evals with A/B tests and user reactions. A coding agent runs across many integrations and tools, so evals can only guard the core. Before a model or RL change ships, the code review product is A/B tested on whether it finds the right mistakes.
Users annoyed by wrong reviews may switch the product off, and the team watches social media for problems. He rejects the idea of a concrete eval set you could bet your life on, a response to the claim that Claude Code's Boris runs no evals and goes on vibes.
4What Badam says separates teams that ship working AI
He says hands-on leaders decide whether AI adoption works. Leaders must rebuild 10 to 15 years of intuition, because adoption is almost impossible to drive bottom up. The Rackspace CEO blocked 4 to 6 a.m. daily to catch up on AI and did weekend vibe coding.
He suggests picking two or three trusted sources and bringing questions to AI experts. A leader who vibe codes a demo and assumes production is easy sets misaligned expectations.
Badam says leaders must make experts feel safe to help. Subject matter experts define ideal AI behavior, but if they fear replacement they refuse to talk.
Leaders should frame AI as a way to 10x each person's own workflow, and that tone has to come from the top.
PMs, engineers and data people should share one feedback loop. The old handoffs have broken. Each role used to optimize its own loop, and now they review agent traces together to decide how the product behaves.
He wants the right tool for each workflow step, not an agent for everything. A workflow mixes ML models, deterministic code and humans. Strong teams obsess over the workflow, not the first agent.
Being first with an agent no longer matters. Having the right flywheels to improve over time does.
Badam calls one-click agents pure marketing. Enterprise data carries tech debt such as messy taxonomies and duplicate functions like get-customer-data v1 and v2. Real ROI takes four to six months.
He prefers a team that builds a pipeline that learns over one promising instant gains.
He favors a supervisor with sub-agents over peer-to-peer agents. Splitting duties by function into agents that coordinate in a gossip-style protocol does not work with current models.
In customer support, peer-to-peer agents make it hard to control which agent replies to the customer, and guardrails would have to be moved everywhere.
Badam says persistence through the pain of learning is the moat. Successful companies in a new area learned the non-negotiables by trial and error, and that knowledge, sometimes as an eval or another product, becomes the moat.
He says about 80% of the time of so-called AI engineers and AI PMs goes to understanding workflows, customer behavior and data. As building gets cheap, design, judgment and taste matter more.
Why most AI products fail: Lessons from 50+ AI deployments at OpenAI, Google & Amazon
AI products differ from regular software because they are non-deterministic and force a trade-off between agency and control, so they should be built in stages that start with high human control. Drawn from over 50 enterprise AI deployments, the episode gives a continuous calibration, continuous development loop, advice on evals versus production monitoring, and patterns that separate teams that ship working AI from those that hot-fix failing agents.
Badam works on Codex at OpenAI after a decade in AI infrastructure. He spent ten years building AI and ML infrastructure at Google and Kumo before Codex.
His co-guest Aishwarya was an early AI researcher at Alexa and Microsoft and has published over 35 research papers.
He and Aishwarya have shipped over 50 enterprise AI products. Their deployments span Amazon, Databricks, OpenAI and Google, in both startups and large enterprises.
The advice comes from hands-on deployments, not theory. The caveat is that the staged-autonomy method rests on their own consulting experience, with no data on how much it improves outcomes or what each stage costs.
Badam calls himself an overthinker and leans on a Steve Jobs line. He cites Jobs: you can only connect the dots looking backwards.
The idea helps him keep experimenting when the best choice is unclear.
Badam says AI products are unpredictable on both the input and the output. Users can phrase intent in endless ways, and LLMs react differently to small wording changes, so you cannot map a fixed path like a booking flow.
"You don't know how the user might behave with your product and you also don't know how the LLM might respond to that."
He starts AI products with low agency and high human control. In customer support, version one routes tickets, version two drafts replies for humans, and version three resolves tickets end to end, later adding refunds and feature requests.
Coding and marketing assistants follow the same ladder. Starting with a full agent makes failures impossible to tabulate, and starting small forces the team to name the problem first.
Badam treats every handover of autonomy as giving up control. The agent has to earn trust first. Autonomy can be limited by number of actions or by topic and risk.
In insurance pre-authorization, AI can approve MRIs and blood tests while invasive surgery stays with humans. A Berkeley and Databricks paper found about 74 to 75% of enterprises named reliability as their biggest problem.
He begins with routing and fixes the data problems it exposes. Routing keeps control high because humans can undo wrong routing, yet enterprise taxonomies are messy and undocumented.
One retail taxonomy put shoes, women's shoes and men's shoes at the same level, plus a node last updated in 2019. A human spots a dead node, but an agent needs that context handed to it.
Logging what humans do in the copilot stage gives free error analysis. Recording how much of the AI draft the human used or changed feeds the improvement flywheel.
The team moves from drafting to full resolution when humans mostly use the drafts as they are.
Writing an expected input and output dataset first aligns the team. Teams often discover they disagree on how the product should behave. PMs and subject matter experts supply the expected behavior.
The dataset is not comprehensive. It only gives the team a place to start.
Badam runs a continuous calibration, continuous development loop. The development half scopes the capability, curates data, sets up the app, designs evaluation metrics, deploys and runs them. The calibration half analyzes unexpected behavior and applies fixes.
The loop came from a customer support agent that was shut down under too many hot fixes. Not every error needs a new metric: a badly defined tool can simply be fixed.
He moves up a stage when calibration stops surprising the team. If a check every day or two shows no new data patterns, little information is left to gain.
Recalibrate after a model swap such as GPT-4o to GPT-5, or when users get bolder. A bank's underwriting assistant worked for about three months, then underwriters began asking what previous underwriters did in similar cases, which forced a rebuild. "It's all about minimizing surprise."
Badam says evals and production monitoring catch different failures. Evals encode what you know must not go wrong, such as an agent that should never offer refunds. Monitoring signals show which traces to read, and important failures become new evals.
Implicit signals include a user regenerating an answer. He calls the idea that only one of the two will solve things "completely dismissible".
He wants teams to define what they mean by eval first. The word now covers expert notes, PM-written checks, LLM judges and benchmarks. A quick check of 10 must-not-fail questions already counts as an eval dataset.
One client said it ran evals but had only checked LM Arena and Artificial Analysis, which benchmark models, not the client's own data. His advice: "Don't be obsessed with prescriptions. They're going to change."
On Codex, Badam pairs core evals with A/B tests and user reactions. A coding agent runs across many integrations and tools, so evals can only guard the core. Before a model or RL change ships, the code review product is A/B tested on whether it finds the right mistakes.
Users annoyed by wrong reviews may switch the product off, and the team watches social media for problems. He rejects the idea of a concrete eval set you could bet your life on, a response to the claim that Claude Code's Boris runs no evals and goes on vibes.
He says hands-on leaders decide whether AI adoption works. Leaders must rebuild 10 to 15 years of intuition, because adoption is almost impossible to drive bottom up. The Rackspace CEO blocked 4 to 6 a.m. daily to catch up on AI and did weekend vibe coding.
He suggests picking two or three trusted sources and bringing questions to AI experts. A leader who vibe codes a demo and assumes production is easy sets misaligned expectations.
Badam says leaders must make experts feel safe to help. Subject matter experts define ideal AI behavior, but if they fear replacement they refuse to talk.
Leaders should frame AI as a way to 10x each person's own workflow, and that tone has to come from the top.
PMs, engineers and data people should share one feedback loop. The old handoffs have broken. Each role used to optimize its own loop, and now they review agent traces together to decide how the product behaves.
He wants the right tool for each workflow step, not an agent for everything. A workflow mixes ML models, deterministic code and humans. Strong teams obsess over the workflow, not the first agent.
Being first with an agent no longer matters. Having the right flywheels to improve over time does.
Badam calls one-click agents pure marketing. Enterprise data carries tech debt such as messy taxonomies and duplicate functions like get-customer-data v1 and v2. Real ROI takes four to six months.
He prefers a team that builds a pipeline that learns over one promising instant gains.
He favors a supervisor with sub-agents over peer-to-peer agents. Splitting duties by function into agents that coordinate in a gossip-style protocol does not work with current models.
In customer support, peer-to-peer agents make it hard to control which agent replies to the customer, and guardrails would have to be moved everywhere.
Badam says persistence through the pain of learning is the moat. Successful companies in a new area learned the non-negotiables by trial and error, and that knowledge, sometimes as an eval or another product, becomes the moat.
He says about 80% of the time of so-called AI engineers and AI PMs goes to understanding workflows, customer behavior and data. As building gets cheap, design, judgment and taste matter more.