ExpertsFMBuild your own company brain: the enterprise AI playbook from Stripe’s engineering team | Sharadh Krishnamurthy
How I AI · September 7, 2026
5 Selected Lessons:
heuristic · 2 framework · 1 reasoning_pattern · 1 case · 1
Tool policies as scoped permission boundaries
Source
How I AI — Build your own company brain: the enterprise AI playbook from Stripe’s engineering team | Sharadh Krishnamurthy (September 7, 2026) · at 0:00 ▸ · at 30:30 ▸ · at 32:39 ▸
When this applies
when giving any autonomous agent access to sensitive data or powerful actions across a diverse user base
The takeaway
Grant capability at the narrowest scope that still lets the task get done, rather than choosing between full access and no access.
Why it works
Scoping which tools an agent may use per workflow (rather than a blanket on/off) lets sensitive work stay safe without blocking all AI usefulness for that team.
One level up
Safety and usability are not opposites once you can scope permissions granularly enough.
Where it stops holding
This stops working when you can't cleanly enumerate which tools/workflows are sensitive, or when scoping overhead itself becomes the bottleneck.
Detail
procedure:
- Identify a workflow/team with sensitive data exposure risk
- Define a project boundary around that workflow
- Set a tool policy restricting which tools the agent can invoke in that context
- Allow human-in-the-loop confirmation for flagged sensitive actions
- Leave default (non-sensitive) workflows frictionless
benchmarks: {}
rationale: Prevents agents from exfiltrating sensitive data (e.g., into public docs) while still letting the team use AI productively.
In their words
Let's say you're a person on the HR team who's dealing with a bunch of sensitive information. You really don't want the agent to son of a go rogue and put that sensitive data into some public Google document that all Stripes can access, but you also don't want to tell them, oh, you can't use any tools because your workloads are too sensitive.
Stay calm and iteratively correct the AI rather than escalate frustration
Source
How I AI — Build your own company brain: the enterprise AI playbook from Stripe’s engineering team | Sharadh Krishnamurthy (September 7, 2026) · at 47:33 ▸
When this applies
when any AI tool's output is wrong or off-target and the user must correct it
The takeaway
Treat correction of an AI's mistake as a precise re-specification task, not an emotional confrontation — tone doesn't change the model's processing, only your own friction.
Why it works
Calm, specific restatement of intent (rather than emotional escalation) gives the model clearer corrective signal and preserves a cooperative interaction pattern, since shouting adds no information the model can use.
One level up
Effective iteration with any imperfect system depends on clear restatement, not escalation.
Where it stops holding
This stops working when the AI's errors stem from missing capability/context rather than ambiguous phrasing, in which case no amount of calm rephrasing fixes it.
Detail
approach: Respond to AI mistakes with polite, specific restatement ('that's not what I wanted, here, I'm going to say it again') rather than shouting.
signals:
- repeated AI misunderstanding
- frustration building
rationale: Shouting at the AI feels wrong, 'almost like I'm shouting at the people who built the AI'; insisting calmly and clearly works better for him.
In their words
I don't like shouting at the AI. It feels, it feels wrong. Almost like I'm shouting at the people who built the AI. So, maybe, but I just insist.
Evaluate build-vs-buy by friction and bespoke-ness of use case
Source
How I AI — Build your own company brain: the enterprise AI playbook from Stripe’s engineering team | Sharadh Krishnamurthy (September 7, 2026) · at 32:39 ▸ · at 35:13 ▸
When this applies
when any organization decides whether to build custom infrastructure or adopt a generic off-the-shelf solution
The takeaway
Choose build over buy when your use cases are varied enough that uniform configuration would create meaningful friction or risk; choose buy when a generic solution's defaults are 'good enough' for most of your workflows.
Why it works
Off-the-shelf tools apply uniform settings across all sessions/users, while bespoke infra can hide complexity behind context-specific defaults — so the deciding factor is how much inappropriate friction a generic tool would introduce for your specific workflows.
One level up
The right level of customization is determined by how heterogeneous your real use cases are, not by a general preference for control.
Where it stops holding
This stops working when the organization lacks the engineering capacity to build and maintain bespoke infra, making 'buy' the only realistic option regardless of fit.
Detail
rule: Ask yourself how much appropriate or inappropriate friction will this put in everybody's day-to-day work before deciding to build vs buy.
threshold: qualitative — tied to how bespoke/varied the use cases are
rationale: You want management requirements to go down, not require everyone to think about connectors/permissions per task.
In their words
when people are asking themselves either, should I build something myself and does that make a lot of sense, or do I need to pluck something off the shelf for my enterprise use case, again, you need to ask yourself how much appropriate or inappropriate friction will this put in everybody's day to day work
User-controlled context ingestion as a privacy/trust lever
Source
How I AI — Build your own company brain: the enterprise AI playbook from Stripe’s engineering team | Sharadh Krishnamurthy (September 7, 2026) · at 5:19 ▸
When this applies
when designing any system that personalizes based on sensitive user data
The takeaway
Make sensitive-data context ingestion an explicit, revocable user choice rather than an all-or-nothing system default.
Why it works
Letting individual users opt in/out of giving the system access to sensitive personal data (rather than forcing full or no access) respects varying personal risk tolerance while maximizing usefulness for those willing to share more.
One level up
Trust in a personalized system is built by giving users granular control over what they expose, not by maximizing default access.
Where it stops holding
This stops working when the system needs guaranteed access to certain data to function at all (making opt-out non-viable), or when too much per-session toggling itself becomes a friction/complexity burden.
Detail
rule: Default to minimal personalized context (identity + org chart) but let users opt into deeper, sensitive context (Slack, email, Drive) per session.
threshold: n/a — described as a per-user, per-session toggle
rationale: Different people have different comfort levels; some want maximum AI context, others (like Sharadh himself) turn access on/off daily.
In their words
We allow people to select how much they give CHI access to, but out of the box, CHI knows who you are and where do you sit in the org chart.
Last-mile data workflows via agent-generated light apps
Source
How I AI — Build your own company brain: the enterprise AI playbook from Stripe’s engineering team | Sharadh Krishnamurthy (September 7, 2026) · at 20:46 ▸
When this applies
when an organization faces a proliferation problem of needing countless narrow, personalized tools/reports that can't all be pre-built and maintained
The takeaway
Use on-demand agent-generated artifacts to solve 'last mile' customization problems instead of trying to pre-build for every variant centrally.
Why it works
Letting any employee direct an agent to manipulate data and generate a bespoke lightweight app/dashboard on demand avoids the unmanageable alternative of building and maintaining a dashboard for every possible workflow variant.
One level up
When demand for customization is combinatorially large, shift creation to the point of need rather than centralizing it.
Where it stops holding
This stops working when data quality/governance can't be guaranteed for ad hoc agent-generated outputs, or when proliferation of one-off artifacts itself becomes unmanageable without the skill-tiering/pruning system described elsewhere.
Detail
situation: People's data workflows are so varied ('last mile data') that building a dashboard for every job is impractical and leads to unmanageable dashboard sprawl.
decision: Give everyone, regardless of coding skill, a secure sandbox where the agent can write code and manipulate data on their behalf to build custom light apps.
outcome: Users (e.g., marketing team) adopted this heavily, generating dashboards per-meeting and iterating over hundreds of turns across weeks.
lesson: Agent-driven, on-demand artifact creation can resolve the long tail of personalized needs that centralized tooling cannot scale to cover.
In their words
It's so hard to build a dashboard for everyone to do every part of their job. And then you have like a gazillion dashboards and how do you manage them? You can't keep the right dashboards at the right level of quality.