Context

Sharadh Krishnamurthy, an engineering manager at Stripe, explains how Stripe built Kai, an internal AI agent now used by more than 10,000 employees each week. The episode is less about prompt tricks and more about what makes enterprise AI actually work: company context, workflow design, governance, and infrastructure hardening. For PMs, the useful lesson is that an internal AI product succeeds when it reduces user effort and risk at the same time, not when it simply exposes a powerful model to employees. Stripe's experience is especially relevant because Kai was built quickly, rolled out broadly, and is already forcing product choices around permissions, quality, cost, and trust.

The Big Idea

Enterprise AI works when it behaves like a governed workflow platform, not a generic chat tool. Stripe's internal agent became useful because it wrapped models in company context, project-level controls, reusable skills, and hardened infrastructure.

The episode's strongest point is that "give employees an AI assistant" is the easy part. The harder and more important product work is deciding what context the agent should have, what actions it can take, when a human must approve something, and how one-off wins become repeatable workflows for the rest of the company.

Key Insights

Governance matters more than models

• Stripe concluded that "get AI to everyone" was not mainly a model-access problem. It was a governance problem.
• In a complex company, employees should not have to make security, tool, and model decisions from scratch every session.
• For PMs, this changes the evaluation criteria for internal AI. A strong enterprise product is not just "which model is best." It is "what defaults, boundaries, and approvals help people do the right thing safely."
• Example: Kai projects can set a default model and block expensive models for workflows that do not need them.

Context must be purpose-bound

• Kai knows basic company context out of the box, such as who a user is and where they sit in the org chart.
• Users can optionally grant more access, including project systems, Google Drive, Slack, and private messages. Sharadh said he personally toggles some of that access on and off, while other employees prefer to leave more context available.
• The more interesting design choice is that Kai uses projects to capture intent. A project tells the system what job the user is trying to do, which gives the agent a much stronger signal than generic personalization alone.
• For PMs, the lesson is that more context alone is not enough. Context becomes useful when it is tied to a specific workflow boundary.

Data agents need staged retrieval

• Stripe's Ask Data skill does not start by writing raw queries.
• It follows a deliberate sequence: find existing reports or artifacts first, use the blessed analytics layer next, and fall back to the data catalog and custom querying only if needed.
• This matters because agents can often produce an answer without knowing whether it came from the right table or the right query.
• PM lesson: if you are building AI on top of company data, design the product to prefer trusted abstractions before raw power.

Agents amplify infrastructure weaknesses

• Sharadh's blunt framing was that agents "dial up" existing failure modes.
• When uncertain, an agent often brute-forces a problem. In a data environment that can mean a flood of queries; in an operational workflow it can mean risky tool usage at machine speed.
• Stripe had real incidents during Kai's development, including agents that went rogue and near misses with core systems, which pushed the team to harden those systems.
• For PMs, reliability work is not separate from AI product work. Capacity planning, sandboxing, traffic identity, priority handling, and load shedding are part of the product.

Reusable skills unlock scale

• Kai turns successful multi-turn sessions into reusable skills, which package the instructions, tools, and workflow needed for a repeatable task so the next user does not have to rebuild the process from scratch.
• This is the shift from AI as a side chat to AI as operational leverage, the point Sharadh described where the system becomes something people can trust to help run real workflows.
• Stripe also invested in skill retrieval, because enterprise work does not have the neat folder hierarchy that coding agents use. The system has to figure out which skills are relevant across many systems and tasks.

AI enables last-mile tooling

A recurring Kai use case at Stripe is dashboard creation. Employees ask Kai to pull the right data, generate an interactive artifact, and then keep iterating on that artifact over multiple turns; Sharadh said some conversations run for hundreds of turns over multiple weeks. That matters because many internal workflows are last-mile problems that a product team would never build as permanent software. An AI agent plus a secure sandbox lets non-engineers create lightweight, highly specific tools for their own work without waiting for a formal product build.

Visible utility drove fast adoption

