Bau dein eigenes Company Brain: das Enterprise-AI-Playbook von Stripes Engineering-Team

Warum Stripe sein eigenes Company Brain gebaut hat

Das Enterprise-AI-Playbook, das die meisten Firmen bisher gefahren haben, ist ein Lizenz-Rollout. Alle bekommen ein Chat-Modell, die Engineers bekommen Coding-Agents, die Budgetzeile wächst. Was nicht wächst, ist der Anteil der Arbeit, den ein Agent allein zu Ende bringen kann, weil der Agent nichts über die Firma weiss: nicht, wer fragt, nicht, zu welchem Projekt die Frage gehört, nicht, welchen Daten man trauen kann, nicht, welche Aktion ein zweites Augenpaar braucht.

Stripe hat Anfang 2026 den umgekehrten Schluss gezogen. Sharadh Krishnamurthy, Engineering Manager bei Stripe, und sein Kollege Anupam fragten sich, wie man KI zu allen bringt, in einer Firma mit Produkten rund um die Welt und einer langen Liste von Prozessen, die sie am Laufen halten. Ihre Antwort war nicht mehr Zugang. «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», sagt Krishnamurthy. Das Ergebnis ist Kai, ein internes Company Brain und Firmen-Agent, den zum Zeitpunkt der Aufnahme 10'000 oder mehr Mitarbeitende pro Woche nutzten, rund 86 Prozent der Firma, mit einem Kernteam für die Experience von weniger als zehn Leuten.¹

Ich bin Mitgründer von Teklens. Davor habe ich Aioma aufgebaut und Localinas CRM an Swisscom verkauft, und ich habe an der ZHAW unterrichtet. Alles über Kai in diesem Beitrag stammt aus einer Quelle: Krishnamurthys Gespräch mit Claire Vo in How I AI, veröffentlicht am 7. September 2026, inklusive Live-Demo. Die Lesart und die Ordnung in zehn Entscheide sind meine.¹

Was du mitnimmst: die zehn Entscheide, die Kai funktionieren lassen, und welche davon nicht davon abhängen, Stripe zu sein; warum das Projekt und nicht der Nutzer die richtige Einheit für AI-Governance ist; wie aus einem Gespräch ein Skill wird und was bei 2'000 davon bricht; und wie dieselbe Architektur für ein Software-Produktteam mit Jira und einer Codebase aussieht.

Die These. Der Vorsprung bei Enterprise AI kommt nicht daher, dass alle das beste Modell bekommen. Er kommt daher, dass das Modell den richtigen Kontext, die richtigen Werkzeuge, Workflows und Grenzen bekommt, ohne dass Mitarbeitende irgendetwas davon verwalten müssen.

Warum schlägt ein AI-Layer für die Firma hundert Copilots?

Weil Kontext der teure Teil ist und sich nur auszahlt, wenn er geteilt wird. Kai weiss von Haus aus, wer du bist und wo du im Organigramm sitzt. Über Standard-Konnektoren liest es das Projektmanagement-System: OKRs, aktuelle Ship-Mails, die Projekte, an denen du beteiligt bist. Wenn du es erlaubst, liest es dein Google Drive, deinen Slack und deine privaten Nachrichten. Wie viel, entscheidet der Mitarbeitende. Krishnamurthy sagt, er schalte seinen eigenen Zugang Session für Session aus und wieder ein, während viele Kolleginnen und Kollegen finden, mehr Kontext sei besser.¹

Hundert unverbundene Copilots bauen diesen Kontext jeder für sich aus dem Nichts auf, und jeder verlangt von seinem Nutzer dieselben Entscheide: welches Modell, welcher Konnektor, welche Berechtigung. Stripes Designziel ist das Gegenteil. Wenige Leute, die die Abwägungen zwischen Kosten, Leistung und Latenz verstehen, bereiten die Bühne; alle anderen fragen nach dem Ergebnis. «We should try to minimise the number of people who have to actively make these choices every day», sagt Krishnamurthy.¹

