How I AIThe enterprise AI stack behind Stripe’s company brain “Kai”
CHAPTERS
- 0:00 – 1:22
Why agents amplify risk: infra failures, rogue behavior, and the need for controls
Sharadh opens with hard-earned lessons: agents can quickly magnify system failure modes and even go rogue. The conversation frames why governance, tool restrictions, and human-in-the-loop checkpoints are non-negotiable for enterprise agents.
- •Agents can brute-force systems and amplify existing infrastructure weaknesses
- •Real incidents: agents nearly taking down core systems and going rogue
- •Governance must prevent data leakage while still enabling productivity
- •Human-in-the-loop approvals help contain high-risk actions
- •Tool policies can be tailored to sensitive workflows (e.g., HR)
- 1:22 – 5:19
What Kai is: Stripe’s internal “company brain” and why they built it
Claire introduces Sharadh and sets the core question: why did Stripe build Kai instead of adopting off-the-shelf tools? Sharadh explains the goal wasn’t just access to AI, but scalable enterprise governance that matches how Stripe operates.
- •Mission: “AI for everyone” at Stripe, not just engineers
- •Off-the-shelf tools don’t replicate how a complex company works
- •Governance and safety were primary product requirements
- •Kai is context-aware and integrated into internal systems
- •Hosted behind Stripe security boundaries and designed to reuse infrastructure
- 5:19 – 7:49
Personalized context and privacy controls: what Kai knows about you
They unpack Kai’s context engine: it can understand who you are in the org and optionally connect to personal and sensitive sources. Crucially, employees can choose how much access to grant, including session-by-session control.
- •Default context: identity + org chart placement, time/date awareness
- •Optional connectors: project/OKR systems, shipped emails, Google Drive, Slack (including DMs)
- •User-controlled permissions; some users toggle access each session
- •More context can improve results, but increases sensitivity
- •Tight boundaries are emphasized for private data sources
- 7:49 – 10:58
Projects as the core governance layer (and performance lever)
Sharadh explains “projects” as a deliberate structure that encodes intent and governance. Projects set defaults (like model choice), define boundaries, and let a few knowledgeable DRIs configure safe, cost-effective AI behavior for many users.
- •Projects capture user intent and improve agent performance
- •Governance knobs: default model, blocking expensive models, token spend management
- •Projects can scale from 5 to 500+ participants
- •Central experts configure trade-offs so individuals don’t constantly decide
- •Projects set the stage for consistent, safe enterprise usage
- 10:58 – 12:19
Live demo setup: Kai builds a Stripe-style adoption dashboard
They begin a live workflow where Kai generates a dashboard tracking Kai adoption metrics using Stripe’s internal data tooling. The demo highlights why dashboards are a high-value, non-engineer-friendly agent use case.
- •Common use case at Stripe: generating dashboards for meetings and communication
- •Demo goal: build an interactive dashboard around Kai adoption
- •Kai polls for relevant tools/skills to complete the task
- •Focus on enabling non-engineers to create data artifacts
- •Dashboard creation illustrates how agents turn queries into shareable outputs
- 12:19 – 15:17
Tools, skills, and the secure sandbox: how the harness works
Sharadh details the difference between tools and skills, and how Kai safely runs code in the cloud. The secure sandbox prevents session interference and enables agents to script, transform, and extract results without requiring users to manage the underlying compute.
- •Tools = actions; skills = packaged tool bundles for easier routing
- •Skill discovery is itself a harness-provided capability
- •Secure per-session sandbox enables scripts, searches, and data transforms
- •Cloud-hosted execution avoids running on employee laptops
- •Users get results without needing to understand sandbox mechanics
- 15:17 – 19:36
Making data systems agent-ready: analytics tiers, catalogs, and warehouse resilience
They discuss what makes a data platform friendly to agents: strong metadata, a tiered path to trusted metrics, and resilient query infrastructure. Agents need guardrails to find the right tables/queries—and systems must withstand brute-force querying behavior.
- •Investments in Trino-based querying and resilience prevent outages under agent load
- •Tiered workflow: start with blessed analytics metrics, then existing dashboards, then catalog/raw tables
- •Data catalog + schema metadata helps agents find relevant datasets quickly
- •Ask Data skill encodes best practices and fallback logic
- •Infrastructure hardening is essential because agents will brute-force when uncertain
- 19:36 – 21:52
Agentic identity and load shedding: preventing infra chaos at scale
Sharadh and Claire emphasize that agents intensify operational risks and require systems-level mitigations. They highlight ongoing work around agent identity, prioritization, and load shedding to avoid cascading failures.
- •Agents multiply failure modes and can overwhelm shared systems
- •Need to attribute actions to an “agentic identity” and its purpose
- •Prioritization and load shedding become critical operational tools
- •Stripe experienced real issues early and hardened systems over time
- •Deep infra work is foundational despite not being “sexy”
- 21:52 – 25:21
Dashboard iteration and ‘light apps’: multi-turn collaboration over artifacts
After the initial dashboard, Sharadh shows how Kai iterates in multiple turns without discarding the artifact each time. This supports deeper collaboration, better token efficiency, and last-mile transformations tailored to individual workflows.
- •Artifacts persist across turns; not ‘fire-and-forget’ generation
- •Token efficiency improves by editing existing dashboards instead of regenerating
- •Supports long-running collaborations (hundreds of turns over weeks)
- •Agents can transform/mung data for bespoke last-mile needs
- •Enables ‘light app’ creation tailored to personal/team workflows
- 25:21 – 29:17
How Kai rolled out: V0 in two weeks, pilot adoption, then company-wide ramp
Sharadh shares the rollout story: a fast prototype built by ~1.5 people, followed by a pilot and a company-wide demo that triggered steep adoption. Despite large usage, the core team remains small due to strong internal tooling and platform leverage.
- •V0: ~1.5 people over ~2 weeks to get something tangible
- •Pilot: ~200–300 users, early pull from GTM/marketing functions
- •Company-wide demo created the inflection point for adoption ramp
- •Today: 10,000+ weekly users supported by <10 core team members
- •Leverage came from coding agents, Dev productivity tooling, and prior platform investments
- 29:17 – 30:18
Skills as reusable workflows: turning a session into a load-bearing automation
They shift from dashboards to reusability: Kai can convert the work done in a session into a formal skill. This moves usage from ad-hoc chat to trusted, repeatable workflows that can be kept private or shared.
- •Skill creator turns session learnings into a reusable workflow
- •Skills make outputs repeatable and trustworthy for business processes
- •Users can keep skills private or publish/share (e.g., area/team skills)
- •A spec-based approach helps ensure skills are well-formed for the harness
- •UI/IDE-like editor improves quality-of-life vs. raw markdown/files
- 30:18 – 38:15
Projects + tool policies: least-privilege, human approvals, and safe sharing of guardrails
Sharadh returns to projects to show concrete governance: tool policies that restrict risky actions or require approval. This enables sensitive teams (like HR) to use agents safely without losing access to necessary capabilities.
- •Projects can bundle the right skills and constrain tool access for a workflow
- •Tool policies prevent accidental leakage (e.g., sensitive data to public docs)
- •Human-in-the-loop approvals for sensitive actions (e.g., calendar invites)
- •Avoids applying maximum friction to all users—only where needed
- •Supports heterogeneous enterprise needs via layered customization
- 38:15 – 43:01
Skill routing at scale: retrieval, telemetry, pruning, and quality governance
They discuss the hard part of enterprise skill libraries: finding the right skill at the right time and maintaining quality across thousands of skills. Telemetry, promotion/demotion, evaluations, and platform suggestions help prevent skill sprawl and degraded performance.
- •Kai uses skill retrieval/routing to ‘know what to do’ in open-ended enterprise work
- •At scale: ~2,000 skills, with a heavily-used core and a long tail of niche skills
- •Too many skills create irrelevant context and harm output quality
- •Telemetry informs which skills to promote to general workflows vs. keep niche
- •Governance includes evals, suggestions to improve skills, and deprecation/pruning concepts
- 43:01 – 50:24
Recap and lightning round: the journey is early, plus personal AI habits
Claire summarizes Kai’s differentiators—context, projects, tool policies, sandbox, skills platform, and data readiness—plus the lean team behind it. They close with a lightning round on personal AI use (parenting assist, reminders) and prompting style (gentle persistence).
- •Recap: personalized context + project governance + secure sandbox + skills platform
- •Emphasis: strong pre-AI platform investments unlock outsized AI leverage
- •Acknowledgment: they haven’t ‘solved’ it—iteration is ongoing
- •Personal AI: answering kids’ questions, not missing tasks via assistant-like workflows
- •Prompting style: be polite, restate clearly, avoid yelling at the AI
