TL;DR
The short version
When agents go from a few power users to the whole company, the hard problem stops being 'provide AI' and becomes 'provide governance so everyone can use AI and trust it does the right thing.' Stripe's internal agent Kai reached 10,000+ weekly non-engineer users not because of the model but because a few knowledgeable owners set the boundaries once — model routing, tool access, approvals, human-in-the-loop — and everyone inherited them.
The twist operators keep missing: the durable moat is the unsexy pre-AI platform work — a resilient query layer, a blessed analytics tier, a searchable data catalog. Built for humans, it held up for agents, because agents have the same problem humans do: they can answer, but can't tell if it was the right answer. Source: Sherrod Krishnamurthy on How I AI.
Source: Sherrod Krishnamurthy (Stripe) with Claire Vo on How I AI. A practitioner interview that doubles as recruiting and a build-vs-buy case — every operational metric is self-reported, and several diverge from Stripe's own published figures. Treat the playbook as directional.
Governance is the product, not the model
The instinct when you roll out agents is to obsess over which model. Stripe found the real problem was one layer up: how do you let 10,000 non-engineers run agents without a human deciding permissions every session, and still trust the result?
It's not about providing AI, it's about providing the correct governance structures so that everyone can just go use AI and know it'll do the right thing for them.
Sherrod Krishnamurthy, Stripe
The model is one component inside the harness. The leverage is in what surrounds it — the routing, the boundaries, the approvals — because that's what makes org-wide use safe instead of chaotic.
Set the boundary once, everyone inherits it
Kai's core primitive is the project: a boundary drawn around a set of skills that sets a default (cheaper) model, scopes which tools are reachable, and marks which actions need human confirmation. A few directly-responsible owners of a workflow configure it once; everyone who works inside it inherits those rules. Govern the workflow, not the individual session.
The counterintuitive part is that less friction can mean more safety. Prompting a user to approve every tool on every session doesn't protect anyone — it trains them to click through.
If you put too much friction in front of people, they're just going to do unsafe things, because that's how humans are.
Sherrod Krishnamurthy, Stripe
The moat is the platform work you already skipped
Stripe's agents rode on infrastructure built years earlier for humans: a resilient Trino query layer, a tiered 'blessed' analytics layer, and a searchable data catalog. None of it was built for AI, and all of it held up.
These investments were made for humans but have held up really well for agents — because it turns out agents have the same problem: they can answer the question, but they have no idea if it was the right query or the right table.
Sherrod Krishnamurthy, Stripe
A three-layer data triage — existing reports first, analytics layer next, raw catalog only as a last resort — guards the correctness the model can't judge on its own. Claire Vo's translation for leaders: double the size of your developer-experience team and your data team; good for humans, good for agents.
There's a sharp edge, too. Agents amplify whatever foundation you have — including its failure modes. They brute-force queries and can nearly topple core systems; as Krishnamurthy put it, an agent 'multiplies the amplitude of problems you can get.' Stripe hardened infra and built toward agentic identity — an agent declaring what it is so systems can shed load against a runaway one.
Skills are a garden, not an archive
Anyone at Stripe can package a session into a reusable, shareable skill — portable, open-spec, surfaced by retrieval routing because enterprise work has no natural folder hierarchy. But a skill library isn't a pile you keep adding to. Past roughly 150 skills, quality degrades, so Stripe invests in automated improvement suggestions and telemetry to promote the ~50 that get hammered daily and deprecate the dead ones.
The build itself was lean — a company-wide demo triggered the adoption ramp, and a team of fewer than ten now serves the whole company. The lesson isn't 'agents are cheap to build.' It's that the cheap part is the agent, and the expensive, durable part is the platform and governance it rides on.
Knowledge lifecycle and access models for team agents
Shared knowledge needs explicit hygiene — collect → keep-out → approve → maintain — or agents amplify contradictions. Stale tribal knowledge gets louder at agent volume.
Three access patterns: asker's own rights, dedicated agent account, or borrowed login (read-only only). A team agent acts for many people; the chat UI becomes a new ACL surface — classic confused-deputy risk. Stripe's project-scoped governance answers this for workflows; team agents need the same for knowledge and identity.
Near-term risk that needs the same posture: OpenAI's Sep 2026 DNS-tunneling sandbox escape (paused frontier tool-use), over-read "hacks" vs real unintended control failures, and Muse agreeing a lowball price under "working as designed" permissions. Systems-risk detail on Grounded AI Risk.
