Langlaufende KI-Agenten brauchen einen Wartestatus

Ein KI-Agent kann aus einem guten Grund aufhören zu arbeiten. Der fehlende Beleg ist noch nicht da. Jemand muss zwischen zwei plausiblen Deutungen entscheiden. Vor dem nächsten Schritt ist eine Prüfung nötig. Eine weitere generierte Antwort beseitigt keine dieser Abhängigkeiten.

Trotzdem belohnt die Diskussion über autonome Agenten vor allem ununterbrochene Aktivität. Längere Läufe, mehr Werkzeuge, mehr erledigte Schritte ohne einen Menschen. Das ergibt eine überzeugende Vorführung. Als Beschreibung von Software, die echte Arbeit abschließen soll, reicht es nicht.

Meine Position: Ein langlaufender Agent braucht einen ausdrücklichen Wartestatus, einen klaren Anlass zum Fortsetzen und einen verlässlichen Stand der bereits erledigten Arbeit. Sonst lässt sich eine Pause kaum von einem Absturz unterscheiden, und „weiter“ kann „noch einmal von vorn“ bedeuten. Unsere gespeicherten Workflow-Zustände bei Norman machen diesen Unterschied greifbar. Entscheidend ist, was diese Zustände aussagen, nicht die Menge der darin enthaltenen Aufgaben.

Was macht einen KI-Agenten langlaufend?

Ein langlaufender Agent behält eine Aufgabe über Unterbrechungen hinweg. Er kann kurz arbeiten, auf ein externes Ereignis warten und später fortfahren. Dafür muss während der gesamten Zeit kein Modell Antworten erzeugen. Dauernde Generierung wäre auch kein Beleg für nützlichen Fortschritt.

Die Branche bewegt sich in diese Richtung. Am 14. September 2026 stellte Salesforce eine Laufzeitumgebung für Ziele über Tage und Wochen vor; der erste Agent Hunter war im Pilotbetrieb. Am 15. September präsentierte Workiva Agent Studio mit Unternehmenskontext und zeitgesteuerten Abläufen.

Damit verändert sich die Produktfrage. Ein Chat-Assistent kann nach einer Antwort die Kontrolle zurückgeben. Ein fortbestehender Workflow muss erklären, wer als Nächstes handeln soll, wenn eine Antwort allein die Aufgabe nicht voranbringt. „Der Agent ist aktiv“ ist dafür zu ungenau.

Für Entwickler verändert sich die Arbeitseinheit. Das Gespräch, der Modellaufruf und das fachliche Ziel haben unterschiedliche Laufzeiten. Behandelst du sie als dasselbe Objekt, sieht eine normale Pause schnell wie ein technischer Fehler oder eine abgeschlossene Aufgabe aus. Daraus entstehen falsche Erwartungen an das System.

Ist ein wartender Agent ein gescheiterter Agent?

Manchmal ist Warten richtig. Manchmal verbirgt sich dahinter ein Fehler. Ein System braucht genügend Zustandsinformationen, um den Unterschied sichtbar zu machen, ohne dass du dafür den gesamten Gesprächsverlauf auswerten musst.

Stell dir einen Agenten vor, der Unterlagen zur Prüfung vorbereitet. Er hat das vorhandene Material zugeordnet und benötigt jetzt einen fehlenden Anhang. Die bisherige Zuordnung bleibt nützlich. Der nächste Schritt hängt von einem Beleg ab, den ein Modell nicht erfinden darf. „Läuft“ suggeriert weitere Berechnung. „Fehlgeschlagen“ verwischt den Unterschied zwischen fehlender Information und einem misslungenen Vorgang.

Die folgende Tabelle ist ein Vorschlag für die Gestaltung eines Produkts, keine Beschreibung einer bestimmten Anbieterimplementierung:

Diese Unterscheidungen helfen nur, wenn sie das Verhalten verändern. Ein Wartestatus, den der Scheduler sofort erneut ausführt, ist ein Etikett ohne verbindliche Bedeutung. Ein Fehlerstatus mit der einzigen Option „Frag den Agenten noch einmal“ schiebt die Wiederherstellung an dich zurück.

Was zeigten Normans Produktionsdaten?

Wir haben gespeicherte Workflow-Zustände für einen festen Zeitraum ihrer Erstellung mit ausschließlich lesenden Aggregatabfragen untersucht. Die Auswahl enthielt Workflows mit automatisierten Schritttypen. Geprüft wurden Zustandsmerkmale und als abgeschlossen markierte Schritte, ohne Gespräche, Dokumente oder Kundenidentitäten zu lesen.

Die Datensätze enthielten als aktiv bezeichnete Workflows, die ausdrücklich auf eine Nutzereingabe oder einen manuellen Schritt warteten. Bereits abgeschlossene Schritte bestanden neben diesen menschlichen Abhängigkeiten weiter. Der übergeordnete Lebenszyklusstatus verriet also nicht, ob gerade gerechnet wurde, ein Mensch handeln musste oder ein Teil der Aufgabe bereits erledigt war.

Die Prüfung zeigte außerdem eine Kombination aus einer Eingabeblockade und einem als laufend markierten Schritt. Das muss man vorsichtig interpretieren. Ein gespeichertes Laufmerkmal beweist keinen gerade arbeitenden Prozess. Eine Momentaufnahme erklärt weder den auslösenden Übergang noch, ob der Zustand vorübergehend war oder was die Person auf dem Bildschirm sah. Sie zeigt aber, warum konkurrierende Statusangaben eine festgelegte Interpretation brauchen.

Das ist kein Benchmark für Abschlussquoten und kein Nachweis, dass jede Pause berechtigt war. Wir haben weder Wartezeiten gemessen noch spätere Ergebnisse überprüft. Der engere Befund genügt: In den Betriebsdaten sind menschliche Abhängigkeiten und erledigte Arbeit unterscheidbar. Das einzelne Wort „aktiv“ verdeckt diese Unterscheidung.

Unser aktueller Runner-Code trennt diese Fälle bewusst. Er hält an einem manuellen Schritt an; eine ausdrückliche Eingabeanforderung lässt den aktuellen Schritt offen. Das beschreibt den Quellcode. Die Datenbankprüfung belegt nicht, welche ausgerollte Version jeden historischen Datensatz erzeugt hat. Die allgemeinere Rolle dieser Steuerung erklärt unser Artikel zum Agent Harness.

Was sollte ein Agent vor dem Warten speichern?

Ein brauchbarer Wartezustand ermöglicht die Fortsetzung, ohne das gesamte Gespräch rekonstruieren zu müssen. Er braucht die offene Frage, die blockierende Abhängigkeit, die erledigte Arbeit und das Ereignis, nach dem es weitergehen darf.

„Bitte prüfen“ ist eine schwache Aufforderung. „Beleg und Transaktion haben unterschiedliche Datumsangaben; entscheide, welches Dokument diesen Eintrag belegen soll“ beschreibt eine konkrete Entscheidung. Die Frage hängt vom Ablauf ab. Sie sollte aber erklären, warum der Agent die fehlende Antwort nicht verlässlich aus den verfügbaren Informationen ableiten kann.

Die Anforderung sollte auch benennen, wer handeln muss. Sonst sehen alle die Blockade, aber niemand weiß, ob sie bei ihm liegt. Du solltest antworten, einen zulässigen Schritt ausdrücklich überspringen oder die Aufgabe abbrechen können. Diese Ergebnisse bedeuten Unterschiedliches und müssen auch später unterscheidbar bleiben.

Das Speichern des Gesprächs allein reicht nicht. Ein Verlauf kann einen veralteten Plan und danach eine Korrektur enthalten. Die Anwendung braucht einen aktuellen Stand der abgeschlossenen Arbeit und der offenen Abhängigkeiten. Unser Artikel über Tool-Ergebnisse behandelt das verwandte Problem, fehlende Informationen von einem leeren Ergebnis zu unterscheiden.