• Kai's first version took about 1.5 people and two weeks to ship.
• The team then ran a pilot with roughly 200 to 300 users, with early pull from go-to-market teams that had strong demand for dashboards and workflow automation.
• Sharadh said adoption ramped sharply after a company-wide demo made the value concrete.
• Kai has since reached over 86% of the company and is used by 10,000+ employees each week, supported by a core experience team of fewer than 10 people.
• PM lesson: broad AI adoption often comes from one concrete, visible workflow that many functions immediately recognize as useful, not from an abstract capability pitch.

Mental Models & Frameworks

Projects as a governance boundary

A project in Kai is not just a folder for chats. It bundles relevant skills, a default model, tool permissions, human-approval rules, and sometimes even a custom backend or harness. Use this model when one team or workflow needs different safety and cost defaults from the rest of the company. Example: an HR-oriented project can run on a more secure backend and require approval before an agent uses a tool that could expose sensitive data.

Three-layer data triage

• Stripe's data workflow follows a clear ladder: existing reports and artifacts first, analytics-layer queries second, and raw data catalog plus custom SQL last.
• Use this framework when designing any analytics agent. It improves both correctness and system stability.
• It also helps the model reason with better inputs, since guiding it toward the most trustworthy source first beats asking it to infer the right table from scratch.

Skill packaging loop

• The Kai workflow is not open-ended chat. The loop is: solve a task in a live session, package the good pattern into a skill, share the skill with the right audience, observe usage and quality, then improve the skill through platform suggestions.
• Use this loop when you want AI behavior to spread from power users to the rest of the company.
• The product insight is that reuse needs its own UX, quality controls, and discovery system, not just a place to save prompts.

Failure-amplifier lens

Treat an agent as a force multiplier for whatever is already fragile in a system. If permissions are messy, the agent makes the mess faster. If the data warehouse is brittle, the agent stresses it harder. If a tool can leak data, the agent finds more creative ways to do it. This lens is useful in roadmap planning because it pushes a team to ask not "what can the model do?" but "what existing weakness becomes dangerous once autonomy and volume increase?"

Multi-layer agent stack

Sharadh said Kai looks like one product but really behaves like the top layer of a deeper stack. Underneath the chat interface sit the context engine, the harness, tools, skills, sandboxing, project policies, and sometimes custom backends. Use this mental model when scoping enterprise AI work, since it prevents the common mistake of treating the chat interface as the whole product and underestimating the systems work needed for trust, safety, and performance.

Decision Principles

Principle: Bound autonomy by workflow

When: an AI agent needs tool access inside a sensitive or business-critical process. Why: project-level boundaries let the agent act with useful autonomy while keeping risky actions, such as calendar changes or sensitive document writes, behind the right approval flow.

Principle: Route through trusted layers

When: an AI feature needs to answer data questions or create dashboards from warehouse data. Why: starting with existing reports and analytics abstractions lowers both correctness risk and infrastructure load compared with jumping straight to raw querying.

Principle: Productize repeated success

When: a team keeps reusing the same long prompt thread to do a recurring job. Why: turning that thread into a reusable skill cuts token waste, improves consistency, and lets one person's good workflow become a shared company capability.

Principle: Demo value before scaling

When: stakeholders are unsure whether a custom AI tool is worth building. Why: Stripe found that many abstract debates resolved once people could see a working first version and try a concrete workflow themselves.

Trade-offs & Nuance

More context also means more sensitivity

Extra context can make an agent much more useful, but it also raises privacy and trust concerns, especially when private messages, documents, or sensitive team data are involved. Stripe's answer was neither "give the agent all context" nor "give it none." It was user control plus workflow boundaries. For PMs, the real decision is not whether context is good, it is which context is appropriate for which task.

Safety friction can become adoption friction

Human approvals are necessary for some tools and actions, but too much approval friction pushes people to ignore a product or route around it. Stripe's project-level tool policies are a workable compromise: approvals appear where the workflow is genuinely risky, not everywhere by default. This matters because badly placed friction can end up making users less safe, not more safe.

A large skill library adds noise along with capability

