Jul, 134 Min. Lesezeit
Frontend
News · Der interne Datenagent von OpenAI vereint eine Oberfläche über sechs Zugangspunkte
Jun, 294 Min. Lesezeit
FrontendDer interne Datenagent von OpenAI vereint eine Oberfläche über sechs Zugangspunkte
Wie OpenAIs interner Datenagent Mitarbeitende dort erreicht, wo sie bereits arbeiten – und was seine Transparenz- und Unterbrechungsfunktionen über das Design von Agenten-Frontends verraten.
Der Agent hat keinen zentralen Startbildschirm
Die meisten Agenten-Demos spielen sich in einem einzigen Chatfenster ab. OpenAIs Datenagent tut das bewusst nicht. Laut dem Beitrag ist er als Slack-Agent verfügbar, über eine Weboberfläche, innerhalb von IDEs, in der Codex CLI über MCP und direkt in OpenAIs interner ChatGPT-App über einen MCP-Connector.
Das sind fünf unterschiedliche Zugangspunkte für ein einziges Backend, und der genannte Grund ist, dass er dort erreichbar sein soll, „wo Mitarbeitende bereits arbeiten“. Das Designziel wird im Schlussabschnitt explizit formuliert: Der Agent „soll sich natürlich in die bestehende Arbeitsweise einfügen, statt wie ein separates Tool zu funktionieren“.
MCP übernimmt hier eine unauffällige, aber zentrale Rolle. Zwei der Zugangspunkte – die Codex CLI und die interne ChatGPT-App – werden über MCP erreicht, was bedeutet, dass dieselbe Agentenlogik als anbindbarer Dienst bereitgestellt wird, statt für jeden Client neu implementiert zu werden. Für Teams, die überlegen, wie sie einen internen Agenten ausliefern sollen, ist das ein konkretes Argument dafür, den Reasoning-Kern einmal zu bauen und über Protokoll-Connectoren in bestehende Tools zu tragen.
Unterbrechbarkeit als Interface-Funktion
Der Beitrag beschreibt den Agenten als „ein Teammitglied, mit dem man argumentieren kann“, und die konkret genannten Verhaltensweisen sind Frontend-Funktionen, nicht bloß Modellfähigkeiten. Nutzer können mitten in der Analyse unterbrechen und sie umlenken, und der Agent behält den vollständigen Kontext über mehrere Turns hinweg, sodass Rückfragen die Frage nicht erneut formulieren müssen.
Es gibt auch ein definiertes Verhalten für Mehrdeutigkeit: Sind Anweisungen unklar, stellt der Agent Rückfragen, und kommt keine Antwort, wendet er „sinnvolle Standardwerte“ an – als Beispiel wird genannt, dass bei einer Wachstumsfrage ohne Zeitraum die letzten sieben oder 30 Tage angenommen werden. Das ist ein gezielt nicht blockierendes Verhalten, gewählt, damit der Agent weiterarbeitet, statt bei fehlenden Angaben ins Stocken zu geraten.
Auch das Gedächtnis zeigt sich über die Oberfläche. Erhält der Agent eine Korrektur oder entdeckt er eine Nuance, fragt er den Nutzer, ob dies als Erinnerung gespeichert werden soll, und Erinnerungen können manuell angelegt und bearbeitet werden, mit globalem oder persönlichem Geltungsbereich. Die Korrekturschleife ist keine verborgene Hintergrundfunktion – sie ist ein sichtbarer Hinweis, auf den der Nutzer reagiert.
Die Arbeit sichtbar machen als Vertrauensmechanismus
Da der Agent SQL schreibt und gegen echte interne Daten ausführt, behandelt OpenAI Überprüfbarkeit als zentralen Bestandteil der Oberfläche. Laut dem Beitrag „legt er seinen Denkprozess offen, indem er Annahmen und Ausführungsschritte zu jeder Antwort zusammenfasst“, und wenn Abfragen laufen, verlinkt er direkt zu den zugrunde liegenden Ergebnissen, damit Nutzer die Rohdaten prüfen können.
Das ist angesichts der offen genannten Fehlerquellen wichtig: Many-to-many-Joins, Fehler beim Filter-Pushdown und unbehandelte Nullwerte, die „Ergebnisse unbemerkt verfälschen können“. Eine selbstsicher falsche Antwort über 70.000 Datensätze ist schlimmer als keine Antwort. Jede Aussage mit ihrer rohen Abfrageausgabe zu verknüpfen, ist die Art des Frontends, stille Fehler überprüfbar zu machen.
Das Sicherheitsmodell verstärkt das noch. Der Zugriff wird als „strikt durchgereicht“ beschrieben – Nutzer können nur Tabellen abfragen, für die sie ohnehin bereits Berechtigungen haben, und fehlt der Zugriff, weist der Agent darauf hin oder greift auf autorisierte Datensätze zurück. Die Oberfläche wird nie zu einem Weg, bestehende Berechtigungen zu umgehen.
Wiederkehrende Arbeit in wiederverwendbare Workflows verpacken
Nach dem Rollout stellte OpenAI fest, dass Nutzer „häufig dieselben Analysen für routinemäßige, sich wiederholende Aufgaben“ durchführten. Die Antwort darauf war eine Workflow-Funktion, die wiederkehrende Analysen in wiederverwendbare Anweisungssätze verpackt, mit wöchentlichen Geschäftsberichten und Tabellenvalidierungen als genannten Beispielen.
Das ist eine aufschlussreiche Frontend-Entscheidung. Die Konversationsoberfläche eignet sich gut für offenes Explorieren – der Beitrag stellt „Erzähl mir etwas über diese Tabelle“ gegen „Ich sehe hier einen Einbruch, können wir das nach Kundentyp und Zeitraum aufschlüsseln?“ –, aber Konversation passt schlecht zu Arbeit, die jede Woche identisch ist. Workflows kodieren Kontext und Best Practices einmalig, damit die Ergebnisse über Nutzer hinweg konsistent bleiben.
Die Implikation für Entwickler interner Agenten ist, dass eine reine Chatoberfläche unvollständig ist. OpenAI lieferte zunächst den konversationellen Agenten aus, beobachtete, was Menschen tatsächlich damit taten, und fügte dann einen zweiten Interaktionsmodus für den repetitiven Anteil hinzu. Das Frontend folgte der beobachteten Nutzung, statt anzunehmen, dass eine einzige Oberfläche sowohl explorative als auch routinemäßige Arbeit abdecken würde.
Find this story relevant to you?
Contact us to find a unique solution
Brauchen Sie einen KI-Engineering-Partner, der auch liefern kann?
Wir helfen Unternehmen dabei, KI in Produkte und Prozesse zu integrieren, wertvolle Workflows zu automatisieren und die zugrunde liegenden Softwaresysteme zu modernisieren.
Weiterführende Beiträge
Weitere Analysen rund um Produktbereitstellung, operative KI und die Systemarbeit, die dafür sorgt, dass der Einsatz in der Praxis Bestand hat.