Most companies deploying AI internally buy an assistant and wonder why nobody uses it twice.
Stripe built one that more than 10,000 employees use every week. Sharadh Krishnamurthy from its engineering team described the architecture on Lenny's Newsletter this week, and the useful part is not the part anybody expected.
It is not the model. It is the permission system.
The bottleneck was never the assistant
The internal agent is called Kai, and it sits on three layers: governance, skills, and infrastructure.
Note the order. Governance is not a compliance wrapper added at the end. It is the base the other two stand on, and that ordering is the whole lesson.
The reason most internal AI deployments stall has nothing to do with output quality. It is that the assistant cannot see anything worth seeing.
To be useful to a finance analyst it needs the finance data. To be useful to support it needs the ticket history. The moment you connect either one, somebody in security correctly asks who else can now reach it, and the project enters a review that lasts two quarters.
So the deployment settles into the safe configuration, which is an assistant connected to nothing, competing with the public version of the same model that has a better interface.
That is why most AI pilots die in the middle. Not at the demo, not at scale, but at the point where access has to be granted and nobody owns the decision.
Projects as a permission boundary
Stripe's answer is a primitive it calls projects, and the reframe is worth stealing whether or not you build anything.
A project is not a folder. It is a scope that defines what data and which permissions an agent operating inside it can reach.
That single move converts an unanswerable question into a routine one. Instead of "can the AI access customer data", which no security team will ever say yes to in the abstract, you get "this project, for this team, reads this dataset, with these permissions".
The second question has an owner and a precedent. The first has neither, which is why it sits open for months.
It also means access decisions become reusable. Approve the shape once and every subsequent team inside that shape inherits it, instead of restarting the argument from zero each time.
Two thousand skills is the real asset
The number that should get attention is 2,000. That is how many skills employees have packaged onto the platform.
A skill is a workflow somebody does repeatedly, written down in a form the agent can execute. Which means Stripe now has two thousand internal procedures documented that were previously living in individual heads.
Sit with that for a second. Companies have spent thirty years and enormous budgets failing to capture tacit process knowledge. Knowledge management systems, wikis, onboarding documentation, all of it decays because writing it down helps the next person and not the person writing.
Here the incentive finally points the right way. You write the skill because it saves you time this week, and the organisational asset is a side effect.
That asset compounds and it does not leave when someone resigns. If I had to name the single most valuable output of this whole programme, it is not the agent. It is two thousand documented procedures that exist because documenting them was selfish rather than virtuous.
It also requires structure to stay useful. Stripe runs skill quality standards, evaluation, and telemetry, because two thousand unmanaged skills is just a second mess with better branding.
They built rather than bought, and the reason matters
Stripe built Kai from scratch instead of buying, specifically to sit on the developer experience platforms and data systems it already had.
That is a defensible choice at Stripe's size and a bad default for almost everyone else. The signal to take is not "build your own", it is that integration depth with your existing systems is what determines whether internal AI gets used.
If you buy, buy the thing that connects to where your work actually lives. If your operations run in a system nothing integrates with, that is your real project, and no assistant fixes it.
Agents break production in ways software does not
The production lessons are the ones I would read twice before deploying anything with write access.
Stripe implemented agentic identity, load shedding, and sandbox protections, specifically to stop agents destabilising production systems.
Agentic identity means an agent acts as itself, not borrowing a human's credentials, so its actions are attributable and revocable. If your agents authenticate as a service account shared by a team, you have no audit trail and no way to switch one off.
Load shedding matters because agents do not back off politely. A retry loop against an internal API is a self-inflicted denial of service, and it arrives at three in the morning.
The pattern underneath all three is the same. Agents are not applications and they are not users. They are a third category, and the infrastructure most companies run assumes only the first two exist.
Start with the permission model. Everything else is downstream of who is allowed to see what.