Das ist der erste Punkt, den die meisten internen KI-Projekte verpassen. Komplexität zu verstecken ist keine Höflichkeit gegenüber dem Nutzer. Es ist das, was die Governance durchsetzbar macht. Wenn die Marketerin daran denken muss, den richtigen Konnektor einzuschalten, wird sie es vergessen. Wenn die Einstellung im Projekt liegt, muss niemand daran denken. Den kleinsten Stack, der für ein Produktteam Kontext trägt, habe ich in KI-Tools für Product Manager beschrieben; Stripes Antwort ist ein Stack für die ganze Firma.

Kai ist ausserdem bewusst kein Laptop-Werkzeug. Es läuft in der Cloud, ist immer an, sitzt hinter Stripes Standard-Sicherheitsgrenzen, und die Infrastruktur, die dafür gebaut wurde, wird zur Standard-Infrastruktur, mit der Stripe Agents für die eigenen Kunden baut. Das Security-Team mag das. Und es stützt das Argument fürs Selberbauen: Das Dogfooding ist der Punkt, nicht ein Nebeneffekt.¹

Was macht ein Projekt zur Einheit der Governance?

Ein Projekt ist der Ort, an dem jemand mit einer Absicht aufschreibt, was ein Agent tun darf. Kais Projekt hält den relevanten Kontext und die Skills, die erlaubten Werkzeuge und Konnektoren, das Standardmodell und die Kostenlimits, Berechtigungen, die Aktionen, die eine menschliche Bestätigung brauchen, und die Sicherheitsgrenze. Manche Projekte haben 500 Mitglieder, manche fünf. Manche existieren für ein kurzlebiges Vorhaben, manche für ein Team.¹

Zwei Dinge machen daraus mehr als einen Ordner voller Chats. Erstens die Absicht. Wer ein Projekt öffnet, sagt dem Agent, was er zu tun versucht, und Krishnamurthy nennt das ein starkes Signal, mit dem die KI deutlich besser arbeitet. Zweitens sind die Einstellungen geteilt. Die meisten Werkzeuge lassen eine Einzelperson Konnektoren und Freigaben konfigurieren, aber die Konfiguration gilt für jede Session dieser einen Person und lässt sich keinem Team übergeben. In Kai entscheidet die Person, die für einen Bereich verantwortlich ist, einmal, für alle, die dort arbeiten.¹

Das People-Team ist sein Beispiel. HR arbeitet mit sensiblen Daten und sollte keinen Agent haben, der sie in ein Dokument legen könnte, das jeder Stripe-Mitarbeitende lesen kann. Die naive Lösung schaltet die Werkzeuge für HR ab. Die Projekt-Lösung ist eine Tool Policy: Das sensible Werkzeug bleibt verfügbar, läuft in diesem Projekt aber mit einer Human-in-the-Loop-Bestätigung, während dasselbe Werkzeug in einem risikoärmeren Projekt ohne läuft. Das People-Team betreibt zudem eine «super secure version» von Kai mit einem separaten Backend. Ein Projekt kann von einem eigenen Agent, einer anderen API und einem anderen Harness angetrieben werden und behält dasselbe Interface.¹

Das Prinzip dahinter verdient einen eigenen Absatz, weil die meisten Teams es in eine von zwei Richtungen falsch machen. Eine Bestätigung bei jedem Tool-Aufruf zerstört die Nutzbarkeit. Keine Bestätigung ist gefährlich. Stripe setzt Freigaben auf der Ebene von Projekt und Tool Policy an, sodass eine Kalendereinladung im Demo-Projekt einen Klick verlangt und derselbe Aufruf in einem anderen Kontext vielleicht nicht. Krishnamurthys Warnung vor der 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.» Zeig denselben Dialog für jedes Werkzeug in jeder Session, und irgendwann drückt jemand den falschen Knopf.¹

