Stripe's Knowledge AI Platform

TL;DR Highlight

Stripe built Kai, an internal agent platform for non-engineers; 83% of staff use it weekly.

Who Should Read

A backend or platform developer designing an internal agent platform for non-engineers and worrying about security and per-domain governance.

Core Mechanics

Coding agents didn't fit non-engineers
- Coding work has a uniform shape of editing files, running tests, and committing, so one agent architecture works.
- Knowledge work needs different tools, data, outputs, and definitions of done, so the same approach doesn't carry over.
The two earlier options both fell short
- The NoCode Agent Builder produced over 4,000 agents, but teams wrote similar prompts of varying quality.
- The spread of micro-agents became hard to monitor and maintain.
- Users who picked coding agents raised security concerns and a new support burden for code quality teams.
Kai is built in three layers
- First is surface-agnostic APIs so multiple interfaces share the same agent.
- Second is Agent Studio, where domain owners build and govern their own agents and skills.
- Third is an execution environment that delivers security without users thinking about infrastructure.
The agent is a service, not an app
- The web app and Slack integration are just views on the same API.

Community Reactions

Metrics are self-reported and questioned
- Some commenters found it suspicious that 2x sales activity gave only 17% more opportunities but 39% more closed deals.
- Others noted correlation isn't causation, since vacations or sick days would lower both activity and tool use.
Not much that is specific to knowledge
- Some commenters saw no verification or transparency features, just a generic agent builder.
- Others said the post doesn't explain why Stripe built its own instead of using open source or products like Notion.
A new channel worked better for one client
- One commenter found a client explicitly preferred a chat UI over poorly maintained internal tools.
- They are replacing hundreds of cshtml views and controllers with one agent tool that applies JSON patches.
Similar directions were mentioned
- Some commenters compared it to Cloudflare OS and said every company with spare engineers builds this internally.
- Another said windmill.dev is heading the same way, centered on a secure code runtime, ACLs, and app building.

How to Apply

Write down your agent's isolation rules
- Spend 30 minutes today listing pairs of data contexts that must never mix in one session.
- For each pair, write one line on what to block based on task context, not the auth token.
Audit your prompt sprawl
- Collect the agents and prompts each team has built and group those with similar goals.
- Merge duplicates into one shared skill and assign an owner.
Split your agent into an API service
- Pull the agent logic out of the web app and expose it as an API.
- Build Slack bots and internal tools as thin views that call that API.
Design a control screen for domain owners
- Show usage and quality signals per skill on a single screen.
- Let domain teams fix their skills without asking the platform team.

Try It

copy & run

# Paste into Claude or ChatGPT (a simplified version of the article's isolation idea as a prompt)

I'm designing an internal agent platform. Use the principle below to review risky scenarios in our service.
Principle: even if a user has access to two data contexts separately, data from two unrelated customer contexts must never be combined in one session. The test isn't 'what can this person see' but 'what should this task be allowed to view in this context'.

Our service description: {{service description}}
Data sources the agent uses: {{data source list}}

Please do the following.
1. List up to 5 pairs of data contexts that must not mix in one session.
2. For each pair, write rules on which context to pin at session start and what to block in tool calls.
3. Write one test scenario question per pair to check for violations.

Next step: run the scenario questions against your real agent and check that the rules hold.

Terminology

Agent harnessThe execution framework that wraps an LLM so it can work with tools. Think of the chassis and controls around a car engine.

SandboxAn isolated space where an agent runs code, separated from outside systems. Like kids playing only inside a sandbox.

Control planeThe layer for configuration, monitoring, and management, separate from the one doing the work. Agent Studio plays this role.

Multi-tenant virtual filesystemA fake file store shared by many users or sessions where each only sees its own space.

SkillA bundle of instructions and tools an agent loads for a specific task. Like a work manual handed to an employee.