Kategorie: Einblicke

Stell dir vor, du arbeitest an einem Projekt. Am Abend schließt du den Laptop, und die Codierungsagentur läuft einfach weiter – in einer Cloud-Sandbox. Unterwegs wirfst du einen Blick auf das Terminal von deinem Handy aus. Am nächsten Morgen öffnest du die IDE und setzt genau dort fort, wo du aufgehört hast. Kein Export, kein Import, kein Neustart der Gedanken. Für die Entwickler von Kiro ist genau das die Vision von agentischer Entwicklung: Eine einzige durchgehende Konversation über alle Oberflächen hinweg, egal ob du im Terminal arbeitest, im Browser oder in einer nativen App.

Lange Zeit war diese Vision allerdings nicht mehr als ein Wunschbild. Der Grund lag nicht in fehlenden Client-Apps, sondern in der Architektur dahinter. Die Kiro-IDE, das Kiro-CLI und das Web-Interface betrieben jeweils einen eigenen Agenten mit eigenem Session-Format, eigenen Werkzeugen und eigenem Konfigurationsmodell. Eine Session, die in einem Client begann, konnte nicht in einem anderen weiterlaufen, weil die Agenten zu wenig gemeinsame Basis hatten. Genau diese Geschichte erzählt der neue Tech-Blogbeitrag des Teams: wie die drei getrennten Agent-Codebasen zu einer einzigen Kiro-Agent-Harness zusammengeführt wurden – und welche Architekturentscheidungen die ursprüngliche Vision nun in greifbare Nähe rücken.

Drei Clients, drei Agenten, dreifacher Aufwand

Am Anfang stand bewusstes Tempo. Als Kiro gestartet wurde, optimierte das Team auf schnelle Experimente. Jedes Client-Team bekam die Freiheit, seine eigene Agent-Harness zu bauen. Die IDE entwickelte ihre in TypeScript, passend zum Code-OSS-Erweiterungsmodell. Das CLI setzte auf Rust, weil dort Performance zählt. Und das Web-Team wählte Python, um näher an der aktuellen Agentenforschung zu sein. Diese Aufteilung erlaubte schnelle, unabhängige Releases – aber sie erzeugte auch eine Menge verborgener Kosten.

Denn die Teams trafen unterschiedliche Entscheidungen. Die Session-Speicherung funktionierte in jedem Client anders. Die Berechtigungssysteme wurden unabhängig entworfen und verwendeten inkompatible Syntaxen: Das CLI nutzte regex-basierte allowedCommands und deniedCommands, die IDE setzte auf Präfix-Matching bei trustedCommands und Substring-Matching bei der Denylist. Auch die Strategien zur Kompaktierung von langen Kontexten gingen auseinander. Sub-Agenten teilten Kontext auf unterschiedliche Weise, und Custom Agents verhielten sich je nach Client anders. Schließlich drifteten auch die Feature-Sets auseinander: Spezifikationsgetriebene Entwicklung und Powers gab es nur in der IDE, Plan-Modus und Code-Intelligenz nur im CLI.

Der Preis dafür wuchs mit jeder neuen Funktion. Jede Fähigkeit musste dreimal gebaut und gewartet werden, oft mit leicht abweichendem Verhalten. Jeder Bug musste dreimal gefixt werden. Und die Nutzer bekamen je nach gewähltem Client ein anderes Produktgefühl. Mehr noch: Die eigentliche Vision war architektonisch unmöglich. Ohne gemeinsames Session-Format, ohne gemeinsamen Werkzeugsatz und ohne gemeinsames Konfigurationsmodell konnten Sessions nicht zwischen Clients und Rechenumgebungen wandern. Es fehlte schlicht die gemeinsame Sprache.

Die Entscheidung: Eine Harness statt drei

Eine mögliche Lösung wäre gewesen, Verträge über das Agentenverhalten zwischen den Clients zu definieren und diese Verträge in allen drei Harnesses zu implementieren. Das hätte die Unabhängigkeit der Teams bewahrt. Aber es hätte auch bedeutet, dass jede neue Funktion eine Spezifikation, drei Implementierungen und eine laufende Validierung benötigt, dass sich die Implementierungen wirklich gleich verhalten. Der Koordinationsaufwand wäre mit jedem Feature gewachsen.

Der Wendepunkt kam, als Kiro sich auf den öffentlichen Start im Web vorbereitete. Statt den Web-Client mit einem weiteren separaten Agenten zu launchen und die wachsenden Implementierungskosten weiterzutragen, entschied sich das Team für den radikalen Schritt: eine einzige Agent-Harness, die das Beste aus allen drei bisherigen Ansätzen vereint. Eine einzige Harness beseitigt die Duplikation zwischen den Teams und konzentriert die gesamte Entwicklungsarbeit an einem Ort.

Eine zentrale Architekturentscheidung war dabei, die Harness als eigenständigen Serverprozess zu bauen – nicht als Bibliothek, die in jeden Client einkompiliert wird. Aus früheren Versuchen wusste das Team, dass gemeinsame Bibliotheken keine starke Grenze erzwingen. Client-Code ruft schnell interne Methoden auf, die gar nicht für den Export gedacht waren, oder legt eigene Agentenlogik oben auf die Bibliothek. Dann ist man zurück bei divergierenden Implementierungen. Ein eigenständiger Prozess macht die Trennung real: Die Harness und die Clients müssen nicht dieselbe Sprache oder Laufzeit teilen, und jeder Client kann in dem Stack bleiben, der zu seiner Plattform passt.

Wie die neue Architektur aussieht

Vorher gab es drei eng gekoppelte Paare aus Client und Agent: den IDE-Agenten in TypeScript, den CLI-Agenten in Rust und den Web-Agenten in Python. Jetzt gibt es eine saubere Trennung. Auf der einen Seite stehen die Clients mit UX, Darstellung, Nutzerinteraktion und plattformspezifischen Werkzeugen. Auf der anderen Seite steht die Kiro-Agent-Harness, die den Agent-Loop verwaltet, Werkzeuge ausführt, Sub-Agenten delegiert, Session-State hält, als MCP-Client fungiert, Konfiguration lädt, Berechtigungen prüft und Telemetrie sammelt. Die einzige Möglichkeit, diese Grenze zu überschreiten, ist das definierte Protokoll.

Weil die Harness ein eigenständiger Prozess ist und keine eingebundene Bibliothek, kann sie auf jeder Rechenumgebung laufen. Dieselbe Harness startet auf deinem Laptop oder in einer VM in der Cloud, ohne dass der Client davon wissen muss. Das wohldefinierte Interface zwischen Server und Client erlaubt es, die Agentenlogik unabhängig von den Clients weiterzuentwickeln. Wenn eine Änderung an der Harness das Protokoll nicht berührt – etwa ein neues Werkzeug, eine verbesserte Planung oder eine Optimierung des Agent-Loops – dann wird sie sofort in jedem Client wirksam, ohne dass dort auch nur eine Zeile geändert werden muss.

Ein konkretes Beispiel nennt der Beitrag: Vor kurzem wurde ein Live-Reload für Custom Agents eingeführt. Wenn du eine Datei unter .kiro/agents/ mitten in einer Sitzung bearbeitest, erkennt die Harness die Änderung sofort und teilt dem Client die neuen verfügbaren Befehle mit. Dafür war keine einzige Client-Änderung nötig, weil der Benachrichtigungstyp für verfügbare Befehle bereits im Protokoll existierte. Jeder Client hat das Feature dadurch automatisch erhalten.

Nicht Einheitsbrei, sondern Anpassung

