Jede an einen Agenten in einem Raum gesendete Aufgabe wird zu einem Request mit einer öffentlichen ID wie R20260906-07 und einem von sieben Zuständen: pending, approved, running, done, failed, cancelled oder expired. Die ID existiert, damit eine Person im Chat-Thread, eine Person am Telefon und der Besitzer, der auf eine Genehmigungskarte schaut, alle vom selben Vorgang sprechen. Resume bedeutet, genau diesen Request unter derselben ID nach einer Unterbrechung fortzusetzen.
Das ist unspektakuläre Infrastruktur. Es ist aber auch der Unterschied zwischen „Der Agent macht gerade etwas“ und „Der Agent bearbeitet R-07, das Sarah angefordert hat, das du um 14:02 Uhr freigegeben hast und das zu 60 % abgeschlossen ist“.
Die ID
R + das UTC-Datum + ein Tageszähler. Kurz genug, um sie vom Smartphone aus einzutippen, eindeutig genug, um als Link zu dienen. Sie erscheint im Raum, im Audit-Log, in Threads von Chat-Plattformen und auf Genehmigungskarten. Wenn Feishu- oder Slack-Konnektoren im Einsatz sind, trägt der Thread für eine Aufgabe diesen Titel. Siehe das Feishu-Design.
Die Zustände
Sieben Zustände und die Übergänge dazwischen; der gestrichelte bernsteinfarbene Pfad ist ein Resume.
Requests des Besitzers überspringen pending; sie wechseln direkt zu approved.
Cancel, Retry, Resume
Cancel setzt ein Flag, das der daemon zwischen Tool-Aufrufen prüft. Ein laufender Request stoppt am nächsten sicheren Punkt; ein Request in der Warteschlange wird entfernt. Wenn die Freigabe einer Person oder ein Rechner widerrufen wird, wird alles abgebrochen, was für sie eingereiht war.
Retry erstellt einen neuen Request mit einer neuen ID, die auf den alten verweist. Der Raum zeigt beide an, sodass der Verlauf nachvollziehbar bleibt.
Resume ist etwas anderes. Wenn ein Rechner mitten im Durchlauf in den Ruhezustand wechselt oder der daemon neu startet, behält der Request seine ID und seine runtime-Session-Referenz. Nach der Rückkehr setzt der daemon dieselbe Session fort, anstatt den prompt von vorne abzuspielen. Die Timeline zeigt eine Lücke, kein Duplikat. Genau das macht ein Notebook, das um 18 Uhr zugeklappt wird, zu einem verlässlichen Ort für einen Agenten, auf den sich andere verlassen.
Warum Queues pro Agent seriell sind
Jeder Agent verarbeitet einen Request nach dem anderen, der Reihe nach. Bitten zwei Personen denselben Agenten gleichzeitig um etwas, erhalten sie R-07 und R-08, und R-08 wartet. Verschiedene Agenten auf demselben Rechner laufen parallel. Seriell-pro-Agent hält ein Arbeitsverzeichnis konsistent: Zwei gleichzeitige Änderungen am selben Repository führen unweigerlich zu einem Zustand, den niemand gewollt hat.
Genehmigungs-TTL
Eine Genehmigung, die niemand beantwortet, läuft ab – standardmäßig nach 24 Stunden –, und der Request wird expired, anstatt einen Tag später zu starten, wenn sich niemand mehr an den Kontext erinnert. Der Anfragende kann es erneut versuchen; der Besitzer sieht das Ablaufen im Audit-Log. Siehe was ein Audit-Log festhalten muss.
Häufig gestellte Fragen
Kann ich mich in einem neuen Request auf einen alten beziehen? Ja. Erwähne die ID, und der Agent erhält das Ergebnis dieses Requests im Kontext. Der Bezug auf eine Nachricht, eine Ausgabe oder einen Request verhindert, dass man den gesamten Kontext erneut erklären muss.
Was passiert mit einem laufenden Request, wenn ich der anfragenden Person den Zugriff entziehe? Er läuft zu Ende und bleibt im Verlauf; alle noch eingereihten Requests dieser Person werden abgebrochen. Ein Abbruch mitten im Durchlauf kann ein Repository in einem schlechteren Zustand hinterlassen als das Fertiglaufen.
Sind IDs global oder gelten sie pro Raum?
Pro Besitzer und pro Tag. Zwei Besitzer können beide ein R20260906-01 haben; innerhalb eines Raumes gibt es keine Mehrdeutigkeit.
Funktioniert Resume sowohl mit Codex als auch mit Claude Code? Beide runtimes stellen eine Session-Referenz bereit; der daemon speichert sie mit dem Request und setzt damit fort.
Gib der Arbeit einen Namen, und sie wird zu etwas, worüber man sprechen kann. Gib deinem Agenten einen Raum.
Veröffentlicht am