Build your own company brain: the enterprise AI playbook from Stripe's engineering team

Why Stripe built its own company brain

The enterprise AI playbook most companies have run so far is a licence rollout. Everyone gets a chat model, the engineers get coding agents, the budget line grows. What does not grow is the share of work an agent can finish on its own, because the agent knows nothing about the company: not who is asking, not which project the question belongs to, not which data can be trusted, not which action needs a second pair of eyes.

Stripe drew the opposite conclusion in early 2026. Sharadh Krishnamurthy, an engineering manager at Stripe, and his colleague Anupam asked how to get AI to everyone at a company with products around the world and a long list of processes that keep it running. Their answer was not more access. “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,” Krishnamurthy says. The result is Kai, an internal company brain and company agent that, at the time of recording, 10,000 or more employees used every week, roughly 86 per cent of the company, with a core experience team of fewer than ten people.¹

I am a co-founder of Teklens. Before that I built Aioma and sold Localina's CRM to Swisscom, and I have taught at ZHAW. Everything about Kai in this article comes from one source: Krishnamurthy's conversation with Claire Vo on How I AI, published on 7 September 2026, including a live demo. The reading of it, and the ordering into ten decisions, is mine.¹

What you will take away: the ten decisions that make Kai work, and which of them do not depend on being Stripe; why the project, not the user, is the right unit of AI governance; how a conversation becomes a skill and what breaks at 2,000 of them; and what the same architecture looks like for a software product team with Jira and a codebase.

The thesis. The enterprise AI advantage does not come from giving everyone the best model. It comes from giving the model the right context, tools, workflows and boundaries, without making employees manage any of them.

Why does one company AI layer beat a hundred copilots?

Because context is the expensive part, and it only pays off if it is shared. Kai knows out of the box who you are and where you sit in the org chart. Through standard connectors it reads the project management system: OKRs, recent ship emails, the projects you are part of. If you allow it, it reads your Google Drive, your Slack and your private messages. The employee decides how much. Krishnamurthy says he turns his own access off and on again, session by session, while many colleagues take the view that more context is better.¹

A hundred disconnected copilots each rebuild that context from nothing, and each one asks its user to make the same decisions: which model, which connector, which permission. Stripe's design goal is the opposite. A few people who understand the trade-offs between cost, performance and latency set the stage; everyone else asks for the outcome. “We should try to minimise the number of people who have to actively make these choices every day,” Krishnamurthy says.¹

This is the first point most internal AI projects miss. Hiding complexity is not a courtesy to the user. It is what makes the governance enforceable. If the marketer has to remember to switch on the right connector, the marketer will forget. If the setting lives in the project, nobody has to remember. I described the smallest stack that carries context for a product team in AI tools for product managers; Stripe's answer is one stack for the whole company.

Kai is also, deliberately, not a laptop tool. It runs in the cloud, is always on, sits behind Stripe's standard security boundaries, and the infrastructure built for it becomes the standard infrastructure Stripe uses to build agents for its own customers. The security team likes that. So does the argument for building it yourself: the dogfooding is the point, not a side effect.¹

What makes a project the unit of governance?

A project is the place where someone with intent writes down what an agent may do. Kai's project holds the relevant context and skills, the allowed tools and connectors, the default model and cost limits, permissions, which actions need a human confirmation, and the security boundary. Some projects have 500 members, some five. Some exist for a short-lived initiative, some for a team.¹

Two things make this more than a folder of chats. First, intent. When a user opens a project they are telling the agent what they are trying to do, and Krishnamurthy calls that a strong signal that lets the AI perform much better. Second, the settings are shared. Most tools let an individual configure connectors and approvals, but the configuration applies to every session of that one person and cannot be handed to a team. In Kai, the person responsible for a space decides once, for everyone who works there.¹

The people team is the example he uses. HR deals with sensitive data and should not have an agent that could put it into a document every Stripe employee can read. The naive fix is to switch tools off for HR. The project fix is a tool policy: the sensitive tool stays available, but in that project it runs with a human-in-the-loop confirmation, while the same tool in a lower-risk project runs without one. The people team also runs a “super secure version” of Kai backed by a separate backend. A project can be powered by a custom agent, a different API and a different harness while keeping the same interface.¹

