How Stripe built its own company AI brain, the Kai agent

The question that opens practically every corporate AI project today is the most tedious possible: build or buy? Stripe answered build, and the result is Kai, an internal agent used by more than 10,000 employees every week. In an episode of the How I AI podcast, by Claire Vo, Sharadh Krishnamurthy, engineering manager at Stripe, opened the box: what weighed on the decision, how governance was designed, and what nearly brought down production systems along the way.

The angle that matters for those who build infrastructure isn't the agent's hype. It's that Stripe treated internal AI as a platform problem, not a tool problem. And much of the answer was already built before Kai existed.

Why Build Instead of Buy

The decision to build from scratch often sounds like engineering pride (the classic "not invented here"). In Sharadh's account, what turned out to be the key was context. A bought agent knows how to use generic tools; it doesn't know what a "disputed payment" means in Stripe's internal vocabulary, which tables contain sensitive data, or who has permission to query what. That corporate context is exactly what doesn't come in the box.

The central point of the interview, and what matters most for a Brazilian technical team, is this: the infrastructure Stripe had already built for human developers turned out to be exactly what the agents needed. A queryable data layer with access control, a secure sandbox, a tool catalog with permissions. None of this was created for AI. It was created for people, and the agent came in as just one more consumer of those internal APIs.

The takeaway: if your company has already invested in decent developer experience (a governed data layer, isolated environments, well-resolved identity and permissions), you're closer to a secure enterprise agent than you think. If it hasn't, buying a ready-made agent doesn't solve the problem, because the hole is underneath it.

Projects as a Governance Layer, Not a Folder

The most interesting design detail is the concept of "projects." In most tools, a project is a folder: a way to organize conversations. At Stripe, a project is a governance mechanism. It defines the scope of data, tools, and permissions the agent has access to within that work context.

It's an important inversion. Instead of giving the agent unrestricted access and hoping it behaves, the project acts as a boundary: within it, Kai only sees what that context authorizes. This shifts the security mental model from "filtering the model's output" to "restricting what it can reach in the first place." For anyone dealing with sensitive data (and payments are the extreme case), that's the difference between a pilot and something that runs in production.

Kai also carries, by default, context about the user themselves: who you are, your team, your history. Sharadh makes a point of separating what the agent knows by default from what the employee controls and can turn off, an acknowledgment that useful context and surveillance are the same technology with different governance.

The Data Layer: Trino and Secure Querying at Scale

For agents to query data without becoming a risk, Stripe relied on a structured data layer. The interview cites Trino (the distributed query engine, formerly PrestoSQL) among the reference tools. The idea is that the agent doesn't talk directly to production databases, but rather to a query layer that already carries the access rules.

This solves two problems at once. The obvious one is security: the agent can't read what it shouldn't. The less obvious one is load: an agent that fires off heavy queries with no sense of cost can degrade a system that serves real payments. Sharadh explicitly mentions load shedding (dropping load under pressure) and the episode in which agents nearly brought down production systems, which pushed the team to treat the agent as an infrastructure client that needs rate limiting and circuit breakers like any other service.

The takeaway from this part of the conversation: agents that run with autonomy need their own identity and load limits, or they'll eventually bump into a critical system.

This is where the concept of agentic identity comes in: the agent acts on someone's behalf, but needs a traceable identity so it's known what it did, with what permission, and so access can be cut off if it goes out of control. It's the same service account principle, applied to something that makes decisions.

Skills: When Anyone Can Package a Workflow

The most scalable part of Kai is the skills platform. A skill is a packaged workflow: an employee describes a repetitive process (generating a report, building a dashboard, checking a status) and turns it into something reusable across the whole company. According to the interview, Stripe reached about 2,000 skills.

That number brings up the real problem of any internal marketplace: quality. Two thousand skills created by people of every technical level inevitably include a lot that's broken, redundant, or dangerous. Stripe's answer combines evals (automated assessments of skill quality) and telemetry to find out which ones are actually used and which ones work. Without that, the skills platform turns into a graveyard of automations nobody trusts.

For a smaller team in Brazil, the lesson isn't "have 2,000 skills." It's that the problem at scale isn't creating automations, it's curating them. The moment anyone can package a workflow, you need a continuous evaluation mechanism, or the platform loses credibility the first time a skill produces the wrong result.

What You Can Take Away (and What You Can't)

Stripe's path is appealing, but expensive. Building from scratch only makes sense when three conditions come together: you have corporate context that no off-the-shelf tool captures, you already have mature data and permission infrastructure to reuse, and you have the scale (10,000 people) to justify the investment. Missing any of the three, buying and integrating tends to be the more rational choice.

What's transferable regardless of size:

• Governance at the entry point, not the exit. Restrict what the agent can reach (the "projects" model), instead of trying to filter everything it produces.
• Treat the agent as an infrastructure client. Its own identity, rate limiting, load shedding. It will bump into production, so plan for that in advance.
• Reuse the governed data layer. If the agent queries data through an engine with access control (Trino or equivalent), you get security and load control thrown in.
• Skill curation is infrastructure, not housekeeping. Evals and telemetry from the start, or the platform rots.

The good question to bring back to your own product: if an autonomous agent had the same permissions as my average developer, what could it bring down? The answer defines how much governance you need to build before releasing any AI into production.

The full episode, with a live demo of Kai building a dashboard, is available on YouTube, Spotify, and Apple Podcasts via Lenny's newsletter.