Trotz der zentralen Harness wird das System nicht zum Einheitsbrei. Die Entwickler betonen, dass verschiedene Clients unterschiedliche Fähigkeiten haben und einige Operationen auf Client-Ebene besser aufgehoben sind. Der Client kann eigene Werkzeuge bereitstellen und eingebaute der Harness unterdrücken. Die IDE nutzt zum Beispiel die Dateizugriffs-APIs von Code OSS und stellt eigene Lese- und Schreibwerkzeuge bereit, anstatt die direkten Dateisystem-Werkzeuge der Harness zu verwenden. Wenn der Agent eines dieser client-seitigen Werkzeuge ausführen möchte, benachrichtigt er den Client, der die Ausführung übernimmt und das Ergebnis zurückgibt.

Diese Flexibilität ist wichtig, weil die Harness für ganz unterschiedliche Umgebungen gebaut wurde. Ein Terminal hat andere Bedürfnisse als eine grafische IDE, und eine mobile App wiederum andere als eine Webanwendung. Die Architektur zwingt nicht alle in dasselbe Schema, sondern definiert einen gemeinsamen Kern und lässt an den Rändern Platz für Plattform-Eigenheiten. Das ist kein Widerspruch, sondern die eigentliche Stärke des Ansatzes: Einheitlichkeit dort, wo sie Verhalten und Konfiguration betrifft, und Vielfalt dort, wo die Darstellung und Interaktion es verlangt.

ACP als Protokoll der Wahl

Für die Grenze zwischen Client und Harness wählte das Team das Agent Client Protocol, kurz ACP. Das ist ein standardisiertes Spezifikationsformat für die Kommunikation zwischen Agenten und Clients, das im Juni 2026 die Version 1.0 erreicht hat. ACP wird in IDEs wie JetBrains-Produkten, Xcode und Zed unterstützt, aber auch in Obsidian, Emacs und Neovim. Die Kiro-Entwickler hatten bereits Erfahrung mit ACP gesammelt, als sie es im CLI einführten, um Kiro direkt in diesen Anwendungen nutzbar zu machen.

Zwei Eigenschaften von ACP machten es zur passenden Grundlage: die Erweiterbarkeit für eigene Methoden und die Flexibilität bei den Transportwegen. Standardmäßig unterstützt ACP stdio als Transport, was für lokale Clients gut funktioniert, bei denen die Harness als Kindprozess des Editors oder Terminals läuft. Für entfernte Clients wie Kiro im Web oder die iOS-App war ein anderer Transport nötig. Das Team ergänzte einen eigenen WebSocket-basierten Transport, damit diese Clients sich mit einer Harness in einer Cloud-Sandbox verbinden können. Die Binärdatei, die Werkzeuge und das Agentenverhalten bleiben dabei identisch, egal welchen Transport ein Client verwendet.

Über die Transportfrage hinaus erweiterte das Team die ACP-Methoden zu dem, was sie Kiro-ACP nennen. Standard-ACP deckt die Grundlagen ab: Session-Lebenszyklus, Message-Streaming und Meldung von Werkzeugaufrufen. Doch Kiro benötigt mehr. Ein Beispiel ist das Live-Steering: ein Nutzer kann während der Arbeit des Agenten eine Nachricht senden, die in den nächsten Inferenz-Schritt eingefügt wird, um die Richtung zu beeinflussen, ohne die laufende Aktion abzubrechen. ACP unterstützt das Einreihen von Nachrichten nicht von Haus aus, daher ergänzte Kiro neue Methoden-Eigenschaften und Benachrichtigungen. Auch der spezifikationsgetriebene Entwicklungsablauf wurde als eigener Methodensatz modelliert, die einfache Werkzeugfreigabe von ACP zu einem mehrstufigen Berechtigungssystem ausgebaut und Benachrichtigungen für Kontextfenster-Auslastung und Hook-Ausführung hinzugefügt. Insgesamt kommen so mehr als 20 agent-aufrufbare Methoden, 15 client-aufrufbare Methoden und 20 Benachrichtigungstypen zur Basisprotokoll hinzu.

Die Sauberkeit dieser Erweiterungen liegt im Namespace-Konzept von ACP. Eigene Methoden verwenden laut Spezifikation einen Unterstrich-Präfix, und alle Kiro-Erweiterungen liegen unter _kiro/. Dadurch kann das Team das Protokoll für Kiro-spezifische Funktionen erweitern, ohne es zu forken. Drittanbieter-Clients können sich auf dieselbe Weise verbinden wie die eigenen Client-Anwendungen. Jeder ACP-kompatible Client erhält den vollen Agenten mit Werkzeugen, Sub-Agenten, Session-Verwaltung und MCP-Konnektivität. Die ersten Parteien – IDE, CLI, Web und iOS – nutzen zusätzlich die Kiro-ACP-Erweiterungen für Live-Steering, Spezifikationen, eine reichhaltige Berechtigungsoberfläche und Kontext-Tracking.

Was sich dadurch konkret ändert

Der unmittelbarste Nutzen der einheitlichen Harness ist, dass Funktionen, die vorher nur in einem Client existierten, nun überall verfügbar sind – mit demselben Konfigurationsformat und demselben Verhalten. Spezifikationsgetriebene Entwicklung war früher nur in der IDE möglich. Jetzt läuft sie auch im CLI, wo man sie mit /spec new startet, und in Kiro im Web. Der Agent übernimmt dabei die Interaktion mit dem Sprachmodell und die automatisierten Denkschritte, die für den Ablauf nötig sind: Anforderungen generieren, einen technischen Entwurf produzieren, Arbeit in Aufgaben zerlegen. Jeder Client präsentiert das Ergebnis so, wie es zu seiner Form passt. Die IDE zeigt die Spezifikationsartefakte in seitlichen Panels, das CLI rendert sie im Terminal, und die Web-Version stellt sie im Browser mit Inline-Review und Mehrbenutzer-Zusammenarbeit dar. Der Agent spricht ACP, und der Client entscheidet, wie er die Ausgabe präsentiert.

Auch Custom Agents profitieren von der Vereinheitlichung. Sie verwenden auf allen Oberflächen dasselbe Markdown-Format unter .kiro/agents/. Eine Agent-Definition enthält Beschreibung, System-Prompt, tag-basierte Werkzeugauswahl, zugängliche Sub-Agenten, Inline-MCP-Serverdefinitionen und Inline-Berechtigungsregeln. Wenn du die Konfiguration eines Custom Agents in die Versionskontrolle eincheckst, bekommt jedes Teammitglied sie in jedem Client. Kein separater Export, kein manuelles Einrichten, keine Syntax-Unterschiede mehr.

Für Entwickler bedeutet das eine spürbare Vereinfachung im Alltag. Eine einmal definierte Agentenkonfiguration funktioniert überall gleich. Eine Sitzung, die im Web beginnt, kann in der IDE weitergeführt werden, weil die Harness den Zustand hält und der Client nur die Darstellung wechselt. Die lästige Frage, in welchem Tool ein bestimmtes Feature verfügbar ist, verschwindet zunehmend. Stattdessen wächst das Vertrauen, dass das Verhalten des Agenten nicht davon abhängt, ob man gerade im Terminal, im Browser oder in der IDE arbeitet.

Natürlich ist eine einheitliche Harness kein Allheilmittel. Die Architektur verschiebt Komplexität, sie löst sie nicht auf. Die Protokollgrenze muss sauber gepflegt werden, und Erweiterungen wie Kiro-ACP brauchen eine klare Versionierung, damit Drittanbieter nicht abgehängt werden. Auch die Entscheidung, die eigene Agentenlogik in einem separaten Prozess zu halten, verlangt Disziplin bei der Gestaltung des Interfaces. Doch der eingeschlagene Weg macht die ursprüngliche Vision zumindest technisch erreichbar: eine kontinuierliche agentische Konversation, die sich über alle Oberflächen erstreckt, mit einer Harness, die überall läuft. Das ist kein Hype, sondern solide Architekturarbeit – und genau die Art von Fundament, auf der man als Entwickler gerne aufbaut.