Der Token-Verbrauch liegt auf derselben Ebene. Ein Projekt kann das Standardmodell setzen und die teuren ausschliessen, wenn die Arbeit sie nicht braucht. Die Modellwahl wird zur Projekteinstellung von jemandem, der die Abwägungen kennt, statt zur Lotterie pro Mitarbeitenden. Dasselbe Argument habe ich von der Seite der Anbieterunabhängigkeit in Modell-Abhängigkeit: Warum modell-agnostische Workflows zur Chefsache werden gemacht.¹

Wie machen Skills aus einem Gespräch Firmen-IP?

Ein Skill packt die Werkzeuge, Anweisungen und Best Practices für einen Workflow so zusammen, dass ein Agent ihn wieder ausführen kann. In Kai bittet ein Nutzer, der einen Workflow abgeschlossen hat, etwa das Dashboard aus der Demo, einen Skill-Creator-Skill, alles aus der Session Gelernte zu verpacken. Kai füllt die Beschreibung aus und wann der Skill zu nutzen ist, öffnet einen Entwurfs-Editor, der sich wie eine kleine IDE anfühlt, und der Autor entscheidet, ob der Skill privat bleibt oder für ein Team oder die Firma veröffentlicht wird. Das Format ist eine offene Spec, die auf jedem Harness läuft, der Skill ist also nicht an Kai gebunden.^1,2

Das ist der Sprung von «KI hat mir einmal geholfen» zu «so erledigt unsere Firma diese Aufgabe jetzt». Krishnamurthy nennt es den Moment, in dem die KI von etwas, mit dem man nebenbei iteriert, zu etwas wird, dem man einen Workflow anvertrauen kann. Es ist auch der eine Grund für Kais Product-Market-Fit, der sich auf jede Firma übertragen lässt: Den Wert eines Skills behält das Team, nicht die Person, die ihn zufällig herausgefunden hat. Was in einer guten Skill-Datei steht, ist das Thema von Skill Files: Die nächste KI-Kompetenz nach dem Prompting.¹

Stripe hat inzwischen rund 2'000 Skills, und das nächste Problem ist nicht das Erstellen. Es ist das Finden. Ein Coding-Agent hat eine natürliche Hierarchie: Du bist in einem Repository, in einem Ordner, und die Skills für diesen Ort werden geladen. Ein Mitarbeitender, der in einem Unternehmen mit der Arbeit beginnt, hat keine solche Hierarchie; er fasst typischerweise fünf Systeme gleichzeitig an. Ein grosser Teil von Stripes Investition floss deshalb darin, die richtigen Skills für den aktuellen Nutzer und die aktuelle Aufgabe automatisch zu finden und rigoros zu prüfen, dass die richtigen aufgerufen wurden, statt alles in den Kontext zu laden.¹

Das Prinzip ist das, das Produktteams immer wieder neu lernen. «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», sagt Krishnamurthy. Jörg Schad von Pinecone macht denselben Punkt von der anderen Seite: Kontext funktioniert als Asset, wenn er einmal kuratiert, versioniert und mit Berechtigungen versehen ist, nicht bei jeder Anfrage aus allem neu zusammengesetzt.^1,3

Also brauchen auch Skills Governance. Stripes Telemetrie zeigt rund 50 Skills, die jeden Tag firmenweit gehämmert werden, einen Long Tail von 100 bis 150, die Teile der Organisation nutzen, und eine Reihe von Werkzeugen, die zwei oder drei Personen verwenden. Alle drei haben ihre Berechtigung; ein Dreier-Squad, das etwas Massgeschneidertes tut, soll untereinander teilen können. Die Pipeline hinter den Zahlen sagt den Harness-Verantwortlichen, welche Skills in den allgemeinen Workflow befördert werden sollen und welche hinaus, weil sie nur Kontext belegen. Autoren bekommen automatische Vorschläge, wie sie ihren Skill verbessern können. Claire Vo ergänzt, was sie bei anderen Teams sieht: Telemetrie zu fehlgeschlagenen Tool-Aufrufen, die in Evals fliesst, und eine Deprecation-Regel, bei der ein ungenutzter Skill eine Meldung bekommt, dann den Archiv-Status, dann die Löschung. Stell es dir als internen App Store mit Telemetrie, Evals und irgendwann Ausmusterung vor.¹