The principle behind it deserves its own paragraph, because most teams get it wrong in one of two directions. Confirmation on every tool call destroys usability. No confirmation is dangerous. Stripe applies approvals at the project and tool-policy level, so a calendar invite in a demo project asks for a click and the same call in another context may not. Krishnamurthy's warning about the alternative: “If you put too much friction in front of people, they're just going to do unsafe things, because that's how humans are.” Show the same dialog for every tool in every session and eventually someone presses the wrong button.¹

Token spend lives at the same level. A project can set the default model and rule out the expensive ones when the work does not need them. Model choice becomes a project setting made by someone who knows the trade-offs, not a per-employee lottery. I made the same argument from the vendor-independence side in Model dependency: why model-agnostic workflows become a board matter.¹

How do skills turn one conversation into company IP?

A skill packages the tools, instructions and best practices for one workflow so an agent can run it again. In Kai, a user who has finished a workflow, say the dashboard from the demo, asks a skill-creator skill to take everything learned in the session and package it. Kai fills in the description and when it should be used, opens a draft editor that feels like a small IDE, and the author decides whether the skill stays private or is published to a team or the company. The format is an open spec that runs on any harness, so the skill is not locked into Kai.^1,2

This is the jump from “AI helped me once” to “this is now how our company performs this task”. Krishnamurthy calls it the moment the AI goes from something you iterate with on the side to something you can trust to run a workflow. It is also the one reason for Kai's product-market fit that generalises to any company: the value of a skill is captured by the team, not by the person who happened to figure it out. What a good skill file contains is the subject of Skill files: the next AI skill after prompting.¹

Stripe now has roughly 2,000 skills, and the next problem is not creation. It is retrieval. A coding agent has a natural hierarchy: you are in a repository, in a folder, and the skills for that place load. An employee starting work in an enterprise has no such hierarchy; they are typically touching five systems at once. So a large part of Stripe's investment went into automatically finding the right skills for the current user and task, and into rigorous checks that the right ones were invoked, rather than loading everything into context.¹

The principle is the one product teams keep relearning. “The more unrelated context you throw into the AI, the less good your results are going to be. So quantity is almost a facet of quality,” Krishnamurthy says. Jörg Schad at Pinecone makes the same point from the other side: context works as an asset when it is curated once, versioned and permissioned, not reassembled from everything on every query.^1,3

So skills need governance too. Stripe's telemetry shows about 50 skills that are hammered every day across the company, a long tail of 100 to 150 used by parts of the organisation, and a set of tools used by two or three people. All three deserve to exist; a three-person squad doing something bespoke should be able to share among themselves. The pipeline behind the numbers tells the harness owners which skills to promote into the general workflow and which to move out because they only take up context. Authors get automatic suggestions on how to improve their skill. Claire Vo adds what she sees other teams doing: tool-call failure telemetry that feeds evals, and a deprecation policy where an unused skill gets a notice, then archive status, then deletion. Think of it as an internal app store with telemetry, evals and, eventually, retirement.¹

Why does your existing infrastructure decide how good your agents get?

Because agents amplify whatever they find. The strongest section of the episode is not about AI at all. Stripe invested for years in developer experience, a data catalogue with tiering, a resilient query layer on Trino, a blessed analytics layer for key metrics, and standard dashboards. “These investments were made for humans, but have held up really well for agents,” Krishnamurthy says. Vo's advice to any leader who asks how to ship more with AI: double the size of your DevEx team and your data team.¹

The Ask Data skill shows how that infrastructure turns into agent behaviour. Its instructions, written by Stripe's data scientists, set a hierarchy: use an existing trusted artefact first, then the governed analytics layer, then the vetted queries behind standard dashboards, and only then search the data catalogue and write new SQL. Agents are good at answering a question and bad at knowing whether it was the right table. The hierarchy removes most of the guessing, reduces hallucinated queries, and keeps agents from brute-forcing the warehouse. Vo's summary: when in doubt, an agent will brute force it, so the warehouse has to survive high query volume.¹

Which brings the warning I would put on the wall of any team introducing agents. “It turns out that agents just dial up all your failure modes. It just multiplies the amplitude of problems you can get.” Poor APIs get overwhelmed. Fragile infrastructure gets hammered. Weak permission models become security risks. Stripe had agents that went rogue and agents that “may have almost taken down core systems”, caught in time, and the response was infrastructure: agent identities that say what an agent is and what it is trying to do, priorities and load shedding based on that identity, rate controls, sandboxes and tool policies. The DORA 2025 report found the same shape at the organisational level: AI amplifies the strengths of well-run teams and the dysfunctions of struggling ones.^1,4

