Auch ein ständig aktiver Agent braucht eine Stoppbedingung

Am 29. September stellte OpenAI dots vor: fortlaufend arbeitende Agenten mit eigenen Cloud-Computern. Diese Ankündigung rückt eine konkrete Gestaltungsfrage in den Vordergrund: Wenn ein Agent nach Ende eines Gesprächs weiterarbeiten kann, woran erkennt er, dass der Auftrag nicht mehr gilt? [1]

Ein Content-Team bittet einen Agenten, Material für eine Produkteinführung vorzubereiten. Dann wird die Einführung verschoben, das Ausgangsvideo ändert sich oder die verantwortliche Person verlässt das Projekt. Wer die alte Anweisung gewissenhaft weiterbefolgt, kann nun das Falsche erledigen. Unser Argument lautet: Ein wiederkehrender Auftrag braucht einen Lebenszyklus mit einem aktuellen Ziel, einem definierten Umfang, einer verantwortlichen Person und Bedingungen für den Stopp. Das sind Empfehlungen für den Einsatz fortlaufend arbeitender Agenten, keine Funktionen, die wir bei dots überprüft haben.

OpenAI trennt die proaktive Recherche von dots von nachfolgenden Handlungen. Laut Sicherheitsdarstellung verwendet diese Hintergrundrecherche nur lesende Werkzeuge; für anschließende Aktionen gelten weiterhin die üblichen Regeln und Prüfungen. Dieser besondere Recherchemodus darf nicht mit jeder autorisierten Aufgabe gleichgesetzt werden, die im Hintergrund weiterläuft. [2]

Für ein Team folgt daraus die Entscheidung, Beobachten, Vorbereiten und Veröffentlichen zu trennen. Eine neue Interviewdatei kann es rechtfertigen, einen Clip-Entwurf vorzubereiten. Sie berechtigt für sich genommen nicht zur Veröffentlichung über ein Markenkonto. Der Auftrag sollte das erlaubte Ergebnis festlegen: welche Materialien, welches Ziel, wessen Freigabe gegebenenfalls nötig ist und welche Änderungen diese Freigabe hinfällig machen. Wenn der Nutzer eine begrenzte wiederkehrende Handlung bereits autorisiert hat, sollte sie innerhalb dieses Rahmens ausgeführt werden; ihn bei jedem unkritischen Schritt erneut zu fragen, ist nicht das Ziel.

Die Dokumentation von OpenAI zu MCP Events beschreibt asynchrone Verarbeitung, erneute Zustellversuche und Ereignisse, die möglicherweise in anderer Reihenfolge eintreffen. Sie verlangt, Ereignis-IDs bei Wiederholungen beizubehalten und Schreibwerkzeuge so zu gestalten, dass wiederholte Aufrufe keine Änderungen doppelt ausführen. Eine Empfangsbestätigung ist daher ein anderer Meilenstein als die Erledigung der angeforderten Arbeit. Das sind dokumentierte Integrationsregeln, kein Beleg dafür, dass wir ein bestimmtes Plugin getestet haben. [3]

In einem Videoprozess sollte eine zweimal eintreffende Upload-Meldung nicht zu zwei öffentlichen Beiträgen führen. Ebenso wenig darf ein älterer Review-Kommentar eine neuere, bereits freigegebene Fassung überschreiben. Ein praktikabler Ansatz ist, Quelle, Version und beabsichtigte Aktion gemeinsam zu erfassen und diese Identität vor einem erneuten Schreibvorgang zu prüfen. Für die verantwortliche Person sollten die Zustände empfangen, in Vorbereitung, wartet auf Entscheidung, abgeschlossen und gestoppt unterscheidbar sein. Eine pauschale Anzeige wie »läuft« verbirgt gerade die Information, die sie für die Entscheidung über ein Eingreifen braucht.