Warum entscheidet eure bestehende Infrastruktur, wie gut eure Agents werden?

Weil Agents verstärken, was sie vorfinden. Der stärkste Abschnitt der Folge handelt gar nicht von KI. Stripe hat über Jahre in Developer Experience investiert, in einen Datenkatalog mit Tiering, eine belastbare Abfrageschicht auf Trino, eine freigegebene Analytics-Ebene für die wichtigen Kennzahlen und Standard-Dashboards. «These investments were made for humans, but have held up really well for agents», sagt Krishnamurthy. Vos Rat an jede Führungskraft, die fragt, wie sie mit KI mehr ausliefert: Verdoppelt euer DevEx-Team und euer Datenteam.¹

Der Skill Ask Data zeigt, wie diese Infrastruktur zu Agent-Verhalten wird. Seine Anweisungen, geschrieben von Stripes Data Scientists, legen eine Hierarchie fest: zuerst ein bestehendes, vertrauenswürdiges Artefakt nutzen, dann die gepflegte Analytics-Ebene, dann die geprüften Queries hinter den Standard-Dashboards, und erst dann den Datenkatalog durchsuchen und neues SQL schreiben. Agents sind gut darin, eine Frage zu beantworten, und schlecht darin zu wissen, ob es die richtige Tabelle war. Die Hierarchie nimmt den grössten Teil des Ratens weg, reduziert halluzinierte Queries und hält Agents davon ab, das Warehouse mit roher Gewalt zu durchsuchen. Vos Fazit: Im Zweifel geht ein Agent mit Brute Force vor, also muss das Warehouse hohes Abfragevolumen überleben.¹

Womit wir bei der Warnung wären, die ich jedem Team, das Agents einführt, an die Wand hängen würde. «It turns out that agents just dial up all your failure modes. It just multiplies the amplitude of problems you can get.» Schwache APIs werden überrannt. Fragile Infrastruktur wird gehämmert. Schwache Berechtigungsmodelle werden zu Sicherheitsrisiken. Stripe hatte Agents, die ausser Kontrolle gerieten, und Agents, die «may have almost taken down core systems», rechtzeitig abgefangen, und die Antwort war Infrastruktur: Agent-Identitäten, die sagen, was ein Agent ist und was er zu tun versucht, Prioritäten und Load Shedding auf Basis dieser Identität, Rate Controls, Sandboxes und Tool Policies. Der DORA-Report 2025 fand dieselbe Form auf Organisationsebene: KI verstärkt die Stärken gut geführter Teams und die Dysfunktionen der anderen.^1,4

Die Sandbox macht die Leistung sicher genug für alle. Kai kann in einer sicheren Cloud-Sandbox, die pro Session isoliert ist, Code schreiben und ausführen, Daten analysieren und Dateien bearbeiten, sodass sich die Arbeit zweier Mitarbeitender nicht «gegenseitig auffrisst». Nicht-Engineers bekommen die Fähigkeiten eines Coding-Agents, ohne etwas auf einem Laptop laufen zu lassen, und, wie Krishnamurthy sagt, sie müssen nicht einmal wissen, dass die Sandbox existiert. Er selbst weiss nicht immer, welches Skript der Agent geschrieben hat. Er weiss, dass es sicher ist, und er prüft das Ergebnis.¹

Was tut ein Company Brain konkret für einen Mitarbeitenden?

Es baut die kleine Anwendung, die diese Person gebraucht hat. Die Demo ist bewusst gewöhnlich: «Build me the latest Kai adoption dashboard.» Kai findet den Skill Ask Data, entdeckt die bestehenden Queries, liest gepflegte Daten, schreibt ein Skript in seiner Sandbox und liefert ein interaktives Dashboard, das zur Überraschung seines Autors in Stripes Farben herauskam. Dann iteriert der Nutzer: füge diese Query hinzu, brich es nach Team herunter, mach etwas mit den Daten, statt sie nur anzuzeigen. Das Artefakt wird nicht bei jedem Zug weggeworfen. Stripe sieht Sessions mit Hunderten von Zügen über mehrere Wochen.¹