The sandbox is what makes the power safe enough for everyone. Kai can write and run code, analyse data and manipulate files inside a secure cloud sandbox isolated per session, so two employees' work cannot “eat each other”. Non-engineers get coding-agent capabilities without running anything on a laptop, and, as Krishnamurthy puts it, they do not even need to know the sandbox exists. He himself does not always know what script the agent wrote. He knows it is secure, and he checks the result.¹

What does a company brain actually do for an employee?

It builds the small application that person needed. The demo is deliberately ordinary: “Build me the latest Kai adoption dashboard.” Kai finds the Ask Data skill, discovers the existing queries, reads governed data, writes a script in its sandbox, and returns an interactive dashboard that, to its author's surprise, came out in Stripe's colours. Then the user iterates: add this query, break it down by team, do something with the data rather than only display it. The artefact is not thrown away each turn. Stripe sees sessions with hundreds of turns over several weeks.¹

The interesting bit is not the dashboard. It is that any employee can create a bespoke light application around their workflow without understanding the code, the tools or the data architecture underneath. Most data work is last-mile work: every workflow differs, no central team can build and maintain a dashboard for each, and the alternative has always been a thousand stale dashboards nobody trusts. Krishnamurthy now generates a dashboard for every meeting he runs. The marketing team, Vo notes, is all in, because no marketer has ever had enough apps or dashboards.¹

The rollout is as instructive as the product. Stripe did not start with an enterprise AI programme. Krishnamurthy and a colleague built V0 in about two weeks with one and a half engineers, because it was impossible to explain why this was needed in a world full of coding agents until people could see it. A pilot of 200 to 300 users followed, driven largely by the go-to-market side, with two and a half to three people on the team. Then a company-wide demo, and the steep part of the adoption curve. Today 10,000 or more employees use Kai weekly and the core team is still under ten people, helped by coding agents, an internal DevEx team and the infrastructure above. He is careful to say that a lot of people help those ten do what they do.¹

What is the bigger lesson, and where does it stop?

The architecture is the transferable part, and it is a stack, not a chatbot. Kai looks like a single product; Krishnamurthy calls it the icing on a multi-layer cake, where each layer can be customised for the enterprise. Reading the episode, the layers are these.¹

Company brain, the interface. One place where employees ask for outcomes.

User and organisational context. Who is asking, where they sit, what they are working on, and what they have chosen to share.

Projects. Intent plus governance boundary: context, skills, tools, model, cost, permissions, approvals.

Skills. Reusable workflows, authored from sessions, shared by team or company.

Skill routing, evals and telemetry. The right skills for the task, and the pipeline that promotes, scopes and retires them.

Tools, connectors and APIs. What the agent can do, subject to the project's policy.

Secure sandbox. Where code runs and files live, isolated per session.

Company infrastructure and data. The layer everything above depends on, with agent identities, rate controls and a trusted data hierarchy.

Read top to bottom, this is much closer to an operating layer for the company than to a chat tool. Read bottom to top, it explains why the team is small: every layer below the interface existed, in some form, before Kai.

That is also where the playbook stops being copyable. The numbers are Stripe's own, from a prepared demo, and Krishnamurthy says himself that they are in the earliest part of the journey and may show something completely different in a year. More important, the two weeks and one and a half engineers bought the interface, not the cake. A mid-sized company with a grown codebase, Jira, Confluence and a data warehouse that nobody has hardened for brute-force queries has the same problem Stripe had and none of the layers. Building the harness is the cheap part. Building the context, the governance model and the skill lifecycle is the work, and it does not get cheaper by starting from a chat window.¹

Which brings the article back to the licence rollout in the first paragraph. Giving everyone the best model is the part that is solved. Giving the model the right context, tools, workflows and boundaries, without asking employees to manage any of them, is the part that is not, and it is the part Stripe's playbook is actually about.

Do it like Stripe, for the software product lifecycle