Quelle: kiro.dev

Jeder kennt dieses Gefühl: Jemand schickt ein Video, man hat keine Zeit, es anzuschauen, und liest stattdessen die Zusammenfassung. Meistens reicht das. Aber manchmal bleibt ein Rest Unsicherheit zurück. Hat man etwas Entscheidendes verpasst? Genau an dieser Stelle setzt der Entwickler des Open-Source-Tools „claude-real-video“ an. In seinen Engineering Notes beschreibt er, warum es einen fundamentalen Unterschied macht, ob ein Sprachmodell einen Text über ein Video bekommt oder das Video selbst.

Eine Zusammenfassung ist nicht das Ereignis

Ein Video ist kein Artikel über das Video. Wer ein Video einmal gesehen hat, hat eine Kompression des Geschehens in der Hand. Ein Mensch hat zugeschaut, entschieden, was wichtig war, und den Rest verworfen. Das Framing, das Timing, Details am Bildrand, die niemand notiert hat – all das fehlt im Text. Wenn ein LLM einen solchen Artikel liest, bewegt es sich innerhalb der Entscheidungen des Autors. Es kann nichts zurückholen, was geschnitten wurde, und es kann eine Auswahl nicht infrage stellen, die es nie gesehen hat.

Gibt man dem Modell stattdessen das Video, verschiebt sich die Kompression auf das Modell selbst. Der Entwickler beschreibt diesen Unterschied als den zwischen dem Lesen einer Zeugenaussage und dem selbst vor Ort sein. Das Modell sieht, wie das Demo tatsächlich aussah, nicht wie ein Rezensent es beschrieben hat. Es bemerkt die Fehlermeldung, die in einem Tutorial kurz aufblitzt und die keiner transkribiert hat. Es erkennt, dass die „schnelle Einrichtung“ elf Schnitte gebraucht hat. Dasselbe Thema, sehr verschiedene Positionen. Genau deshalb sind die Token-Budget und die Auswahl der Frames so entscheidend.

Das Token-Budget setzt die Grenzen

Der größte Teil dessen, was heute als Video-Understanding verkauft wird, ist ein Transkript plus Frames, die per Timer gezogen werden – ein Frame pro Sekunde, manchmal nur alle zehn Sekunden. Uniform Sampling scheitert gleich in beide Richtungen: Es begräbt das Modell unter fast identischen Frames eines sprechenden Kopfes und überspringt genau die eine Sekunde, in der sich etwas verändert hat. Die Ursache ist beide Male dieselbe: Der Sampler hat keine Ahnung, was sich geändert hat.

Die harte Randbedingung ist das Token-Budget. Bilder sind die teuerste Sache, die man in einen Kontext legen kann. Wenn man einmal akzeptiert, dass nur etwa 100 bis 150 Frames pro Video Platz haben, hört die Extraktion auf, das Problem zu sein. Die Selektion ist das Problem. Jeder behaltene Frame muss sich seinen Platz verdienen. Der Rest des Artikels dreht sich darum, wie man diesen Platz gut vergibt – mit Szenenerkennung, Deduplizierung und einer sauberen Fusion des Transkripts.

Szenenerkennung: Der gleitende Durchschnitt schlägt den fixen Schwellwert

Der erste Durchlauf ist Standard: ffmpegs Scene-Score. Ein Frame wird bei jedem Szenenwechsel gezogen, plus eine niedrige Mindestdichte, damit eine lange, ungeschnittene Einstellung nicht leer ausgeht. Alles in einem chronologischen Durchlauf, weil die Deduplizierung später echte Nachbarn vergleichen will. Feste Schwellwerte scheitern allerdings an einer bestimmten Sorte von Inhalt: Animation und langsame Kamerabewegung.

Eine Cartoon-Figur, die sich dehnt und staucht, oder ein langsamer Schwenk verändert das Bild ständig, aber nie abrupt. Der Score überschreitet die Linie nicht, und der Sampler schläft durch die ganze Szene. Die Lösung klingt langweilig, funktioniert aber: Man berechnet die Scene-Scores frame-weise in einem reinen Metadaten-Durchlauf und behält einen Frame immer dann, wenn sein Score ein Vielfaches des rollierenden Durchschnitts übertrifft. Bewegungsintensives Material hebt die Latte, ruhiges senkt sie. Niemand muss manuell etwas tunen.

Deduplizierung: Aus einem Kanal wurden drei

Die Deduplizierung startete als ein einziger Vergleicher. Jedes Mal, wenn echtes Videomaterial ihn vorführte, kam ein Kanal dazu. Der erste Kanal ist der globale: Er skaliert das Bild auf eine 16×16-RGB-Signatur herunter und zählt die Zellen, die sich in irgendeinem Kanal um mehr als 25/255 verändert haben. Sinkt die Zahl der veränderten Zellen unter etwa acht Prozent, wird der Frame verworfen.

Wichtig ist dabei RGB und nicht Graustufen, weil ein Rot-Grün-Schnitt mit gleicher Luminanz für einen Graustufen-Vergleich unsichtbar bleibt. Außerdem vergleicht der Kanal gegen ein Fenster der letzten vier behaltenen Frames und nicht nur gegen den unmittelbaren Vorgänger. Sonst re-admittiert ein A-B-A-Schnitt – Interview, Reaktionsshot, zurück zum Interview – einen bereits gesehenen Shot, nur weil dazwischen ein anderer Frame lag.

Der zweite Kanal: Kleine Subjekte, starke Veränderung

Ein prozentualer Schwellwert ist strukturell blind für kleine Motive. Ein Mensch, der im Weitwinkel nur 0,5 Prozent der Bildfläche einnimmt, kann niemals acht Prozent der Pixel verändern, egal was er tut. Der eine relevante Moment wird also wegdedupliziert. Der Entwickler hat dieses Problem nicht in einem Benchmark gefunden. Ein Nutzer entdeckte es, nachdem das Tool über 2.181 reale Videos gelaufen war.

Der Patch arbeitet auf einem 32×32-Raster. Wenn dort auch nur eine Handvoll Zellen sich hart verändern – also mehr als 45/255 –, gilt der Frame unabhängig vom Prozentsatz als neu. Kleines Motiv, scharfe Änderung, wird behalten. Das ist die Lektion, die sich durch die ganze Deduplizierung zieht: Prozentwerte allein sagen nichts über Bedeutung aus, wenn die Veränderung klein und konzentriert ist.

Der dritte Kanal: Der ruhige Blick auf den Zustand

Der globale Kanal kann außerdem kleine lokale Zustandsänderungen nicht sehen: einen Untertitelwechsel, eine Linie Tinte auf dem Whiteboard, ein aktualisiertes UI-Element. Auf der 16×16-Skala messen solche Änderungen praktisch null. Der dritte Kanal arbeitet deshalb mit einer 192×192-Signatur und sucht Pixel, die sich stark von jedem Frame im behaltenen Fenster unterscheiden. Eine Verschiebung von plus/minus einem Pixel ist erlaubt, weil Filmkorn, Sensor-Jitter und Bildrauschen sonst überall Änderungen melden.

Die Schutzmechanismen sind hier wichtiger als der Detektor. Der Kanal läuft nur, wenn die Szene sonst statisch ist, weil Bewegung die Aufgabe der anderen Kanäle ist. Dazu kommen zwei weitere Bremsen. Kandidaten-Pixel müssen eine zweite, strengere Toleranzprüfung bestehen. Das filtert weiche Kontrastverläufe heraus – etwa Rauch, der sich auflöst –, während Tinte und Text ihren harten Kern behalten. Und jeder ausgelöste Treffer hebt die Schwelle wieder an, mit einem abklingenden Cooldown. So kann ein flackerndes Element nicht immer wieder Frames für sich beanspruchen, während eine einzelne Texteinblendung normal durchkommt.