Das Interessante ist nicht das Dashboard. Es ist, dass jeder Mitarbeitende eine massgeschneiderte kleine Anwendung um seinen Workflow bauen kann, ohne den Code, die Werkzeuge oder die Datenarchitektur darunter zu verstehen. Die meiste Datenarbeit ist Last-Mile-Arbeit: Jeder Workflow ist anders, kein zentrales Team kann für jeden ein Dashboard bauen und pflegen, und die Alternative waren schon immer tausend veraltete Dashboards, denen niemand traut. Krishnamurthy erzeugt heute für jedes Meeting, das er leitet, ein Dashboard. Das Marketing-Team, merkt Vo an, sei voll dabei, weil noch nie eine Marketerin genug Apps oder Dashboards hatte.¹

Der Rollout ist so lehrreich wie das Produkt. Stripe hat nicht mit einem Enterprise-AI-Programm begonnen. Krishnamurthy und ein Kollege bauten V0 in rund zwei Wochen mit anderthalb Engineers, weil sich in einer Welt voller Coding-Agents nicht erklären liess, wozu das nötig ist, bis die Leute es sehen konnten. Ein Pilot mit 200 bis 300 Nutzern folgte, stark getrieben von der Go-to-Market-Seite, mit zweieinhalb bis drei Leuten im Team. Dann eine firmenweite Demo und der steile Teil der Adoptionskurve. Heute nutzen 10'000 oder mehr Mitarbeitende Kai wöchentlich, und das Kernteam hat immer noch weniger als zehn Leute, unterstützt von Coding-Agents, einem internen DevEx-Team und der Infrastruktur oben. Er betont, dass viele Leute diesen zehn helfen, das zu tun, was sie tun.¹

Was ist die grössere Lektion, und wo hört sie auf?

Übertragbar ist die Architektur, und sie ist ein Stack, kein Chatbot. Kai sieht aus wie ein einzelnes Produkt; Krishnamurthy nennt es die Glasur auf einem mehrschichtigen Kuchen, bei dem jede Schicht für das Unternehmen angepasst werden kann. Beim Hören der Folge ergeben sich diese Schichten.¹

Company Brain, das Interface. Ein Ort, an dem Mitarbeitende nach Ergebnissen fragen.

Nutzer- und Organisationskontext. Wer fragt, wo die Person sitzt, woran sie arbeitet und was sie zu teilen beschlossen hat.

Projekte. Absicht plus Governance-Grenze: Kontext, Skills, Werkzeuge, Modell, Kosten, Berechtigungen, Freigaben.

Skills. Wiederverwendbare Workflows, aus Sessions erstellt, pro Team oder Firma geteilt.

Skill-Routing, Evals und Telemetrie. Die richtigen Skills für die Aufgabe, und die Pipeline, die sie befördert, eingrenzt und ausmustert.

Werkzeuge, Konnektoren und APIs. Was der Agent tun kann, im Rahmen der Projekt-Policy.

Sichere Sandbox. Wo Code läuft und Dateien liegen, pro Session isoliert.

Firmeninfrastruktur und Daten. Die Schicht, von der alles darüber abhängt, mit Agent-Identitäten, Rate Controls und einer vertrauenswürdigen Datenhierarchie.

Von oben nach unten gelesen ist das viel näher an einer Betriebsebene für die Firma als an einem Chat-Werkzeug. Von unten nach oben gelesen erklärt es, warum das Team klein ist: Jede Schicht unter dem Interface gab es in irgendeiner Form schon vor Kai.