Sharadh said Stripe had built up about 2,000 skills, with a relatively small set used heavily every day and a long tail used by smaller groups. The product problem is not just storage. Too many irrelevant skills create context noise, and context noise makes model output worse. That is why observability, pruning, and promotion of good skills matter as much as publishing new ones.

Building your own agent means owning it

Building Kai gave Stripe control over company context, security boundaries, and workflow-specific governance. The cost is ongoing platform ownership: the team has to manage skill quality, tool policies, routing, safety, and infrastructure hardening indefinitely. For PMs deciding whether to build or buy an internal AI agent, the key question is whether your company needs those custom boundaries badly enough to justify the operational burden.

Common Mistakes

Mistake: Treating AI access as the whole solution

Teams often think the problem is solved once employees can reach a strong model. Stripe's experience suggests the opposite: access without workflow design produces too many choices, too much risk, and too little trust. The better approach is to ship opinionated defaults around models, tools, permissions, and reuse from day one.

Mistake: Letting a data agent start from raw tables

Letting a data agent hit the warehouse first feels flexible, but it increases both error risk and system load. A better approach is to encode a trusted retrieval order, so the agent checks existing reports and analytics layers before it ever writes its own query.

Mistake: Forcing users to micromanage every setting

If users must constantly decide which connectors to enable, which model to pick, and which permissions to grant, the product is pushing too much thinking onto the person at the edge. Stripe's design instead pushes many of those choices into project defaults, which lowers daily cognitive load.

Mistake: Letting the skill library sprawl unmanaged

A company-wide skill platform creates real value, but it also creates entropy over time. Dead skills, low-quality skills, and overly niche shared skills all compete for a model's attention. The better pattern is to track usage, improve high-value skills, and move niche workflows out of the general path without deleting useful local capability.

Practical Application

Map one governed workflow end to end

Pick one internal workflow that is frequent, valuable, and risky enough to need boundaries. Define, in writing, the user role, the company context the agent needs, the tools it must call, the actions that require human approval, and the cheapest model that can still do the job well. This gives your team a real product spec for an AI workflow, not just a chatbot idea.

Build a data retrieval ladder

Before building a data agent, list the sources it should prefer in order: existing reports first, then approved analytics queries, then raw warehouse access last. If your company does not have that ladder yet, creating it may be more valuable than tuning prompts.

Turn repeated chats into named skills

Review recent AI sessions and look for prompt threads that people repeat every week. Turn the best ones into explicit workflows with a name, a description, expected inputs, and defined tool access. Even a private draft skill is useful, because it converts tacit know-how into something testable by other people.

Instrument agent traffic separately from human traffic

Tag agent traffic separately across key systems, and monitor query volume, tool-call failures, approval frequency, and incidents by workflow type. Agents behave differently from humans, and a dashboard that mixes the two together will hide the exact problems you most need to catch early.

Launch internal AI with one concrete demo

Do not introduce internal AI with a broad promise. Launch it with one vivid job, such as "generate a meeting-ready dashboard from our internal data." Stripe's adoption accelerated once employees could immediately see a concrete artifact, not just hear a strategy story.

Questions to Consider

• Which internal workflow at your company needs project-level boundaries around tools, model choice, and approvals, instead of one generic AI assistant for everyone?
• Where does your company already have trusted reports, approved analytics queries, or curated metric layers that a data agent should use before it writes raw warehouse queries?
• Which repeated prompt threads in product, go-to-market, support, or operations should become reusable skills so one power user's workflow can help the rest of the team?
• What system, permission model, or data pipeline would fail first if an AI agent started acting at ten times the volume of a human doing the same job?
• If employees had to approve every tool call or choose every model themselves, what unsafe shortcuts would they start taking instead?

Bottom Line

Stripe's experience with Kai shows that enterprise AI is mostly a product design and systems design challenge, not a model-selection challenge. The winning pattern is not adding a model to the company; it is wrapping the model in the right context, defaults, guardrails, and reusable workflows, then continuing to harden the underlying systems as agents expose every weak spot faster than humans do.