Was am Ende zählt

Die Summe ist überschaubarer, als es die Details vermuten lassen. Keyframes plus ein zusammengeführtes Transkript reichen für den Alltagsfall aus: das Modell soll sich das Ding wirklich ansehen, bevor es antwortet. Dafür braucht es keinen Dienst in der Cloud. Das läuft vollständig auf der eigenen Maschine.

Quelle: leoaido.com

Stell dir vor, du hast einen persönlichen Assistenten, der für dich Termine plant, Einkäufe erledigt und E-Mails schreibt. Damit er das kann, braucht er Zugang zu deinem Kalender, deinem Bankkonto, deinen Kontakten. Und wehe, er muss für jede Aufgabe einen anderen Schlüssel finden. Genau vor diesem Problem stehen Unternehmen, wenn sie KI-Agenten in ihre Arbeitsabläufe integrieren. Es geht nicht um einen einzelnen Schlüssel, sondern um dutzende Türen. DoorDash hat dafür ein zentrales Tor gebaut: ein Agent Gateway.

In einem technischen Blogbeitrag beschreiben die Software-Engineers Siddarth Kodwani und Vasily Vlasov, wie dieses Gateway die Art und Weise verändert, wie KI-Agenten auf interne und externe Werkzeuge zugreifen. Das Besondere daran ist nicht die Erfindung eines neuen Protokolls, sondern eine klare Plattform, die die vielen Einzelprobleme der Tool-Anbindung löst. Es geht um Zugriff, Sichtbarkeit und Kontrolle – und das, ohne dass jede Anwendung das Rad neu erfinden muss.

Vom Protokoll zum Produktionsproblem

KI-Agenten werden wirklich nützlich, wenn sie Aktionen in echten Systemen ausführen können. Bei DoorDash heißt das: interne APIs, Engineering-Systeme, Observability-Plattformen, Ticketing-Systeme, Wissensdatenbanken und externe SaaS-Produkte. Das Model Context Protocol, kurz MCP, hat dabei geholfen, diese Werkzeuge einheitlich zu beschreiben, zu entdecken und aufzurufen. Es ist sozusagen die gemeinsame Sprache zwischen Agenten und Servern.

Aber wie so oft im Leben: Die Sprache allein löst nicht das Problem, was man tun darf. MCP standardisiert die Form eines Tool-Aufrufs, aber es beantwortet nicht die kritischen Produktionsfragen: Welcher Agent darf dieses Tool überhaupt aufrufen? Für welchen Benutzer, welches Team oder welchen Dienst handelt er? Welches Zugangsdatum soll verwendet werden? Welche Teilmenge der Werkzeuge soll der Agent sehen? Wie entzieht man Zugriff wieder? Und was passiert nach dem Aufruf? Das sind Fragen, die in der Praxis schnell an Bedeutung gewinnen.

Der Artikel macht das an einem Beispiel deutlich: Ein Coding-Agent braucht Zugriff auf GitHub, Jira, Code-Suche, CI, Observability und Doku. Ein externer MCP-Server kann hunderte Tools bereitstellen, obwohl der Arbeitsablauf nur fünf braucht. Ein Benutzer-Agent braucht OAuth-Zustimmung des Nutzers, während Team-Automatisierung mit einem Dienstkonto arbeitet. Wenn jedes Team diese Probleme separat löst, entsteht ein Flickenteppich aus Auth-Code, OAuth-Flüssen, Geheimnis-Verwaltung, Tool-Katalogen, Rate-Limits und Logs. Genau hier setzt das Agent Gateway an.

Ein Tor, viele Regeln

Das Gateway ist ein einziger, kontrollierter Einstiegspunkt, über den Agenten Werkzeuge entdecken und aufrufen. Es authentifiziert den Aufrufer, prüft die Autorisierung, zeigt nur die genehmigte Tool-Oberfläche, spritzt die richtigen Anmeldedaten, leitet an den passenden MCP-Server weiter und protokolliert jeden Aufruf strukturiert. Der Blog betont: Das Gateway ist kein einfacher Proxy, sondern die Kontrollebene für das gesamte Agenten-Ökosystem. Es verwaltet, wer Tools aufrufen darf, kuratiert die Tool-Listen, bündelt Werkzeuge nach Aufgaben und bietet DoorDash einen zentralen Ort für Beobachtung, Rate-Limits, Zugriffsentzug und Verbesserung.

Die Architektur besteht aus zwei zentralen Teilen: einem Proxy und einem Registry. Der Proxy bildet die Datenebene. Er empfängt jede MCP-Anfrage, authentifiziert, autorisiert, begrenzt die Rate, spritzt Anmeldedaten, leitet weiter und sendet Observability-Daten. Die Registry ist die Quelle der Wahrheit in der Kontrollebene. Sie speichert Agenten, MCP-Server, Verantwortliche, Transport-Konfigurationen, Auth-Modi, Richtlinien, entdeckte Tool-Kataloge und Tool-Oberflächen-Konfigurationen.

Diese Trennung bringt Eigenschaften, die mit Punkt-zu-Punkt-Integrationen kaum zu erreichen sind. Agenten nutzen einen konsistenten MCP-Endpunkt statt die Auth- und Routing-Modelle jedes Servers zu lernen. Tool-Anbieter registrieren ihre Fähigkeiten einmal, hinterlegen Ownership und Richtlinien und sehen die Nutzung in Produktion. Security-Teams haben einen Ort, um Zugriff zu erzwingen, Berechtigungen zu entziehen und Prüfungen durchzuführen. Und die Plattform-Teams können den gemeinsamen Pfad einmal verbessern, und alle Agenten profitieren davon.

Identität, Autorisierung und Geheimnisse unter einem Dach

Jede Gateway-Anfrage löst eine Identität auf: einen Benutzer, einen Dienst oder einen Agenten, der im Namen eines Benutzers handelt. Diese Identität wird durch Autorisierung, Credential-Injektion, Routing und Beobachtung getragen, sodass jede Aktion zugeordnet werden kann. Die Autorisierung fragt nicht nur, ob der Aufrufer Zugriff auf den Server hat, sondern auch, ob dieser Agent diesen Server nutzen darf, ob dieser Benutzer dieses Tool über diesen Agenten verwenden darf, ob das Tool in dieser Umgebung überhaupt sichtbar ist und ob eine schreibende oder nur lesende Variante möglich ist.

Weil die Richtlinie im Gateway lebt, gibt es einen einzigen Ort, um Zugriff zu ändern oder zu entziehen. Tool-Besitzer müssen nicht für jeden Server eine eigene Autorisierung aufbauen, und Agent-Entwickler müssen keine Sicherheitsentscheidungen in Prompts oder Code einbauen. Das Credential-Handling folgt demselben Muster. Es gibt verschiedene Auth-Modi: interne Service-Identitäten, Gateway-gespeicherte Tokens, nutzerbezogenes OAuth und Service-Prinzipale. In allen Fällen gilt ein Prinzip: Agenten sollen keine rohen Anmeldedaten in den Händen halten, weder API-Keys noch OAuth-Refresh-Tokens noch geliehene menschliche Berechtigungen. Das Gateway hält diese Grenzen explizit und prüfbar.

Besonders spannend ist die Behandlung von per-user OAuth. Nutzerbezogene Drittanbieter-Tools brauchen die Zustimmung des Benutzers. Wenn ein Agent im Namen eines Nutzers Dokumente liest oder Tickets anlegt, darf er nicht einfach einen geteilten Schlüssel verwenden. Früher baute jedes Team seinen eigenen OAuth-Fluss, seine eigene Token-Speicherung und seine eigene „Verbinde dich zuerst“-Erfahrung. Das Gateway zentralisiert die OAuth-Zustimmung und speichert die Tokens verschlüsselt. Die Zugriffseinheit ist auf Agent, Benutzer und Server bezogen.

