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.