Genau dort hört das Playbook auf, kopierbar zu sein. Die Zahlen sind Stripes eigene, aus einer vorbereiteten Demo, und Krishnamurthy sagt selbst, sie seien am Anfang der Reise und zeigten in einem Jahr vielleicht etwas völlig anderes. Wichtiger: Die zwei Wochen und anderthalb Engineers haben das Interface gekauft, nicht den Kuchen. Ein mittelgrosses Unternehmen mit gewachsener Codebase, Jira, Confluence und einem Data Warehouse, das niemand gegen Brute-Force-Abfragen gehärtet hat, hat dasselbe Problem wie Stripe und keine der Schichten. Den Harness zu bauen ist der billige Teil. Kontext, Governance-Modell und Skill-Lebenszyklus zu bauen ist die Arbeit, und sie wird nicht billiger, wenn man bei einem Chatfenster anfängt.¹

Womit der Beitrag zum Lizenz-Rollout im ersten Absatz zurückkommt. Allen das beste Modell zu geben ist der gelöste Teil. Dem Modell den richtigen Kontext, die richtigen Werkzeuge, Workflows und Grenzen zu geben, ohne von Mitarbeitenden zu verlangen, irgendetwas davon zu verwalten, ist der ungelöste, und genau davon handelt Stripes Playbook.

Mach es wie Stripe, für den Software-Produkt-Lebenszyklus

Das ist die eine Stelle, an die Teklens in diesem Beitrag gehört, und die Parallele ist enger, als ich beim ersten Hören erwartet habe. Stripe nennt Kai ein Company Brain. Für ein Software-Produktteam heisst dasselbe Ding Product Brain: ein gemeinsames Gedächtnis für Menschen und Agents, das Kundenfeedback, Produktentscheide, Jira und den Code verbunden und aktuell hält. Stripe wendet die Architektur oben auf die ganze Firma an. Teklens wendet dieselbe Form auf den Software-Produkt-Lebenszyklus an: Entscheid → Spec → Plan → Build → Review → ausgelieferte Software.

Schicht für Schicht: Das Product Brain ist der gemeinsame Kontext, aufgebaut aus Jira, Confluence, GitHub und Dateien, einmal kuratiert und laufend aktuell gehalten. Ein Vorhaben in Teklens ist Stripes Projekt. Es trägt die Absicht, die Quellen, die ein Agent lesen darf, die Modellwahl pro Projekt, die Kostenlimits und die menschlichen Quality Gates, die festlegen, welche Ergebnisse eine benannte Person freigibt, bevor es weitergeht. Activities und Skills sind Stripes Skills: wiederverwendbare Workflows mit Owner, einem Input aus dem Product Brain, einem zugewiesenen Agent und einem definierten Ergebnis, im Skill Studio konfiguriert und am echten Code geprüft. Menschen steuern und geben frei. Agents erledigen die Arbeit. Kontrollierter Modellzugang und AI Spend Management sind in der Beta; gehostet wird in der Schweiz und der EU.

Stripe hatte anderthalb Engineers, zwei Wochen und ein Jahrzehnt Infrastruktur. Wenn euer Produktteam Jira, eine Codebase und Coding-Agents hat, und eine Person, die das alles von Hand zusammenhält, müsst ihr die Schichten nicht selbst bauen. Namen und Zahlen veröffentlichen wir nur mit Freigabe, deshalb steht hier keine Metrik. Zeigt uns genau, wie eure Produktarbeit heute abläuft, und wir sagen euch ehrlich, ob die Stripe-Form dazu passt: Buch einen Call mit einem Founder. Jira und euer Repository sind in der ersten Stunde verbunden.

Häufige Fragen

Empfehlungen