Bei der ersten Anfrage, die eine Autorisierung braucht, startet das Gateway den OAuth-Fluss des Anbieters und speichert das Ergebnis. Der Agent sieht das Token nie. Für Clients, die MCP-Elicitation unterstützen, kann das Gateway die Tool-Ausführung unterbrechen, den Client bitten, einen Verbindungsbildschirm zu zeigen, und nach der Zustimmung den ursprünglichen Aufruf fortsetzen. Für Clients ohne Unterstützung gibt es eine strukturierte Antwort mit einer Verbindungs-URL. Das macht aus einem gescheiterten Durchlauf einen behebbaren Teil des Tool-Aufrufs. Genau so soll Software sich anfühlen: Wenn etwas fehlt, bricht es nicht ab, sondern zeigt den Weg.

Kuratierte Werkzeuglandschaften statt Tool-Wildwuchs

Agenten denken nicht in MCP-Servern. Sie denken in Aufgaben. Ein Coding-Agent will nicht GitHub, Jira, Observability und Doku als separate Setup-Schritte behandeln. Er will die Werkzeuge, die er braucht, um ein Problem zu untersuchen, Code zu ändern, einen Pull-Request zu öffnen, die CI zu prüfen und das Produktionsverhalten zu verstehen. Gleichzeitig bieten viele MCP-Server weit mehr Werkzeuge an, als ein einzelner Agent nutzen sollte. Manche Drittanbieter-Server veröffentlichen hunderte Operationen, darunter Admin-Aktionen, destruktive Befehle, Billing-APIs und spezielle Nischenfunktionen. Die meisten Arbeitsabläufe benötigen nur einen kleinen Teil davon.

Das Gateway löst dieses Problem mit kuratierten Tool-Surfaces. Bundles kombinieren Werkzeuge aus mehreren MCP-Servern zu einem logischen Endpunkt. Filter entscheiden, welche Werkzeuge aus jedem Server für ein bestimmtes Bundle, einen Agenten, eine Benutzergruppe, eine Umgebung oder eine Zielgruppe sichtbar sind. Ein Entwickler-Tools-Bundle kann etwa ausgewählte GitHub-Werkzeuge, Jira-Werkzeuge, Observability-Werkzeuge, Code-Suche- und Doku-Werkzeuge sowie Feature-Flag-Werkzeuge enthalten.

Der Agent verbindet sich mit einer einzigen Gateway-URL. Dahinter führt das Gateway die Tool-Listen über die Server im Bundle zusammen, wendet Filter an, passt Namen und Beschreibungen an, wo nötig, und liefert einen zusammenhängenden Katalog. Bei jedem Tool-Aufruf wird die Richtlinie erneut geprüft, die Anfrage an den richtigen Server geroutet und das jeweilige Credential verwendet. Der Vorteil ist ein Produkterlebnis für den Agenten: eine bewusste Auswahl an Werkzeugen mit stabilen Namen, klaren Beschreibungen, Ownership-Metadaten und zielgruppenspezifischen Bundles. Technik-, Datenanalyse-, Support- und externe Anwendungsfälle können dieselben Gateway-Primitive nutzen, aber unterschiedliche Oberflächen bekommen.

Das klingt vielleicht trivial, ist es aber nicht. Eine kuratierte Tool-Surface kann den Unterschied ausmachen zwischen einem Agenten, der das richtige Werkzeug findet, und einem, der in einem riesigen API-Katalog umherirrt. Genau hier zeigt sich, warum das Gateway mehr ist als ein Access-Proxy. Es prägt, was Agenten entdecken können, was sie aufrufen dürfen und wie viel irrelevanter Kontext sie mit sich herumtragen. Für KI-Einsteiger ist das eine wichtige Lektion: Was ist KI also wirklich? Ein nützliches System, das aber klare Grenzen braucht, um nicht in Beliebigkeit zu versinken.

Beobachtbarkeit, Kosten und Schutz

Weil jeder Aufruf durch das Gateway läuft, kann jede Anfrage ein strukturiertes Ereignis auslösen: Server, Tool, Bundle und verantwortliches Team; Benutzer, Agent, Dienst und Plattform; Autorisierungsergebnis, Statuscode, Fehlerquelle und Latenzaufschlüsselung; Anfrage- und Antwortgröße; und gegebenenfalls vom System gemeldete Kostenmetadaten. Das Gateway erzeugt auch Metriken für Anfragevolumen, Latenz pro Tool, Autorisierungsentscheidungen, OAuth-Ergebnisse, Rate-Limit-Entscheidungen, Streaming-Verbindungen und Upstream-Fehler. Trace-Propagation erlaubt es, einen Aufruf vom Agenten durch das Gateway bis zum Server zu verfolgen.

Der operative Wert ist direkt spürbar: Die Sicherheit kann Zugriffe auditieren, Plattform-Teams finden laute Agenten, Tool-Besitzer sehen Einführung und Fehler, und die Infrastruktur kann Kosten zuordnen. Gleichzeitig schützt das Gateway nachgelagerte Systeme vor Überlastung. Rate-Limits lassen sich pro Server, Tool, Aufrufer, Benutzer, Bundle oder Aufrufertyp konfigurieren. Neue Limits können zuerst im Schattenmodus laufen, also nur beobachten, was sie abgelehnt hätten, ohne den Produktionsbetrieb zu beeinträchtigen. Das Gateway verwandelt Governance in Daten, statt sich darauf zu verlassen, dass jedes Team die richtigen Felder protokolliert und die richtigen Limits erzwingt.

Selbstbedienung ist der Schlüssel

Ein Gateway funktioniert nur, wenn die Teams es gern nutzen, statt es zu umgehen. Deshalb setzt DoorDash auf Self-Service. Registrierung, Entdeckung, Filterung und Bundle-Verwaltung laufen über eine Control-Plane-Oberfläche und API. Teams können selbst ihre MCP-Server und Agenten registrieren, Authentifizierung konfigurieren, Tools entdecken, Verantwortlichkeiten hinterlegen, Filter definieren, Tools in Bundles aufnehmen und den Produktionseinsatz verfolgen.

Der Onboarding-Prozess folgt klaren Schritten: Zuerst den MCP-Server registrieren, dann den rohen Tool-Katalog per tools/list entdecken. Danach werden die Werkzeuge ausgewählt und freigegeben, die DoorDash wirklich nutzen will. Im nächsten Schritt werden Auth-Modus, Ownership und Richtlinien zugewiesen. Schließlich kommen die freigegebenen Tools in ein Bundle – und fertig. So bekommt ein Agent einen eigenen, sauberen Zugang, ohne hinter den Kulissen ein eigenes Sicherheits- und Verwaltungssystem aufzubauen.

Das alles klingt nach einem klassischen Plattform-Thema. Und doch steckt eine größere Idee dahinter: Wenn KI-Agenten ernsthaft in Unternehmen ankommen sollen, brauchen sie eine Infrastruktur, die Skalierung, Sicherheit und Vertrauen ermöglicht. Das Gateway von DoorDash ist ein gutes Beispiel dafür, wie so etwas aussehen kann. Es ist kein Hype, sondern eine handfeste Ingenieurslösung für ein Problem, das jede Organisation treffen wird, die Agenten jenseits von Spielereien einsetzen will.