This is the one place Teklens belongs in this article, and the parallel is closer than I expected when I started listening. Stripe calls Kai a company brain. For a software product team the same thing is a Product Brain: shared memory for people and agents that keeps customer feedback, product decisions, Jira and the code connected and current. Stripe applies the architecture above to the whole company. Teklens applies the same shape to the software product lifecycle: Decision → Spec → Plan → Build → Review → Shipped software.

Layer by layer: the Product Brain is the shared context, built from Jira, Confluence, GitHub and files, curated once and kept current. An initiative in Teklens is Stripe's project. It carries the intent, the sources an agent may read, the model choice per project, the cost limits, and the human quality gates that say which results a named person approves before they move on. Activities and skills are Stripe's skills: reusable workflows with an owner, an input from the Product Brain, an assigned agent and a defined result, configured in Skill Studio and checked against the real code. Humans steer and approve. Agents do the work. Managed model access and AI spend management are in beta; hosting is in Switzerland and the EU.

Stripe had one and a half engineers, two weeks and a decade of infrastructure. If your product team has Jira, a codebase and coding agents, and one person who holds it all together by hand, you do not need to build the layers yourself. We publish names and numbers only with permission, so there is no metric here. Show us exactly how product work happens today and we will tell you honestly whether the Stripe shape fits it: book a call with a founder. Jira and your repository are connected in the first hour.

Frequently asked questions

Recommendations

• Count your copilots, then pick one layer. List every AI tool that carries its own connectors and permissions. The ones that rebuild the same context are candidates for one shared layer.
• Write your first project as a governance boundary. For one team: allowed sources, allowed tools, default model, cost cap, and the two or three actions that need a human. If it fits on one page, it can be enforced.
• Turn one finished workflow into a skill this week. Give it an owner, a description of when to use it, and a place where the team can find it.
• Put the data hierarchy in writing. Trusted report, then governed metric, then vetted query, then raw data. Hand it to the agent as instructions before you hand it the warehouse.
• Give every agent an identity and a sandbox before you give it a second tool. Rate limits and load shedding are cheaper than the outage.
• Measure skill usage from day one. Promote what the company uses, scope what a squad uses, retire what nobody uses.

Scope & caveats

• Everything about Kai comes from one podcast conversation (How I AI, 7 September 2026) with a prepared live demo; it is Stripe's own account. The figures (10,000-plus weekly users, roughly 86 per cent adoption, about 2,000 skills, one and a half engineers and two weeks for V0, a pilot of 200 to 300 users, a core team under ten, about 50 daily and 100 to 150 long-tail skills) are as stated on the show and not independently verified. Krishnamurthy says himself that Stripe is in the earliest part of this journey.
• The ten decisions and the layer list are my reading and ordering of the episode, not Stripe's own framework. The deprecation policy (notice, archive, delete) is Claire Vo's description of practice at other companies, not something Stripe showed.
• The DORA 2025 finding on AI as an amplifier is about software delivery organisations in general, not about agents in enterprise infrastructure specifically; I use it as a parallel. The Pinecone description is the vendor's account of its own product.
• Teklens statements describe product capabilities, not measured customer results. Managed AI model access and AI spend management are in beta. Names and figures only with permission.

Sources

Every external figure and quote in this piece – linked so you can verify it.

1. 1.Sharadh Krishnamurthy mit Claire Vo, «Build your own company brain: the enterprise AI playbook from Stripe's engineering team», How I AI, 7. September 2026 ↗ – The only source on Kai. Why build from 03:15, projects from 07:49, the data layer and “multiplies the amplitude” from 15:16, the rollout from 25:19, skills and tool policies from 29:16, skill retrieval and telemetry from 38:13.
2. 2.Anthropic Docs, «Agent Skills» ↗ – The open skill format most harnesses read; the show describes Kai's export as an open spec without naming it.
3. 3.Jörg Schad mit Kevin Ball, «Moving Beyond RAG with Precomputed Context», Software Engineering Daily, 3. September 2026 ↗ – Context as a precomputed, versioned, permissioned artefact at 07:04 and 09:58.
4. 4.DORA, «State of AI-assisted Software Development Report 2025» (Google Cloud) ↗ – AI as an amplifier: it strengthens well-run organisations and sharpens the dysfunctions of the rest.

Keep reading in the PM Lab

Related deep dives – from the same pillar and the adjacent phases.

Matching use cases from the library

From the article straight into practice: these use cases put the concepts to work with Teklens.