• Zähl eure Copilots, dann wähl einen Layer. Liste jedes KI-Werkzeug auf, das eigene Konnektoren und Berechtigungen mitbringt. Die, die denselben Kontext neu aufbauen, sind Kandidaten für einen gemeinsamen Layer.
• Schreib euer erstes Projekt als Governance-Grenze. Für ein Team: erlaubte Quellen, erlaubte Werkzeuge, Standardmodell, Kostendeckel und die zwei, drei Aktionen, die einen Menschen brauchen. Passt es auf eine Seite, lässt es sich durchsetzen.
• Mach diese Woche aus einem abgeschlossenen Workflow einen Skill. Gib ihm einen Owner, eine Beschreibung, wann er zu nutzen ist, und einen Ort, an dem das Team ihn findet.
• Schreib die Datenhierarchie auf. Vertrauter Report, dann gepflegte Kennzahl, dann geprüfte Query, dann Rohdaten. Gib sie dem Agent als Anweisung, bevor du ihm das Warehouse gibst.
• Gib jedem Agent eine Identität und eine Sandbox, bevor du ihm ein zweites Werkzeug gibst. Rate Limits und Load Shedding sind billiger als der Ausfall.
• Miss die Skill-Nutzung vom ersten Tag an. Befördere, was die Firma nutzt, grenze ein, was ein Squad nutzt, und mustere aus, was niemand nutzt.

Einordnung & Grenzen

• Alles über Kai stammt aus einem Podcast-Gespräch (How I AI, 7. September 2026) mit vorbereiteter Live-Demo; es ist Stripes eigene Darstellung. Die Zahlen (über 10'000 wöchentliche Nutzer, rund 86 Prozent Adoption, rund 2'000 Skills, anderthalb Engineers und zwei Wochen für V0, ein Pilot mit 200 bis 300 Nutzern, ein Kernteam unter zehn, rund 50 tägliche und 100 bis 150 Long-Tail-Skills) sind so, wie sie in der Folge genannt wurden, und nicht unabhängig geprüft. Krishnamurthy sagt selbst, Stripe stehe am Anfang dieser Reise.
• Die zehn Entscheide und die Schichtenliste sind meine Lesart und Ordnung der Folge, kein Framework von Stripe. Die Deprecation-Regel (Meldung, Archiv, Löschung) ist Claire Vos Beschreibung der Praxis anderer Firmen, nichts, was Stripe gezeigt hat.
• Der DORA-Befund 2025 zu KI als Verstärker betrifft Software-Delivery-Organisationen allgemein, nicht Agents in Unternehmensinfrastruktur im Besonderen; ich nutze ihn als Parallele. Die Beschreibung von Pinecone ist die Darstellung des Anbieters seines eigenen Produkts.
• Die Teklens-Aussagen beschreiben Fähigkeiten des Produkts, keine gemessenen Kundenresultate. Kontrollierter Modellzugang und AI Spend Management sind in der Beta. Namen und Zahlen erst mit Freigabe.

Quellen

Jede externe Zahl und jedes Zitat in diesem Beitrag – nachprüfbar verlinkt.

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 ↗ – Die einzige Quelle zu Kai. Warum bauen ab 03:15, Projekte ab 07:49, Datenschicht und «multiplies the amplitude» ab 15:16, Rollout ab 25:19, Skills und Tool Policies ab 29:16, Skill-Retrieval und Telemetrie ab 38:13.
2. 2.Anthropic Docs, «Agent Skills» ↗ – Das offene Skill-Format, das die meisten Harnesses lesen; die Folge beschreibt Kais Export als offene Spec, ohne sie zu benennen.
3. 3.Jörg Schad mit Kevin Ball, «Moving Beyond RAG with Precomputed Context», Software Engineering Daily, 3. September 2026 ↗ – Kontext als vorberechnetes, versioniertes Artefakt mit Berechtigungen ab 07:04 und 09:58.
4. 4.DORA, «State of AI-assisted Software Development Report 2025» (Google Cloud) ↗ – KI als Verstärker: stärkt gut geführte Organisationen und verschärft die Dysfunktionen der anderen.

Weiterlesen im PM Lab

Verwandte Deep Dives – aus demselben Pillar und den angrenzenden Phasen.

Passende Use Cases aus der Bibliothek

Vom Beitrag direkt in die Praxis: Diese Use Cases setzen die Konzepte mit Teklens um.