Für alle, die sich fragen, was KI-Anwendungen in der Praxis wirklich brauchen, liefert dieser Beitrag eine klare Antwort: nicht nur schlauere Modelle, sondern bessere Zugriffswege. Das Wichtigste ist die Einsicht, dass Technologie allein nicht reicht. Es braucht Governance, gute Gliederung und die Bereitschaft, den gemeinsamen Pfad zu bauen. Dann können KI-Agenten zu dem werden, was sie versprechen: nützliche Kollegen, die uns Arbeit abnehmen – ohne dass wir uns Sorgen um die Schlüssel machen müssen.

Quelle: careersatdoordash.com

Stell dir vor, dein Unternehmen hat für die Entwicklerteams eine Superkraft erschlossen: KI-Agenten schreiben Code, testen Module und beheben Fehler. Während die Programmierer im KI-Rausch arbeiten, sitzen die Kollegen aus Vertrieb, Finanz oder Compliance daneben und warten. Ihre Aufgaben – eine Recherche vor einem Kundentermin, die Modellierung von Umsatzszenarien, die Vorbereitung einer Compliance-Prüfung – blieben bisher außen vor. Genau hier setzt die Stripe Knowledge AI Platform an. Intern nennt Stripe sie „Kai“. Und sie zeigt, wie KI-Agenten für Wissensarbeit aussehen können, wenn man sie nicht als Spielzeug, sondern als ernsthafte Plattform baut.

Das Problem: Werkzeuge für Programmierer, nicht für Wissensarbeiter

Wer schon einmal mit Coding-Agenten wie Claude Code oder Codex gearbeitet hat, kennt das Muster: Die Aufgabe wechselt, aber der Arbeitsablauf bleibt gleich. Du editierst Dateien, führst Tests aus, committest. Programmiersprachen variieren, doch die Struktur der Arbeit ist erstaunlich uniform. Deshalb funktioniert fürs Programmieren ein einzelner Agententyp hervorragend. Wissensarbeit ist das genaue Gegenteil. Eine Kundenanalyse erfordert andere Datenquellen, andere Werkzeuge und andere Ergebnisse als die Vorbereitung einer Bilanzprüfung. Auch die Definition von „fertig“ ist eine völlig andere. Für diese Vielfalt gab es bislang keine passende KI-Lösung.

Stripe experimentierte zunächst mit zwei Ansätzen. Der erste: ein No-Code-Agent-Builder, mit dem jede*r eigene Workflow-Agenten bauen konnte. Es entstanden über 4.000 solcher Mini-Agenten. Doch schnell zeigte sich ein Problem: Die Teams schrieben konzeptionell ähnliche Prompts, nur mit unterschiedlicher Qualität. Die Flut an Mikro-Agenten wurde zunehmend schwer zu überwachen und zu warten. Der zweite Ansatz war der Einsatz von Coding-Agenten. Die waren mächtig, führten aber zu Sicherheitsproblemen und einer neuen Support-Last für Code-Qualitätsteams, die plötzlich Nicht-Programmierer betreuen sollten. Aus diesen Erfahrungen zog Stripe eine klare Lehre: Eine Knowledge AI Platform muss drei Dinge richtig machen – Expertise skalieren, ohne sie zu zentralisieren; die Nutzer dort abholen, wo sie arbeiten; und Schutzmechanismen durchsetzen, die es im Code so nicht gibt.

Expertise skalieren, ohne sie zu zentralisieren

Das Wissen darüber, wie man eine Zahlungsreklamation bearbeitet oder ein Umsatzmodell erstellt, liegt nicht bei einer zentralen KI-Abteilung. Es ist verteilt über Dutzende Fachbereiche: Vertrieb, Finanz, Marketing, Recht, Data Science und mehr. Jeder Bereich hat eigene Tools, Datenquellen, Workflows und eigene Vorstellungen von Qualität. Multipliziert man das mit allen Produkten und Ländern, in denen Stripe operiert, entsteht eine atemberaubende Komplexität. Kai muss diese Komplexität so modellieren, dass sie für die Nutzer unsichtbar wird. Die Aufgabe soll einfach funktionieren – ohne dass man die zugrunde liegende Struktur verstehen muss. Das ist ein hoher Anspruch, denn ein einzelner, monolithischer Agent kann all diese Einschränkungen unmöglich abbilden. Und es wäre ebenfalls nicht skalierbar, wenn jedes Fachteam seine eigene, sichere Agenteninfrastruktur bauen müsste. Deshalb hat Stripe Kai in drei Schichten aufgebaut.

Der Agent muss dorthin, wo die Arbeit passiert

Die Oberfläche, auf der ein Agent erscheint, ist genauso wichtig wie das, was er weiß. Nicht jede*r arbeitet im Browser-Tab, und schon gar nicht im Terminal. Ein Wissensagent kann also kein einzelnes Produkt sein. Er muss eine Plattform sein, die sich überall einbetten lässt. Ein Beispiel: Das Finanzteam von Stripe nutzt eine interne Anwendung, um komplexe Änderungen am Betriebsbudget zu modellieren. Der Agent muss den Kontext der Anwendung lesen, verwandte Dokumente recherchieren, gültige Änderungen vorschlagen und die Unterschiede zusammenfassen – und zwar mitten in der Anwendung, ohne die Nutzer herauszureißen. Ein separates Agentenprodukt würde genau das verhindern. Eine eigene Agentenlösung für jede einzelne Oberfläche wäre wiederum zu aufwendig und würde für Nutzer, die mehrere Tools verwenden, zu einem zerrissenen Erlebnis führen. Die Lösung von Stripe sind Surface-agnostische APIs. Das bedeutet: Der Agent ist ein Dienst, keine Anwendung. Die verschiedenen Oberflächen – Web-App, Slack-Integration, Browser-Erweiterungen, interne Tools – sind nur unterschiedliche Ansichten auf denselben Agenten. Wer im Business-Intelligence-Tool arbeitet, kann direkt dort eine Frage an Kai stellen, ohne das Tool zu wechseln.

Schutzmechanismen, die es im Code nicht gibt

Coding-Agenten profitieren von jahrzehntealten, verlässlichen Schutzmechanismen: Compiler lehnen ungültigen Code ab, Tests fangen Regressionen ab, und Git macht jeden Fehler rückgängig. Bei Wissensarbeit fehlen solche Sicherheitsnetze weitgehend. Ein zentrales Prinzip bei Stripe lautet: Man darf Daten aus zwei unterschiedlichen Kundenkontexten nicht in einer einzigen Analyse kombinieren. Ein Nutzer kann zwar für beide Kontexte einzeln eine Zugriffsberechtigung haben, aber niemals im selben Session. Die Trennlinie ist nicht die Frage „Was darf diese Person anhand ihres Autorisierungs-Tokens sehen?“, sondern „Was sollte diese Aufgabe in diesem Kontext sehen dürfen?“. Die Plattform muss diese stillschweigenden Regeln durchsetzen, auf die sich die Nutzer verlassen. Genau das leistet die dritte Schicht von Kai: die Execution Environment. Sie umfasst den Agenten-Harness, Sandbox, Workflow-Orchestrierung und ein Zugriffskontroll-Framework. Interne Wissensarbeit verarbeitet dieselben sensiblen Daten wie die externen Produkte von Stripe und dient denselben Nutzern. Deshalb gelten hier dieselben Sicherheits- und Compliance-Anforderungen. Die gemeinsame Infrastruktur erzwingt Disziplin und erzeugt einen positiven Kreislauf: Verbesserungen an der Ausführungsumgebung kommen sowohl den internen als auch den produktbezogenen Agenten zugute.

So funktioniert Kai: Ein Blick unter die Haube

