How Stripe Built Its Internal AI Agent: One Engineer, One Week, Now Used by Nearly Everyone
- One sentence in, 11 seconds later, and Kai returns a working event invitation page—openable, exportable, with a live countdown.
- The first version took one engineer a week to build, because the hardest part was already done: file handling, sandboxing, and context summarization all came off the shelf.
- You can have too many skills. At 150, Stripe watched frontier models start grabbing the wrong ones.
- Even the official post contradicts itself: the text says most conversations are multi-turn, but the chart shows the median session is just 2 turns.
Kai: A Company-Wide AI Assistant Built by One Person in a Week
At the end of July, LangChain's official blog published a detailed teardown of how Stripe used their open-source Deep Agents to build Kai, an AI assistant for all non-engineers across the company. Today, 83% of Stripe employees use it every week. The first working version took a single engineer a week to build. What makes this post worth reading is that it lays out exactly which layers can be bought, which layers you have to build yourself, and where you hit a wall if you scale it too far—including one counterintuitive finding: equip an agent with too many skills, and it actually gets dumber.
What Kai is, in three paragraphs
Here's what it can do:
Watch it work. In Stripe's 11-second demo, engineer Anupam types this into Kai's home screen:
Create a week-by-week launch plan and an interactive event invitation for a public Stripe Press event in San Francisco. Target early-stage founders. Theme: "Building companies that last in the age of AI." Pick the 3 books with the highest website traffic in the last 90 days. Research what these authors have published recently. Recommend a theme, a reading list, and two potential speakers. Cite every choice.
Stripe's Kai demo (no audio). From a blank home screen to a finished dark-themed event page in 11 seconds. You can see it calling the tool write_file · file_path: event_invite.html, plus a skill tag called ask-data. Source: stripe.dev, "Meet Stripe's Knowledge AI Platform."
That page is a real file: dark theme, headlined "Built to Last: Founding Durable Companies in the AI Era," dated Thursday, September 24, 2026, 6:00–8:30 PM, at Stripe's San Francisco Bay Area office. The audience is "early-stage founders (pre-seed to Series A)." There are two buttons—"Request Invite" and "See Reading List"—and a live countdown ticking underneath. In the top right, you'll find "Exit Demo" and "Export."
A few details flash by worth noting: the small print at the bottom of the home screen says it was built by the Agent Foundations team, the getting-started guide lives at the internal shortlink go/kai-getting-started, and feedback goes to the #kai-pilot channel. There's an "Incognito" toggle in the top right. And the input placeholder is "Ask anything, # for skills"—type a hash to pick a skill.
The difference between a knowledge-work agent and a chatbot shows in the output: you need something you can open, edit, and send on. A wall of text you read once and forget won't cut it—and that difference dictates a different foundation underneath.
Why Coding Agents Can't Help Sales and Finance
Stripe's engineers have had AI helpers for a while—their homegrown coding agent Minions merges over a thousand PRs a week, with humans still reviewing the code. (This context comes from two other posts about Minions on stripe.dev; LangChain's post doesn't mention it.)
The problem: most of the company doesn't write code—sales, financial analysts, technical account managers. When the Claude Code / Codex wave hit, these people got left behind. They wanted to use the tools, but the terminal, data permissions, and security approval were three barriers they couldn't cross.
Before Kai, Stripe tried two paths, and neither worked all that well.
Anyone could drag and drop a small, single-purpose agent with tools attached. They ended up with 4,000 of them.
The problem wasn't the count. It was that many prompts were *similar in intent* but wildly uneven in quality. And with so many small agents scattered around, monitoring and maintenance became a nightmare.
Some people actually did this, contorting their workflows to fit a developer tool.
Security issues surfaced quickly. Meanwhile, the code quality team suddenly had to support a whole new class of non-engineer users—an entirely new burden.
After these two attempts, they landed on a core insight that all subsequent design grew out of:
Coding is a fixed shape. The specific file you're changing varies, but the loop is constant: edit files, run tests, commit. The language might be Ruby or Java, but the shape of the work is the same. That's why one agent architecture can handle it all.
Knowledge work sits at the opposite end. Researching a client account and preparing for a compliance review use different tools, different data, and produce different outputs. Even the definition of "done" is different. You can't fit that into one architecture.
That insight drove three conclusions.
1. Expertise has to be distributed, not centralized
The people who know how to handle a billing escalation or model revenue are scattered across dozens of domains—GTM, Finance, Marketing, Legal, Data Science. They're certainly not on the team building the agent infrastructure. Multiply that by Stripe's entire product line and global footprint, and the complexity is staggering. Kai's job: model that complexity, then make it invisible—so the task just gets done.
2. The agent has to meet people where they already work
Not everyone works in a browser, and far fewer in a terminal. So a standalone product was out. It had to be a platform, embeddable in any internal tool.
Finance has an internal app for forecasting complex changes to the operating budget. An agent needs to read the current context, query the relevant documents, propose compliant changes, and summarize the differences—all without pulling the user out of that app. A standalone product would force users to abandon their existing workflow for a new app. Building a separate agent for every entry point is a maintenance nightmare and creates a fragmented experience for people working across multiple tools.
3. Guardrails have to be built from scratch
Coding agents sit in an ecosystem with decades of guardrails: compilers reject syntax errors, tests catch regressions, git undoes mistakes. These fast, verifiable checks are almost entirely absent in knowledge work.
Stripe gives a concrete example of a hard rule: You can't put data from two unrelated customers into the same analysis. The boundary is subtle here—a person might legitimately have access to both datasets, but they still can't be in the same session.
So the question shifts. Instead of asking "what can this person's authorization token access?" you ask "what should this task, in this context, be allowed to see?" The first question has an answer in the permissions system. The second is something the platform has to hold for you at runtime.
Three Things Deep Agents Handed Them: Files, Sandbox, Context
Kai is built on Deep Agents, LangChain's open-source agent harness.
Think of it as an agent's skeleton and drivetrain: the model invocation loop, middleware composition, streaming output, state management—the generic parts anyone building an agent has to write from scratch. It's like buying a chassis and transmission when you're building a car. You design the body and interior, but nobody re-invents the drive shaft.
Deep Agents solved everything that wasn't Stripe-specific, freeing us to focus on Stripe's problems. You can grab a bunch of middleware off the shelf. The composable skill pattern, the composite backend—it gave us the right structure while keeping enough flexibility.
Sharadh Krishnamurthy · Engineering Manager, Agent Foundation, Stripe
The one-week timeline came down to three off-the-shelf middleware components (middleware: a pluggable layer between the model and your business logic, each handling one generic concern, installable on demand). Let's break each one down.
1. Virtual file system: A desktop the agent can keep scribbling on
Kai is a production service running in the cloud, not a local process you've launched. It has no hard drive. Stripe's solution is an S3-backed virtual file system, letting the agent read, write, and reference files across turns.
A file system works well as agent context because it's something the model can browse, modify, and organize itself—unlike a chat log that just grows in one direction.
Deep Agents gives the model eight file tools (this table comes from LangChain's official docs, which the original post doesn't list):
| Tool | What it does |
|---|---|
ls | List directory contents with file sizes and modification times |
read_file | Read a file; supports line offsets for large files. Can also read images, video, audio, PDFs, and PPTs |
write_file | Create a new file, or completely overwrite one |
edit_file | Precisely replace strings; supports global replace |
delete | Delete a file, or recursively delete a directory |
glob | Find files by wildcard pattern, e.g., **/*.py |
grep | Search file contents, with options for filenames only, context, or just a count |
execute | Run shell commands. This tool only appears to the model when a sandbox backend is configured |
Stripe wraps this with a layer they call "sync-in / sync-out": before any execution in the sandbox, the relevant files are materialized into it; after execution, any new or changed files are synced back to the virtual file system.
The effect: the agent and its model experience a single, coherent, persistent file environment for the lifetime of the session, even though the underlying sandbox may have been created and destroyed multiple times.
2. Sandbox: The key is that the agent stands outside
Kai runs two kinds of code: analysis (Python queries, charts) and messy file formats (PDFs, presentations, structured documents).
Here's a subtle but crucial design choice that's easy to miss: The sandbox is exposed to the agent as a tool. The agent itself does not run inside the sandbox. The agent runs outside, and calls in when it needs to execute code.
Why? The answer is in a security model called the "lethal trifecta," proposed by Simon Willison in June 2025, which Stripe cites directly:
Any AI system with all three can be tricked into shipping your data out—the model can't reliably tell a command from its operator apart from a command from the document it's reading—everything becomes a string of text fed into the model. Worse, there's currently no 100% reliable defense. You can instruct it in your prompt not to listen, but you can't guarantee it will work every time.
So Stripe's architecture gives "model-generated code" a clear execution boundary: the agent is outside, the code runs inside. If something explodes in there, it can't reach the credentials or data channels outside.
3. Auto-summarization: It cleans up when context gets full
Long, multi-turn conversations have a physical limit: the more you chat, the longer the history you feed the model. It gets expensive and quickly hits the context window ceiling.
Deep Agents' summarization middleware defaults work like this (these defaults are from reading the deepagents source code; Stripe hasn't published their numbers): summarization triggers at 85% context usage. The most recent 10% is preserved verbatim. The middle section is handed to a model to be condensed into a summary. The original raw messages aren't deleted—they're moved to a file in the virtual file system at /conversation_history/, retrievable if needed.
middleware/summarization.py); Stripe tunes these parameters.Stripe's dials here include when to trigger summarization, which model to use for it, and how long the summary should be. They also mention a cost consideration: most people use Kai in short bursts, not one long session, so they want to avoid invalidating large cached context blocks. When the cache misses, those tokens have to be recomputed at full price.
One Engineer, One Week: The Three Layers of Kai
Stripe has spent over a decade building internal tooling, security layers, and deployment support around Ruby and Java. Adopting a Python-native stack means rebuilding that internal scaffolding around a new language—a major investment that's hard to justify upfront.
Kai made the case with results: Anupam, one engineer, one week, produced the first version of Kai, because the hardest part of the agent infrastructure—the part Stripe would have had to build from scratch—was already solved by Deep Agents.
Kai proved definitively that Deep Agents was the right path.
Chrissie · Head of AI Platform, Stripe
Kai has a three-layer architecture.
Top layer: An interface-agnostic API
Kai ships with a web app and a Slack integration, but the real core is the API underneath: The agent is a service here; those interfaces are just custom views of it. The web app was available to all employees on day zero, with zero infrastructure setup required.
Any internal tool can embed Kai, and many teams have done exactly that. If you're working in a BI platform, you can ask Kai directly in that interface. Stripe built a Chrome extension that puts Kai inside web-based third-party tools.
Kai embedded in the sidebar of the internal BI tool (Insights and Forecasting Studio). The user says, "Show me revenue trends by region." Kai builds the chart on the left and lists what it did: net revenue by month, split by region, filtered to current versions, formatted currency. Below that, you can see its collapsed "36 tools" call history, and a short trend analysis it wrote. The region names (Atlantis, Mordor, Westeros) indicate sanitized demo data. Source: stripe.dev.
Middle layer: AgentStudio, a control console for every domain
Domain leads come here to build, test, and monitor their own skills, customizing Kai and its tool selection. For example, the GTM team has a version of Kai tuned specifically for their workflow: it loads their skills by default, connects to their data sources, and formats results the way they're used to. The console also shows usage data and quality signals next to every asset, so domain leads know which skills work—without having to ask the platform team.
The skills page in Agent Studio. The top right shows 34 "areas." You can see the ABP (Admin Business Partner) area has 2 skills, the Bridge area has 6 skills across 5 sub-areas, the Data & AI area has 2 skills across 32 sub-areas, and Finance & Workplace has 0 skills of its own but 35 sub-areas beneath it. These 1,000+ skills are attached hierarchically, and a parent area can have zero skills itself. The "Editor" tag in the bottom right of each card indicates the current user's permission. There are two entry points for building skills: "Create with AI" and "Create in Editor." (Stripe's text uses the compound "AgentStudio"; the product UI writes it as two words. We're matching the screenshot here.) Source: stripe.dev.
Bottom layer: A shared execution environment
The agent harness, sandbox, workflow orchestration, and access control framework are intentionally shared with the agents in Stripe's external products. The logic: internal knowledge work handles data just as sensitive, for the same users. The security and compliance bar shouldn't be lower. Sharing the foundation enforces discipline and creates a flywheel—improvements to the execution environment benefit both internal and product agents.
This layer runs on Kubernetes, with a separate sandbox per session and a multi-tenant virtual file system.
Stripe's official architecture diagram. The two boxes at the top are the consumers: the internal knowledge agent (Kai) and the external product agent. Both feed into the same "secure shared execution environment." The dark purple bar in the middle is the agent harness (running on Kubernetes), responsible for "maintaining context and state across long sessions." Below it, four components: workflow orchestration (planning and coordination), per-session sandbox (isolated code execution), session workspace (virtual files and artifacts, extended state), and context routing (selecting the right skill and tools). At the bottom are 1,000+ skills and tools, leading to Stripe data, team-owned domain workflows, and external services like Google Workspace and Zoom. Source: stripe.dev.
1,000 Skills—How Does the Model Know Which One to Use?
First, what's a skill? In Deep Agents, a skill is a structured, executable module that encodes "how to do a specific type of task," including which tools to load and what approach to take. It follows the Agent Skills standard, which on disk means a directory containing a mandatory SKILL.md: YAML frontmatter at the top (name, one-line description, allowed tools), followed by instructions for the agent. It can also include scripts, templates, and reference docs.
Stripe's approach is federalist: teams own and maintain their own skills. The base Kai ships with a set of foundational skills (covering basic Stripe navigation). Additional skills load in layers based on the user's profile and which customized Kai they're using—someone in Sales Ops gets a different package than Finance. There's a user-level profile layer on top of that, where individuals can add their own skills on top of department defaults.
1000+
Total skills and tools, contributed by 100+ teams
500+
Internal MCP tools, still growing
34
"Areas" skills are grouped into, with sub-areas below
Here's the tension: putting all of them in context is impossible. That would be asking the model to read a phone book before every request.
The solution: Pick a skill first, and the skill brings its tools
In the Agent Skills spec, each skill can declare allowedTools. At startup, Deep Agents injects only each skill's name, one-line description, allowed tools list, and file path into the system prompt. The body of the skill is never read. (This is "progressive disclosure"—like a book that only shows you the table of contents, expanding a chapter when you get to it.) The model decides which skill fits the task. Only then does that skill's allowedTools determine which tool definitions get fully loaded.
middleware/skills.py.The model is already spending effort deciding which skills to load. We just leverage that decision to load the relevant tools too.
Anupam Upadhyay · Engineer, AI Platform, Stripe
A set of base skills are pinned—always there, regardless of what the model decides to load or unload. This keeps Stripe's foundational context and policy behavior consistent at all times.
Then there's the wall: 150
Skill descriptions are capped at 1,024 characters. This is defined by the Agent Skills standard and hardcoded as a constant in Deep Agents' source (MAX_SKILL_DESCRIPTION_LENGTH = 1024 in middleware/skills.py).
Stripe's team tested this and found: Once skill count exceeds 150—combined with their own system prompt—quality from frontier models starts to degrade.
150 skills, each description up to 1,024 characters. That's potentially 150,000+ characters just for the skill list, before you even count the system prompt, tool definitions, or the user's actual question.
The model can remember that much text. The problem is the act of choosing from such a long list. Pick the wrong skill, and the tools that come with it are also wrong. The whole chain goes sideways.
Skill selection is still an open challenge. Stripe is looking for better approaches. The direction is a hybrid selection system. One observation is counterintuitive: at the current scale, letting the model choose directly performs better than RAG—where you'd first use search to pull out the most relevant skills and feed those to the model. The reason: the model makes better decisions with full context. But as the scale grows further, they'll need to add a RAG layer or a classifier to do a coarse pre-filter, letting the model make the final call. The specifics of this hybrid system are left for a follow-up post.
Usage Data: 83% Use It Weekly, Half of All Sessions Are Just 2 Turns
Growth first. After the open preview, Kai hit its quarterly adoption target in a single week. In about 4 weeks, users went from 296 to over 5,000—a 16x increase.
It just took off.
Sharadh Krishnamurthy · Engineering Manager, Agent Foundation, Stripe
The people who picked it up were exactly who they designed for: sales, financial analysts, business operations. These are the people who'd been told to "use AI" but never found a tool that fit how they work. Sharadh relayed a quote from a user: "I felt like the old tool wasn't accessible. There were too many knobs to turn. But the company was asking me to use AI—I really tried." Then: "This one is different. I don't have to turn any knobs."
Current numbers: 83% of Stripe employees use Kai every week. By percentage, Marketing (95%) and GTM (87%) have higher adoption than Engineering.
2×
Account managers ran 2x the sales activities in weeks they used Kai vs. weeks they didn't
+39%
Deal difference for the same people, using vs. not using (opportunities +17%, revenue opps +26%)
25k
Hours per year moved from admin to revenue-generating work
The text says sessions are multi-turn. The chart says the median is 2 turns.
On the question of "how long is a session," the same source material gives two answers.
The text suggests long: "Most Kai sessions require many turns," illustrated with an example that ran 932 turns.
The chart shows the actual distribution across 359,000 sessions.
Stripe's official statistics chart, based on 359,000 sessions and 1.34 million turns. Left: turns per session. Median 2, mean 3.7, p99 is 34. Center: model calls per session. Median 8, mean 15.8, p99 is 131. Right: tool calls per session. Median 9, mean 19.1, p99 is 154. Shaded ranges are p25–p75; dashed lines are means. Source: stripe.dev.
Half of all sessions are just 2 turns. You need to get to the top 1% to hit 34 turns. The caption in the source says, "user behavior is changing, with sessions increasingly used for deep, multi-turn collaboration"—that's about a trend, not the current majority. The 932-turn session is an extreme outlier.
Total session counts don't match either: the text mentions "over 5,000 sessions a day around data analysis" and "over 60,000 sessions" company-wide, while the chart shows 359,000 sessions. The scope difference isn't explained, so we're noting both separately without mixing them.
A 2-turn median session runs 8 model calls underneath
Look at the three charts together: the median 2-turn session runs 8 model calls and 9 tool calls.
Low turn count doesn't mean simple tasks. The user says one thing; the agent does multiple steps—queries data, parses files, drafts output, then revises it. This also explains why those three middleware components are non-negotiable: even a short, 2-turn session runs ~17-18 calls. Files need a home. Code needs a place to run. Context needs managing.
Four Unresolved Problems, and the Framework's Admitted Boundaries
Stripe has a favorite saying: "We haven't won yet." Four things are still being worked on.
An agent like Kai generates a lot of state—repeated tool calls, pulling in large documents. They're constantly balancing two things: the "active" context actually sent to the model, and the "extended" context stored in places like S3 and the virtual file system.
With 500+ tools and 1,000+ skills, no model can reliably choose from a list that size. They need a pre-filter, but pre-filtering risks losing the current advantage of "the model makes better decisions with full context."
With thousands of users, they need to invest in security and compliance guardrails so Kai's reach doesn't outpace regulatory structures.
Some teams want Kai to propose a plan first and ask clarifying questions. Others want quick, direct answers. It's still single-user sessions. On the roadmap: shared skills, shared artifacts, and eventually multiple people (and multiple agents) working on the same output together.
The whole promise of this product is that you don't have to turn knobs. So now that responsibility falls on us. We have to build that intelligence—to make all these judgments for everyone.
Sharadh Krishnamurthy · On why they don't expose the knobs to users
One more detail shows this is still a work in progress: Deep Agents, the foundation Kai is built on, is at version 0.7.4 (released August 4, 2026). Still pre-1.0. And it's iterating fast: 0.7.1 on July 30, 0.7.2 and 0.7.3 on August 3, then 0.7.4 on August 4. Five versions in five days.
Why governance made the backlog: Two facts in the framework's repo
To understand the weight of "governance and guardrails," you have to read the Deep Agents repo. These two items aren't mentioned in either blog post. They come from the threat model doc that LangChain keeps in the repo (libs/deepagents/THREAT_MODEL.md, marked at the top as auto-generated and experimental).
Under "assumptions," the doc states: users who need to isolate untrusted workloads should extend BaseSandbox themselves, or use container/VM-level sandboxing. This library does not provide OS-level process isolation.
This explains why the "one isolated sandbox per session" on Kubernetes had to be built by Stripe. You buy the skeleton; you weld the security boundaries yourself.
Threat item T1 states: skill and memory file contents are injected verbatim into the system prompt, with no filtering, escaping, or content checks performed. If a skill name fails validation, it's just a warning—not a rejection.
In other words, anyone who can write files to the skill directory can modify this agent's behavior. Put that next to "100+ teams each maintaining 1,000+ skills," and you see why "governance and guardrails" made the backlog.
You Can Buy the Agent Skeleton. The Guardrails You Build Yourself.
Stripe used an open-source framework to build Kai, an AI assistant that 83% of employees use weekly. The first version took one engineer a week. Here's what they bought, what they built, and where they hit a wall—all on one page.
↓ Read the whole thing here · includes an animated chart
Kai is Stripe's AI assistant for everyone who doesn't write code. Sales, finance, and ops give it a task in a chat box. It hands back something they can open, edit, and send out. At the end of July, LangChain's blog published a teardown of how it was built, down to the component level.
Stripe's engineers have had coding agents for a while—merging 1,000+ PRs a week. Sales, financial analysts, and ops can't get past the terminal, data permissions, and security approval. Stripe's insight: coding is a fixed shape (edit, test, commit), so one architecture fits all. Knowledge work changes tools, data, and the definition of "done" every single time.
Anyone could drag and drop a small, single-purpose agent. They ended up with 4,000. The problem wasn't the number: many people wrote prompts that were similar in intent but uneven in quality. With so many scattered around, monitoring and maintenance became a nightmare. The other path—non-engineers using coding tools directly—quickly raised security issues and burdened the code quality team.
1,000+ skills from 100+ teams, all on one platform with layered loading: Sales Ops gets a different skill package than Finance. Individuals can stack their own on top of department defaults. Every skill has usage data and quality signals next to it, so domain leads know what works—without asking the platform team.
Kai is built on LangChain's open-source Deep Agents. Think skeleton plus drivetrain: the model invocation loop, state management—all the generic parts you'd have to build from scratch. This is what let one engineer ship a first version in a week. And "one week" means first runnable version. Neither official post says how long it took from there to company-wide adoption, or how many people were involved.
✔ A sandbox interface: The sandbox is a sealed room. Model-written code runs inside. The key is that the agent is outside, calling it as a tool. If something fires in there, it can't reach the credentials or data channels outside.
✔ Automatic context compression: At 85% context use, the system summarizes the middle, keeps the recent 10% verbatim, and files the original text away for later retrieval.
✘ Skill content checks: Skill files go into the system prompt verbatim, with zero filtering or escaping. Anyone who can write to the skill directory can change the agent's behavior.
✘ Guardrails for knowledge work: Coding has compilers, tests, and git. Knowledge work has none of that. Stripe's hard rule: "data from two unrelated customers can't be in the same session"—even if a person has permission to see both.
A skill is a directory containing a SKILL.md: YAML frontmatter (name, one-line description, allowed tools) and the how-to body. Stripe has 1,000+ skills and 500+ internal tools. Loading them all would mean making the model read a phone book before every request.
A skill description is capped at 1,024 characters. 150 skills is potentially 150k+ characters just for the list. The model can remember that; the problem is choosing from a list that long. Stripe says this wall isn't crossed yet. The direction is a hybrid: a search or classifier pre-filter, then the model decides. At the current scale, though, letting the model see the full list beats retrieving a few candidates via RAG.
The open preview hit its quarterly adoption target in a week. In 4 weeks, users went from 296 to 5,000+. They were exactly who it was designed for: sales, financial analysts, business ops.
83%
Of Stripe employees use Kai weekly; Marketing at 95% and GTM at 87% are both higher than Engineering
2
Median turns per session (359k sessions); the top 1% reaches 34 turns
8 / 9
Those 2-turn sessions run 8 model calls and 9 tool calls underneath — about four steps per user sentence
- × Need a terminal
- × No data access
- × Security review
→ Commit
· Compliance
A sealed sandbox
Auto-cleanup for context
1 week
Members can copy or download the full Markdown, and let their AI subscribe and ask.
Found this useful? Leave your email — every new explainer, the moment it's out. Unsubscribe anytime.