Derselbe Leitfaden zu MCP Events verlangt, das Ende befristeter Abonnements zu behandeln und die Zustellung einzustellen, wenn der Zugriff entzogen wird. Die Laufzeit eines Abonnements steuert die Ereigniszustellung; sie bestimmt für sich genommen nicht, wann ein Geschäftsziel überholt ist. Diese zweite Grenze muss gesondert gestaltet werden. [3]

Wir empfehlen, für jeden wiederkehrenden Auftrag eine verantwortliche Person, einen Prüftermin, den erlaubten Umfang und Stoppbedingungen festzuhalten. Das Ende einer Kampagne, der Rückzug einer Quelle oder der Weggang der verantwortlichen Person können eine Prüfung auslösen. Vor einer Änderung außerhalb des eigenen Systems sollte geprüft werden, ob der Auftrag und die betreffende Quellversion noch aktuell sind. Wenn ein Agent Arbeit delegiert, müssen die geltenden Grenzen für die delegierte Aufgabe mitgegeben werden; außerdem sollte getestet werden, was beim Stopp der übergeordneten Aufgabe geschieht. Ein Stoppauftrag sollte ein beobachtbares Ergebnis haben, aus dem auch hervorgeht, welche Schritte bereits abgeschlossen sind und welche noch laufen.

Im FAQ zu dots erklärt OpenAI, dass das Trennen eines Plugins neuen Zugriff unterbindet, bereits gespeicherten Kontext aber nicht löscht. Es unterscheidet außerdem zwischen dem Löschen eines dot und dem Löschen separat gespeicherter Dateien oder Gespräche. Das sind produktspezifische Fakten; die allgemeinere betriebliche Lehre ist, den Zustand zu benennen, der geändert wird. [4]

Ein Projektabbruch kann bedeuten, künftige Arbeit zu stoppen, eine Verbindung zu widerrufen, Arbeitsmaterial zu archivieren oder gespeicherten Kontext zu entfernen. Das sind getrennte Ergebnisse. Verantwortliche müssen wissen, was davon geschehen ist und wofür ein weiterer Schritt nötig ist. Ein Status »abgebrochen« darf nicht so wirken, als hätte er eine bereits versandte Nachricht zurückgenommen. Ebenso wenig darf man annehmen, dass das Entfernen einer Integration sämtliche Kopien zuvor erhaltener Daten löscht. Das gewünschte Ergebnis ist festzulegen und in den Systemen zu prüfen, die den jeweiligen Zustand speichern.

Ein sinnvoller erster Versuch ist ein enger, rückgängig zu machender Ablauf: eine genehmigte Quelle beobachten und einen Entwurf für eine namentlich bestimmte prüfende Person vorbereiten. Dann gezielt ein Ereignis doppelt senden, die Quelle während der Vorbereitung aktualisieren, Zugriff entziehen, die übergeordnete Aufgabe abbrechen und ein gewähltes Zeit- oder Kostenbudget ausschöpfen. Zu prüfen sind doppelte Änderungen, veraltete Entwürfe, weiterlaufende delegierte Aufgaben und klare Erklärungen dafür, warum die Arbeit stoppte. Eine Budgetgrenze muss im tatsächlichen Ausführungssystem durchgesetzt werden; ein Satz im Prompt ist kein Nachweis für eine feste Obergrenze.

Dabei gibt es einen echten Zielkonflikt. Zu viele Rückfragen machen den Agenten zu einem weiteren Posteingang, der betreut werden muss. Deshalb sollten Befugnisse für Routinehandlungen ausdrücklich festgelegt und Eingriffe auf Änderungen des Umfangs, folgenreiche Schritte oder ungeklärte Bedingungen konzentriert werden. Öffentliche Unterlagen belegen nicht, wie zuverlässig jede Integration solche Fälle behandelt, und wir haben keine Bewertung im Produktivbetrieb durchgeführt. Die Einführung macht eine Abnahmefrage aktuell: Kann das System unpassend gewordene Arbeit ebenso zuverlässig stoppen, wie es nützliche Arbeit beginnt?