Der Agent-Harness von Kai wurde mit LangChain’s deepagents gebaut und läuft auf Kubernetes. Jede Sitzung erhält eine sichere Sandbox und ein Multi-Tenant-Virtual-Dateisystem. Der Agent legt darin Dateien an, arbeitet iterativ an Artefakten und nutzt eine Code-Execution-Umgebung für Analysen und Datenverarbeitung. Die Architektur ist darauf ausgelegt, über lange, komplexe Sitzungen hinweg Zustand zu halten. Eine Sitzung erreichte kürzlich 932 Turns. Wissensarbeit ist selten eine einzelne Frage; sie ist iteratives Denken, das auf sich selbst aufbaut. Die Plattform muss diesen Zustand halten, ohne den Kontextfenster zu überladen. Besonders spannend ist die Fähigkeit von Kai, die richtige Fähigkeit auszuwählen. Über 1.000 Skills und Tools sind angebunden – von Business-Intelligence-Dashboards über Projektmanagement-Tools bis hin zu Drittanbieter-Diensten wie Zoom und Google Workspace. Nutzer können einfach eine Frage stellen und Kai wählt den passenden Kontext und die richtigen Werkzeuge. Coding-Agenten haben hier einen natürlichen Vorteil, weil die Ordnerstruktur automatisch eine Organisation für Skills und Kontext vorgibt. Wie Kai diese Herausforderung ohne eine solche vorgegebene Struktur löst – mit einem Hybrid aus RAG und LLM-Ansteuerung – will Stripe in einem Folgebeitrag erklären.

AgentStudio: Die Kontrollzentrale für Fachbereiche

Die zweite Schicht, AgentStudio, ist die Kontrollzentrale für Domain-Experten. Teams können damit ihre eigenen Skills, kundenspezifischen Kai-Agenten und Tool-Auswahlen bauen, testen und überwachen. Ein Vertriebsteam besitzt zum Beispiel einen eigenen Kai-Agenten, der perfekt auf seine Workflows abgestimmt ist. Er lädt die passenden Skills standardmäßig, verbindet sich mit den eigenen Datenquellen und präsentiert die Ergebnisse in dem Format, das die Nutzer erwarten. AgentStudio zeigt Nutzungsdaten und Qualitätssignale direkt neben jedem Asset. So sehen Domain-Experten, was funktioniert, ohne das Plattform-Team um Auswertungen bitten zu müssen. Diese Balance zwischen zentraler Plattform und dezentraler Governance ist entscheidend. Die Expertise bleibt bei den Fachteams, während die Plattform die Infrastruktur, Sicherheit und Wartung übernimmt.

Impact: Umsatz, Effizienz und alltägliche Nutzung

Die Zahlen, die Stripe kommuniziert, sind beachtlich. Innerhalb von zwei Wochen nach dem Launch im April nutzte der Großteil des Unternehmens die Knowledge AI Platform. Heute sind 83% der Belegschaft wöchentlich aktive Nutzer, darunter nahezu der komplette Go-to-Market-Bereich (Marketing, Vertrieb, Kundenerfolg, Technical Account Management). Neue Mitarbeitende im Vertrieb sind „Kai-native“: Sie nutzen die Plattform 2,7-mal häufiger, und Power-User erzielen in derselben Kohorte 80% mehr Wert als Wenig-Nutzer. Wenn Account Executives Kai verwenden, produzieren sie doppelt so viele Vertriebsaktivitäten, erzeugen 17% mehr Opportunities und 26% mehr Umsatzmöglichkeiten und schließen 39% mehr Deals ab – verglichen mit denselben Verkäufern in Wochen ohne Kai. Insgesamt hat Kai dazu beigetragen, 25.000 Stunden pro Jahr von administrativer Arbeit in umsatzgenerierende Arbeit zu verschieben. Täglich finden mehr als 5.000 Sitzungen statt, die sich auf Datenanalyse konzentrieren. Auch im Finanz- und Operationsbereich hilft Kai, unstrukturierte Daten zu analysieren, wiederkehrende Berichte zu generieren und fragmentierte Kontexte in nutzbare Artefakte zu verwandeln.

Besonders beeindruckend ist ein Detail: Eine nicht-technische Mitarbeiterin verließ eine Einführungsveranstaltung und erstellte sofort automatisiert einen Digest, der Asana, Slack und Jira in einen einzigen Prozess integriert. Solche Geschichten zeigen, dass die Plattform nicht nur für Spezialisten funktioniert. Sie senkt die Hürde zur Nutzung von KI erheblich – nicht durch vereinfachte Oberflächen, sondern durch eine Architektur, die die Komplexität im Hintergrund versteckt. Wie das Stripe-Team betont: „Wir haben noch nicht gewonnen.“ Das ist die grundlegende Haltung. Man sieht die Plattform als erstes Kapitel, nicht als Endpunkt.

Was noch kommt: Reflexion, Kollaboration und bessere Zustandsverwaltung

Stripe arbeitet bereits an den nächsten Schritten. Ein Thema ist die Verbesserung des State Managements. Allgemeine Agenten wie Kai erzeugen viel Zustand, während sie Werkzeugaufrufe tätigen und große Dokumente herunterladen. Die Entwickler optimieren kontinuierlich den „aktiven“ Kontext, der an das Large Language Model gesendet wird, und den „erweiterten“ Kontext, der in S3 oder dem virtuellen Dateisystem liegt. Zudem wird an einer Qualitätsschleife gearbeitet, die es Kai ermöglicht, eigene Sitzungen zu reflektieren und Verbesserungen an Skills vorzuschlagen. Diese Verbesserungen können getestet und dem jeweiligen Skill-Eigentümer zur Überprüfung vorgelegt werden. Und schließlich soll die Kollaboration erleichtert werden: Bisher sind viele Kontexte in Sitzungen „eingeschlossen“. Die Idee ist, Erkenntnisse aus Kai-Sitzungen zu teilen und mehrere Personen – und auch mehrere Agenten – an denselben Artefakten arbeiten zu lassen.

Für alle, die selbst über eine Knowledge AI Plattform nachdenken, lohnt sich ein Blick auf die Prinzipien, die Stripe geleitet haben. Es geht nicht darum, möglichst viele einzelne Agenten zu bauen. Es geht darum, eine Plattform zu schaffen, die Expertise aus dem Fachbereich anzieht, in die vorhandenen Arbeitsabläufe eintaucht und dieselben Sicherheitsstandards anlegt wie produktionsreife Systeme. Die KI-Agenten für Datenbankabfragen und Compliance, die in solchen Umgebungen entstehen, sind keine Spielzeuge, sondern ernsthafte Werkzeuge – mit klaren Grenzen, überprüfbaren Ergebnissen und einem menschenzentrierten Design, das nicht nach Technologie-Spielerei klingt. Stripe zeigt damit, wie man eine KI-Plattform für Unternehmen und Teams baut, die nicht nur Programmierer bedient. Die Knowledge AI Platform ist ein Vorbild für alle, die KI in der Wissensarbeit ernsthaft einsetzen wollen.

Die Botschaft am Ende ist keine Hype-Geschichte, sondern eine geerdete: Wissensarbeit ist komplexer als das Schreiben von Code. Aber mit den richtigen Architekturprinzipien lässt sich diese Komplexität bändigen. Kai ist dafür ein Beweis – nicht, weil die Plattform perfekt ist, sondern weil sie zeigt, wie man KI-Agenten baut, die in den Alltag von Vertrieb, Finanz und Compliance eintauchen, ohne sie zu bevormunden. Wenn diese Prinzipien auch außerhalb von Stripe Schule machen, könnte die nächste Welle der Produktivität nicht aus der Softwareentwicklung kommen, sondern aus den Bereichen, die man lange übergangen hat.

Quelle: stripe.dev

Das Problem: Der traditionelle BI-Stack als Flaschenhals