An dieser Stelle würde ich zusätzliche autonome Überlegungen kritisch sehen. Ist die fehlende Voraussetzung bekannt, können weitere Denkschritte nur immer aufwendigere Vermutungen erzeugen. Die nächste sinnvolle Operation ist möglicherweise eine klare Frage. Danach kann der ausführende Prozess freigegeben werden, bis sich etwas Relevantes ändert.

Wie sollte ein KI-Agent nach einer Pause fortfahren?

Die Fortsetzung sollte mit der gespeicherten Aufgabe und den neuen Informationen beginnen. Sie sollte nicht automatisch jede im Chat beschriebene Aktion wiederholen. Während der Wartezeit kann eine Rechnung geändert, ein Anhang ersetzt oder die Aufgabe abgebrochen worden sein.

Ein praktikabler Ablauf prüft, ob die Aufgabe noch offen ist, ob die benötigte Eingabe vorliegt und ob frühere Schlussfolgerungen weiterhin gelten. Anschließend geht es beim frühesten betroffenen Schritt weiter. Unveränderte erledigte Arbeit bleibt erledigt. Veränderte Belege können dagegen die Neuberechnung eines bestimmten Ergebnisses erfordern.

Das ist eine vorgeschlagene Verhaltensregel, keine Behauptung, unsere Aggregatprüfung habe jeden Wiederaufnahmeweg getestet. Gespeicherter Fortschritt allein beweist insbesondere keine Wiederherstellung nach einem Prozessabsturz und verhindert keine doppelten externen Aktionen. Dafür sind eigene Implementierungen und Tests nötig. Unser Artikel über Wiederholungsversuche von Agenten erklärt die Bedeutung solcher Grenzen.

Eine menschliche Antwort sollte eine Abhängigkeit auflösen und nicht unbemerkt den Auftrag erweitern. Entsteht dadurch zusätzliche Arbeit, muss das System den neuen Umfang sichtbar machen. Sonst wird aus einer einfachen Rückfrage ein offener Auftrag, dessen Abschlussbedingungen sich ständig verschieben.

Wie bewertest du einen Agenten, der manchmal wartet?

Trenne die Zeit für die eigentliche Arbeit von der Zeit, in der ein anderer Akteur am Zug ist. Prüfe anschließend, ob die Rückfrage nützlich war. Benannte sie eine tatsächlich fehlende Information? Hätte der Agent die Antwort bereits finden können? Hat die Antwort den vorgesehenen Schritt freigegeben?

Der Abschluss ist wichtig. Eine einzelne Abschlusskennzahl beantwortet diese Fragen aber nicht. Ein Workflow kann schnell fertig werden, weil er eine unbelegte Annahme trifft. Er kann auch nach einer unklaren Rückfrage unbegrenzt warten. Beides verdient Aufmerksamkeit, obwohl die Zustände unterschiedlich aussehen.

Lass für eine Vorführung bewusst einen notwendigen Anhang fehlen. Sieh dir den Wartestatus an, füge den Anhang hinzu, ändere einen relevanten Sachverhalt und beobachte die Fortsetzung. Prüfe, ob erledigte Arbeit erhalten bleibt und das betroffene Ergebnis neu bewertet wird. Wiederhole den Versuch mit einem Abbruch. So prüfst du die Übergabe, die im reibungslosen Demofall unsichtbar bleibt.

An diesem Übergang würde ich das Versprechen langlaufender KI messen. Kann das Produkt erklären, warum es angehalten hat, nützliche Arbeit bewahren und auf veränderte Umstände angemessen reagieren? Dann hat es eine belastbare Grundlage für länger dauernde Aufgaben. Ein längerer ununterbrochener Lauf allein liefert diese Grundlage nicht.