Eine einfache Frage zu den Umsatzzahlen beantwortet die Datenabteilung erst nach drei Tagen. LangChain stand vor genau diesem Problem. Ihr Data Stack: ein klassisches BI-Tool, gut für vordefinierte Reports, unflexibel für spontane Fragen. Jede Anfrage landete bei der Datenabteilung, damals eine Person. Sie entschlüsselte die Frage, suchte das Modell, schrieb SQL, validierte das Ergebnis und antwortete. Das bremste viele Anfragen aus.

Die Entwickler erkannten, dass der Workflow nicht skalierte. Sie wollten einen Stack für mehrere Benutzertypen gleichzeitig: Dashboards für Eilige, Notebooks für Techniker, direkte Fragen für Geschäftsanwender – und optimiert für einen KI-Agenten, der die Datenabteilung entlastet. Das war der Ausgangspunkt.

Die Lösung: Ein zentraler Arbeitsplatz für Menschen und Agenten

Das Team ersetzte den alten BI-Stack durch Hex. Hex bietet Dashboards, Notebooks, SQL-Workflows und eine konversationelle Schnittstelle – alles in einer Plattform mit eingebauten KI-Funktionen. So entstand ein zentraler Arbeitsplatz für Menschen und Agenten. Der Agent operiert als virtueller Analyst und ist über Hex, Slack, CLI oder MCP zugänglich. Nutzer fragen dort, wo sie arbeiten.

Ein Produktmanager fragt in Hex nach Nutzerverhalten, ein Vertriebler stellt die gleiche Frage über Slack, ein Entwickler nutzt das CLI. Der Agent liefert eine erste Antwort; die Datenabteilung validiert später. Die Migration dauerte sechs Wochen. Danach nutzen 100 Prozent des Unternehmens den neuen Stack. 30 Prozent der Mitarbeiter haben Agentenzugriff, beantragbar über die IT. Der Agent bearbeitet heute die 40‑fache Menge an Anfragen, die das dreiköpfige Daten‑Team zuvor schaffte. In den letzten 30 Tagen gab es rund 2.200 Agentengespräche – durchschnittlich 23 pro aktivem Nutzer.

Die Kontextschichten: Das Rezeptbuch für den Agenten

Die Qualität des Agenten hängt vom Kontext ab. Ein Datenagent ohne Kontext ist wie ein Koch ohne Rezept – er mischt Zutaten, aber das Ergebnis passt selten. LangChain hat vier Schichten aufgebaut, die dem Agenten genau sagen, was die Daten bedeuten und wie sie verwendet werden.

1. Datenmodelle mit klaren Definitionen

Die Grundlage sind Datenmodelle, verwaltet mit dbt. dbt organisiert SQL‑Abfragen und Beschreibungen für Tabellen und Spalten. Jede Spalte bekommt nicht nur einen technischen Namen, sondern eine erklärende Beschreibung. Statt account_status: Der Status des Kontos heißt es nun: account_status: Der aktuelle Lebenszyklusstatus des Kontos in Salesforce. ‚Active‘ bedeutet, der Kunde hat einen aktiven bezahlten Vertrag. ‚Churned‘ bedeutet, der Kunde hatte früher einen bezahlten Vertrag, der beendet wurde. ‚Prospect‘ bedeutet, das Konto ist noch kein Kunde. Für Kundenberichte filtere auf ‚Active‘, es sei denn, die Analyse schließt explizit abgewanderte oder potenzielle Konten ein. Diese Details liefern Geschäftswissen. Auch Tabellen werden beschrieben: Körnung, geeignete Fragen, Vorsichtshinweise. Schwache Definitionen führen zu technisch korrekten, aber fachlich nutzlosen Antworten.

2. Das semantische Modell für konsistente Metriken

Die zweite Schicht: das semantische Modell. Es definiert Begriffe wie ARR, Pipeline oder Nutzung und ihre Berechnung. So muss der Agent nicht raten, welche Tabelle oder Formel gemeint ist. Das semantische Modell baut auf den sauberen Datenmodellen auf – schlechte Fundamente nützen auch der besten Semantik nichts. Klare Modelle, Körnungen und Definitionen steigern die Qualität auf jeder Ebene.

3. Business-Kontext in Workspace Guides

Manche Informationen – wie unternehmensinterne Prozesse, team‑spezifische Workflows oder Reporting‑Konventionen – passen nicht in Tabellen‑ oder Metrikdefinitionen. Dafür verwenden die Entwickler Workspace Guides in Hex: schriftliche Anleitungen für den Agenten. Ein Guide erklärt etwa: Wie definieren wir die Pipeline für das wöchentliche Vertriebs‑Reporting? Welche Dashboards gelten als kanonisch für eine Metrik? Wie interpretieren wir die Produktnutzung bei verschiedenen Bereitstellungsarten? Welche Filter setzen wir bei Kunden‑Gesundheitsanalysen? Wann leiten wir eine Frage zur Validierung an die Datenabteilung? Diese Guides werden in einem GitHub‑Repository versioniert und automatisch mit Hex synchronisiert. Sie sind in natürlicher Sprache und fangen Nuancen ab, die nicht in Code passen.

4. Endorsements: Vertrauenssignale für den Agenten

Die vierte Schicht: Endorsements – Kennzeichnung vertrauenswürdiger Datenquellen. In vielen Unternehmen gibt es mehrere Tabellen oder Dashboards zu ähnlichen Konzepten. Ohne Vertrauenssignal könnte der Agent eine veraltete Quelle wählen. Deshalb markiert nur die Datenabteilung bestimmte Assets als „endorsed“. Ein endorsed Dashboard ist wie ein offizielles Rezept – der Agent vertraut ihm. Nur das Daten‑Team darf Endorsements vergeben, Änderungen an endorsed Dashboards müssen vorab geprüft werden. Sonst verliert das Signal an Wert, wenn alles endorsed ist. Zusätzlich hat der Agent Zugriff auf das dbt‑Repository, um die SQL‑Logik hinter jeder Spalte nachzuvollziehen. Das ist für technische Nutzer wichtig.

Der Feedback-Loop: Aus Fehlern lernen

Kontext allein reicht nicht. Das Team hat eine Feedback‑Infrastruktur aufgebaut. Sie nutzen das Context Studio von Hex (oder LangSmith). Damit analysieren sie Gesprächsthemen, Warnungen und Fehlschläge des Agenten. Häufige gleiche Fragen deuten auf ein fehlendes Dashboard hin. Bei wiederholten Fehlern zu einer Metrik verbessern sie die Definition im semantischen Modell. Erfordern Fragen internes Prozesswissen, erstellen sie einen neuen Workspace Guide. Greift der Agent auf die falsche Quelle zu, passen sie Endorsements oder die dbt‑Dokumentation an. Dieser Kreislauf aus Beobachten und Verbessern macht den Agenten zuverlässiger.

Fazit: Der Wandel von der Datenabteilung zum Systemkurator

Die Datenabteilung von LangChain wandelte sich vom Dienstleister zum Kurator eines intelligenten Systems. Sie verbringt Zeit mit der Verbesserung von Modellen, dem Schreiben von Guides, der Freigabe von Endorsements und der Analyse von Feedback‑Daten. Einfachere Fragen übernimmt der Agent – mit der 40‑fachen Menge an Anfragen. Jeder mit Agentenzugriff kann jederzeit fragen, ohne auf einen Termin zu warten. Das macht Datenzugang demokratischer, ohne Qualitätsverlust – solange der Kontext stimmt. Für Unternehmen, die KI‑Agenten im Datenbereich einsetzen möchten, ist dieser Ansatz eine Blaupause: Datenfundamente klären, den Agenten mit Kontext versorgen, einen Kreislauf des Lernens etablieren. So wird der Agent mehr als ein SQL‑Generator – er entlastet die Datenabteilung und steigert die Wertschöpfung.

Quelle: langchain.com