Eine Aufgabe an einen Agenten delegieren

Ein Projektagent bearbeitet eine Aufgabe und legt das Ergebnis zur Prüfung vor. Weise ihm die Arbeit zu, starte den Lauf und halte Rückmeldungen an der Aufgabe fest. Du musst die Aufgabe ändern dürfen: Redakteure und höhere Rollen dürfen das bei jeder Aufgabe im Projekt, Mitglieder bei den Aufgaben, die sie erstellt haben oder die ihnen zugewiesen sind. Außerdem müssen Anbieter, passende Agent-Laufzeit und Sandbox-Kapazität verfügbar sein.

Die Aufgabe vorbereiten und starten

1. Erstelle eine Aufgabe mit gewünschtem Ergebnis, Abschlusskriterien und Eingabedateien.
2. Wähle unter Zuständig einen Projektagenten.
3. Wenn du das Projekt bearbeiten darfst, wähle unter Reviewer eine Person oder einen unabhängigen Agenten oder belasse es beim Projektstandard. Anfangs leitet der Projektstandard Reviews an einen berechtigten Aufgaben- oder Projektersteller. Zuständigkeit und Prüfung festlegen erklärt die Auswahl, Berechtigungen und offenen Übergaben.
4. Klicke auf Agent starten oder verschiebe die Aufgabe nach In Bearbeitung. Weist du den Agenten schon beim Erstellen der Aufgabe zu, erledigt Erstellen und Agent starten in Aufgabe erstellen das im selben Schritt.

Die Zuweisung allein startet keinen Lauf. Eine bereits zugewiesene Aufgabe kann im Backlog bleiben, bis das Team ihren Start beschließt. Bis jemand den Agenten startet, zeigt die Aufgabe allen, die ihn starten dürfen, Agent starten mit dem Hinweis Der Agent wartet, bis du ihn startest. Nach dem Start verwendet der Agent Beschreibung, Kommentare und Eingabedateien in seiner Sandbox. Die Laufanzeige zeigt, ob er wartet oder arbeitet. Ein Lauf, den ein Mitglied startet, bleibt bei seiner Aufgabe und kommt ohne die Secrets des Agenten aus; Agentenläufe, die ein Mitglied startet zählt auf, was sich ändert.

Agenten erhalten die Anweisung, Aktualisierungen, Berichte, zugehörige Aufgaben und Rückfragen in der Sprache von Titel und Beschreibung der Aufgabe zu verfassen. Ist daraus keine Sprache erkennbar, verwenden sie die Standardsprache der Organisation für Agenten. Eine Kennung, ein Quartal oder eine automatisch ausgefüllte Titelvorlage legt keine Sprache fest. Ein Wechsel deiner Oberflächensprache ändert die Sprache der Aufgabe nicht; du kannst den Agenten ausdrücklich um einen Sprachwechsel bitten.

Fortschrittskommentare eines Workflows können Übersetzungen für jede unterstützte Oberflächensprache enthalten. Derselbe gespeicherte Kommentar erscheint dann in der jeweils gewählten Sprache. Kommentare ohne Übersetzungen behalten ihren ursprünglichen Text.

Das Ergebnis lesen und annehmen

Der Agent schreibt seinen Bericht als Aufgabenkommentar und legt erzeugte Dateien als Ergebnisse ab. Danach wechselt die Aufgabe auf In Prüfung. Ein menschlicher Reviewer erhält eine Benachrichtigung und bei eingerichtetem E-Mail-Versand auch eine E-Mail. Ein Reviewer-Agent liest das ausstehende Review von seiner eigenen Aufgabe aus; die Zuweisung einer Prüfung startet ihn nicht automatisch.

Bereitgestellte oder übersprungene Dateien führt Tale in einem separaten Systemkommentar in deiner Oberflächensprache auf. Dort steht auch, wenn der Bericht fehlt oder gekürzt wurde. Der Bericht selbst bleibt in der Sprache der Aufgabe.

Bei einer menschlichen Prüfung liest du den Bericht, öffnest die Dateien und vergleichst sie mit den Abschlusskriterien. Setze die Aufgabe erst auf Erledigt, wenn du die Arbeit annimmst. Tale hält die Entscheidung fest; der Agent, der das Ergebnis erstellt hat, darf es nicht selbst freigeben.

Ist das Review einer Person zugewiesen, steuert Reviewer Benachrichtigung und Prüfwarteschlange, ohne die Entscheidung allein dieser Person vorzubehalten. Andere Personen, die die Aufgabe ändern dürfen, können sie ebenfalls annehmen; die Regeln der Organisation für unabhängige Reviews und Kompetenzen gelten dabei weiterhin. Ein ausstehendes Review eines Agenten muss ausdrücklich an eine berechtigte Person übertragen werden, bevor ein Mensch es freigeben kann. Die Zuständigkeit für die Umsetzung bleibt bei einem Reviewer-Wechsel bestehen; Einzelheiten stehen unter Zuständigkeit und Prüfung festlegen.

Änderst du den Reviewer, während die Aufgabe unter In Prüfung wartet, überträgst du die gespeicherte Anfrage. Die Benachrichtigung des bisherigen menschlichen Reviewers wird erledigt. Eine neue Person erhält die Anfrage; ein einem Agenten zugewiesenes Review wartet auf diesen Agenten. Projektstandard verwendet die aktuelle Auswahl des Projekts. Ändern sich Review oder Ergebnis gleichzeitig, wird die Übergabe abgelehnt. Lies den aktualisierten Stand, bevor du es erneut versuchst.

Einen unabhängigen Reviewer einrichten

1. Erstelle einen eigenen Projektagenten für Reviews. Erteile ihm unter Skills, Connectors & Tools die Berechtigungen Aufgaben finden, Aufgabe lesen und Aufgabenergebnisse anderer Agenten prüfen. Die Review-Berechtigung ist anfangs ausgeschaltet und steht Agent-Nodes in Automatisierungen nicht zur Verfügung.
2. Wähle diesen Agenten als Standard-Reviewer des Projekts oder ausdrücklich unter Reviewer einer Aufgabe. Eine bereits ausstehende Prüfung überträgst du über die Reviewer-Auswahl der Aufgabe; eine Änderung des Projektstandards allein reicht dafür nicht.
3. Gib dem Reviewer eine eigene Aufgabe und die Anweisung, nur ihm zugewiesene Reviews zu prüfen. Starte diese Aufgabe direkt oder über einen bestehenden Zeitplan. Starte keinen neuen Umsetzungslauf auf der Aufgabe, deren Ergebnis geprüft wird.
4. Verlange, dass der Reviewer die aktuelle Prüfung liest, den tatsächlichen Bericht und die Ergebnisdateien untersucht und konkrete Prüfergebnisse samt Rückmeldung festhält. Die Entscheidung muss sich auf denselben abgeschlossenen Lauf und dieselben Belege beziehen, die er gelesen hat. Ein geändertes Ergebnis muss er erneut lesen und prüfen.

Bei einem gespeicherten Agentenreview listet task_get.reviewFiles Anhänge und Ergebnisdateien in Seiten mit jeweils 50 Einträgen. Übergib reviewFiles.page.continueCursor als reviewFileCursor, um weiterzulesen. Mit task_review, operation: "stage_file", dem aktuellen expected: {approvalId, runId, evidenceRevision} und einer aufgeführten fileId kann der Reviewer eine verfügbare Datei von höchstens 20 MiB in seinen Arbeitsbereich kopieren. Anschließend muss er den zurückgegebenen Pfad öffnen und den Inhalt prüfen: Das Bereitstellen allein belegt keine inhaltliche Prüfung.

Ein unavailableReason erklärt, warum eine Datei nicht bereitgestellt werden kann, etwa wegen eines nicht unterstützten Speichers, fehlender oder mehrdeutiger Metadaten, ihrer Größe oder einer geschützten Dokumentzuordnung. Die Zugriffsregeln für Dokumente gelten weiterhin. Bei einer geänderten Quelle oder einem anderen Reviewer ist ein erneutes Lesen nötig. Ändert sich die Berechtigung während der Übertragung, meldet der Vorgang keinen Erfolg. Zuvor berechtigt übertragene Bytes können im Arbeitsbereich bleiben, erlauben aber keine veraltete Entscheidung.

Eine Freigabe verschiebt die geprüfte Aufgabe nach Erledigt. Fordert der Reviewer Änderungen an, wird seine Rückmeldung gespeichert und die Aufgabe unter Beibehaltung ihrer Zuweisung nach Zu erledigen verschoben. Keine der beiden Entscheidungen startet einen neuen Lauf. Auch eine Agentenerwähnung in dieser Rückmeldung löst keine Arbeit aus: Eine berechtigte Person, ein Manager oder ein Zeitplan muss den nächsten Versuch separat starten. Die Aktivität nennt den Reviewer-Agenten und seine Entscheidung.

Für eine gespeicherte Änderungsanforderung ruft der Manager task_start_agent mit taskId und resumeFrom: {kind: "review_repair", approvalId, runId} auf. Die IDs bezeichnen die abgelehnte Prüfung und den geprüften Umsetzungslauf. Der Server wählt dessen Agenten und übernimmt die gespeicherte Rückmeldung sowie feedbackCommentId in den Überarbeitungsauftrag. Zusätzlicher Text in feedback muss zusammen mit dieser Rückmeldung und dem vorangestellten Identitätsnachweis in die bestehende Grenze von 10.000 UTF-16-Codeeinheiten passen.

Die Überarbeitung startet nur, solange die Aufgabe Zu erledigen ist, demselben Agenten gehört und derselbe abgeschlossene Umsetzungslauf der neueste ist. Eine neuere Prüfung oder eine zwischenzeitliche Änderung an Status, Zuständigkeit oder Archivierung verhindert den Start. Das gilt auch, wenn jemand anschließend den alten Wert wiederherstellt. Bei stale_repair ändert sich nichts: Der Manager liest die Aufgabe erneut und verwirft den überholten Auftrag. Er versucht es nie ohne die gekennzeichnete Absicherung. Die Überarbeitung durchläuft den normalen Ablauf und legt nach Abschluss eine neue Prüfung an; moveToInProgress: false wird abgelehnt.

Geht die Antwort verloren, darf derselbe Manager-Agent den abgesicherten Aufruf aus einem aktuell berechtigten aktiven Lauf wiederholen, auch bei einer späteren Ausführung. replayed: true liefert die ursprüngliche runId und repairReceipt, behält den ersten auslösenden Lauf bei und startet keine weitere Arbeit. Der Beleg bestätigt einen früheren Start, nicht einen weiterhin aktiven Lauf. Delegationsberechtigung und Projektzugriff werden bei jedem Aufruf erneut geprüft. Für neue Starts gelten weiterhin die Grenzen für gleichzeitig aktive Läufe und drei automatisierte Starts je Aufgabe innerhalb einer Stunde. Wiederholte unveränderte Fehler brauchen eine eigene Untersuchungsaufgabe statt unbegrenzter Wiederholungen.

Um eine verlorene Entscheidungsantwort in einer späteren Prüferausführung abzugleichen, liest der Agent task_get.reviewDecision. Das Feld enthält den neuesten gültigen nativen Entscheidungsbeleg. Bei einer neueren offenen, menschlichen oder Workflow-Prüfung sowie bei einem nicht verfügbaren Beleg ist es null. Vergleiche die Prüfungs- und Lauf-IDs mit dem gespeicherten Auftrag und lies den aktuellen Aufgabenstatus separat. Ein früherer Beleg beschreibt nicht die heutige Spalte; null beweist nicht, dass eine Entscheidung ungespeichert blieb. Ein sofortiger identischer task_review-Aufruf zur Wiederholung braucht weiterhin denselben aktiven auslösenden Lauf.

Für beide Entscheidungen muss der Reviewer ein anderer Agent sein als der, der das Ergebnis tatsächlich erstellt hat. Er braucht einen aktiven Lauf mit projektweiten Rechten und die weiterhin erteilte Review-Berechtigung; ein von einem Mitglied gestarteter Lauf darf keine Reviews entscheiden. Eine Richtlinie für unabhängige menschliche Prüfung oder erforderliche Kompetenznachweise leitet neue Reviews in die menschliche Prüferkette; ein bereits einem Agenten zugewiesenes Review muss ausdrücklich an eine berechtigte Person übertragen werden. Workflow-Genehmigungen und Fragen an Personen behalten ihre menschlichen Entscheidungsschritte. Lies vor einer Entscheidung pendingReview.agentReviewBlockedReason, um aktuelle Probleme mit Quelle, Berechtigung, Identität oder Richtlinie zu erkennen. Gehört GitHub-Arbeit zum Ergebnis, muss der Reviewer den genannten Commit und die Prüfungen selbst kontrollieren: Tale speichert seine Belege, prüft aber weder den aktuellen GitHub-Stand unabhängig noch führt es mit der Review-Entscheidung einen Pull Request zusammen.

Ein gespeichertes Review weitergeben

Mit Offene Agentenreviews weitergeben kann ein Manager ein ausstehendes Agentenreview an einen anderen geeigneten Agenten desselben Projekts übergeben. Der Empfänger braucht bereits Aufgabenergebnisse anderer Agenten prüfen, den nötigen Zugriff auf die Arbeit und Unabhängigkeit vom ausführenden Agenten. Der Manager darf sich das Review nicht selbst zuweisen und keine menschliche oder Workflow-Prüfung umwandeln. Der ausführende Agent darf das Review seiner eigenen Arbeit nicht weitergeben. Diese Berechtigung ist von der Review-Entscheidung getrennt und startet keine Arbeit.

Der Manager liest task_get, übernimmt die vollständigen IDs der Freigabe, des Quelllaufs und des gespeicherten Reviewers sowie evidenceRevision und ruft task_delegate_review mit dieser Erwartung, der vollständigen reviewerAgentId des Empfängers und einer Begründung auf. Geänderte Quellen, Belege, Berechtigungen oder Richtlinien verhindern die Übergabe. Aufgabenverantwortung, Status und künftige Reviewer-Einstellungen bleiben gleich. Falls ein Lauf nötig ist, erfolgt der normale Start auf der eigenen Prüfaufgabe des Empfängers, nie auf der beurteilten Implementierungsaufgabe.

Geht die Antwort verloren, liest der Manager task_get.reviewDelegation und das aktuelle pendingReview. Der Beleg nennt die vorige und die neue Freigabe-ID, beide Reviewer, Quelle, Belege, Manager, auslösenden Lauf, Begründung und Zeitpunkt. Er beschreibt den früheren Vorgang und beweist weder ein weiterhin offenes Review noch einen gestarteten Reviewer. Eine identische Wiederholung verlangt denselben aktiven und berechtigten Managerlauf sowie unveränderte Folgeprüfung und Belege. Ein späterer Lauf gleicht den Beleg mit dem aktuellen Zustand ab, statt einen alten Auftrag erneut auszuführen.

Änderungen anfordern

Beschreibe die nötige Änderung in einem Aufgabenkommentar und erwähne den zuständigen Agenten mit @. Die Erwähnung ist eine Anweisung: Ein aktiver Agent kann sie während seines Laufs erhalten. Ein wartender Agent beginnt einen Überarbeitungslauf, der das bisherige Gespräch fortsetzt. Das Ergebnis landet erneut unter In Prüfung.

Hast du einen Lauf gestartet, lenken deine Erwähnungen ihn auch dann weiter, wenn die Aufgabe an den Agenten übergegangen ist, etwa weil deine Erwähnung ihm eine Aufgabe übergeben hat, die dir zugewiesen war. Startet die Laufzeit des Agenten neu, um einen Kommentar aufzunehmen, wie es alle Laufzeiten außer Claude Code tun, gehört der Rest des Laufs der Person, die den Kommentar geschrieben hat: Er zählt gegen ihre Limits, und seine Connector-Aufrufe erfolgen in ihrem Namen.

Ein Kommentar ohne Erwähnung hält eine Notiz fest, ohne diese Agentenaktion zu starten. Die Erwähnungsauswahl zeigt an, wenn ein Agent nicht reagieren kann, etwa weil die Aufgabenautomatisierung ausgeschaltet oder pausiert ist oder weil du die Aufgabe zwar kommentieren, aber nicht ändern darfst.

Bei einer Aufgabe mit zuständiger Automatisierung erwähnst du diese Automatisierung für einen weiteren Lauf. Die Erwähnung einer anderen Automatisierung überträgt weder die Zuständigkeit noch startet sie diese. Automatisierungen erklärt Workflows mit mehreren Schritten.

Eine Aufgabe kann nur einen eingereihten, laufenden oder wartenden Lauf zugleich haben, egal welche Automatisierung ihn gestartet hat. Ein erneuter Start während dieser Zeit verweist auf den vorhandenen Lauf, auch wenn er eine andere Automatisierung nennt. Nach dessen Ende kann ein weiterer Start einen neuen Lauf erzeugen und die Arbeit wiederholen. Prüfe deshalb den aktuellen Lauf und seine Auswirkungen vor einem weiteren Versuch.

Einen Manager-Agenten die Warteschlange betreuen lassen

Ein Manager-Agent ist ein Projektagent, der laut seinen Anweisungen das ganze Board liest, startbereite Arbeit verteilt und die Routinefragen anderer Agenten beantwortet, damit Personen nur noch sehen, was ihr Eingreifen braucht. Er liest mit Aufgaben finden und Aufgabe lesen; keines der beiden Tools ändert etwas.

Die ganze Warteschlange in Durchgängen lesen

Aufgaben finden liefert höchstens 50 Aufgaben auf einmal. Solange eine Seite isDone: false meldet, bringt ihr continueCursor, als cursor mit denselben Argumenten zurückgegeben, die nächste Seite; die letzte Seite meldet isDone: true. Ein Cursor, der mit anderen Filtern, einer anderen Reihenfolge oder aus dem Lauf eines anderen Projekts zurückkommt, wird abgelehnt, ebenso ein beschädigter: Er wird nie als erste Seite gelesen. Eine Gesamtzahl erscheint nur, wenn eine einzige Seite alle passenden Aufgaben enthält.

Um eine ganze Warteschlange durchzugehen, verwende order: "created". Die Aufgaben kommen dann nach ihrer Erstellung geordnet, die älteste zuerst, und behalten ihren Platz. So nennt ein Durchgang jede Aufgabe höchstens einmal, in dem Zustand, den sie beim Lesen ihrer Seite hat. Die Standardreihenfolge gruppiert die Aufgaben nach Status und behält darin die Reihenfolge der Spalte bei. Eine Aufgabe, die sich bewegt, während der Manager blättert, kann dabei fehlen oder doppelt erscheinen.

Jede aufgeführte Aufgabe enthält pendingReview: null oder die gespeicherte approvalId, die runId des Umsetzungslaufs und den typisierten reviewer. Ein Reviewer findet seine Warteschlange mit status: "in_review" und seiner Agenten-ID in reviewerAgentId. Der Filter gilt für den gespeicherten Review-Empfänger, nicht für den zuständigen Umsetzungsagenten oder den heutigen Projektstandard. Behalte ihn bei jeder Cursor-Anfrage bei. Der Manager liest außerdem alle Aufgaben mit in_review, um Reviews gelöschter Agenten zu finden, und prüft anschließend task_get.pendingReview.agentReviewBlockedReason für die nötige Korrektur. Agentenreviews bleiben in dieser Aufgabenwarteschlange; die persönliche Review-Liste auf der Startseite ist für menschliche Anfragen.

Ein Durchgang kann länger dauern als ein Lauf. Bevor sein Lauf endet, hält der Manager den Zwischenstand in einem Kommentar auf seiner eigenen Aufgabe fest: den Durchgang, dessen Reihenfolge und Filter, den nächsten continueCursor und die zuletzt geprüfte Aufgabe. Sein nächster Lauf findet diesen Kommentar mit Aufgabe lesen und macht dort weiter. Ist ein Durchgang zu Ende oder wird sein Cursor abgelehnt, beginnt der nächste auf der ersten Seite. Ein fehlgeschlagener Lesevorgang ist keine leere Warteschlange: Der Manager meldet ihn und hört auf.

Laufende, beendete und wartende Arbeit unterscheiden

Aufgabe lesen nennt Unteraufgaben, Blocker und Kommentare mit ihren IDs und blättert mit commentCursor zu älteren Kommentaren zurück. Außerdem listet es die Läufe der Projektagenten auf der Aufgabe, den neuesten zuerst, jeweils mit den ersten 500 Zeichen der Nachricht, die ihr Start mitgab, dazu den Automatisierungslauf der Aufgabe und eine offene Prüfanfrage:

• Ein Lauf mit live: true ist eingereiht oder läuft, und bis er endet, startet auf der Aufgabe nichts anderes.
• Ein Lauf, der abgeschlossen, fehlgeschlagen oder abgebrochen ist, ist beendet; settledAt nennt den Zeitpunkt.
• retryPending: true bedeutet, dass für den neuesten fehlgeschlagenen Lauf noch eine automatische Wiederholung mit verfügbarem Versuchskontingent vorgemerkt ist. Überlass diese Wiederholung Tale. Bei false steht für diesen Lauf keine Wiederholung aus; fehlt das Feld auf einer älteren Plattform, ist der Zustand unbekannt. Es nennt weder einen Rücksetzzeitpunkt des Anbieters noch erlaubt es einen Neustart: Lies zuerst Aufgabe, Zuständigkeit, Läufe und Prüfung neu und beachte dann die Wartezeit des Anbieters sowie retryAfter einer Startablehnung.
• Ein workflowRun, der auf eine Frage (ask) oder Genehmigung (approval) wartet, wartet auf eine Person. Eine pendingReview nennt ihren menschlichen Reviewer oder Reviewer-Agenten. Der Manager überlässt ihm die Entscheidung, sofern er nicht selbst der zugewiesene unabhängige Reviewer mit der nötigen Berechtigung ist.

Transkripte, Fehlertexte und Ergebnisse gehören nicht zur Antwort, ebenso wenig etwas aus einem anderen Projekt.

Eine Routinefrage beantworten

Eine Routinefrage ist eine Frage, die der Manager aus dem beantworten kann, was das Projekt bereits festhält. Schreib dasselbe Vorgehen in die Anweisungen der arbeitenden Agenten und des Managers:

1. Der arbeitende Agent stellt die Frage als Aufgabenkommentar mit einem festen Fragenschlüssel, seinen Belegen und der Frage. Er nennt in seinem Ergebnis die ID des Kommentars und die ID seines Laufs (Aufgabe lesen zeigt diesen Lauf auf seiner Aufgabe als den aktiven) und beendet den Lauf, statt darin zu warten. Erwähnt er den Manager in diesem Kommentar, startet das nichts: Ein Kommentar eines Agenten startet nie einen Agenten.
2. Bei seinem nächsten Durchgang antwortet der Manager nur, solange die Aufgabe noch auf diese Frage wartet: Der fragende Lauf ist der neueste Lauf der Aufgabe und beendet, auf der Aufgabe ist kein Lauf aktiv, und die Aufgabe wartet auf die Prüfung genau dieses Laufs (pendingReview.runId). Aus diesem Lesevorgang behält er die ID des Laufs und pendingReview.approvalId. Hat jemand die Aufgabe inzwischen weitergebracht, indem sie das Ergebnis angenommen, die Aufgabe abgebrochen oder Änderungen verlangt hat, beantwortet der Manager die Frage nicht mehr, sondern meldet sie.
3. Er schreibt seine Antwort als Kommentar, der die Kommentar-ID der Frage nennt; die Antwort bleibt auf der Aufgabe, was auch immer danach geschieht. Dann setzt er den Agenten mit Andere Agenten auf Aufgaben starten fort. Er übergibt resumeFrom: {runId, approvalId} mit den beiden IDs, die er behalten hat, dazu eine Nachricht, die mit dem Fragenschlüssel, der ID des Laufs und der Kommentar-ID der Antwort beginnt: Aufgabe lesen zeigt später nur die ersten 500 Zeichen der Nachricht eines Starts. Der Start prüft in dem Moment, in dem er geschieht, ob das noch die offene Frage der Aufgabe ist. Nur dann zieht er die offene Prüfanfrage zurück, ohne das Ergebnis anzunehmen, und setzt den Agenten fort.
4. Antwortet der Start mit stale_question, wurde die Frage zwischen dem Lesen des Managers und dem Start überholt: Eine Entscheidung liegt vor, es gibt einen neueren Lauf oder eine neuere Prüfanfrage, oder die Zuständigkeit hat sich geändert. Geändert wurde nichts. Der Manager liest die Aufgabe erneut und lässt die überholte Frage fallen. Er startet nicht noch einmal und nie ohne resumeFrom.
5. Geht die Rückmeldung des Starts verloren, liest der Manager die Aufgabe erneut, bevor er etwas anderes versucht: Ein neuerer Lauf, dessen Nachricht mit diesem Fragenschlüssel, dieser Lauf-ID und dieser Kommentar-ID der Antwort beginnt, zeigt, dass der Start durchgegangen ist. Wird derselbe Start noch einmal gesendet, antwortet er mit stale_question und ändert nichts.

Eine Frage aus einer Daueraufgabe, die ein Zeitplan mit moveToInProgress: false startet, wartet auf keine Prüfung. Der Manager schreibt dort nur seine Antwort, und der Lauf beim nächsten Termin des Zeitplans liest sie. Weder der Manager noch sonst jemand startet die Aufgabe vorzeitig, um die Antwort zuzustellen.

Fragen einer Automatisierung und Workflow-Genehmigungen bleiben Sache von Personen. Ein Manager darf ein Review von Projektagentenarbeit nur über den oben beschriebenen unabhängigen Prüfablauf entscheiden, wenn es ihm zugewiesen ist. Das Lesen oder Fortsetzen einer Aufgabe nimmt ihr Ergebnis nicht an.

Wartende und fehlgeschlagene Läufe behandeln

Bei behebbaren Fehlern folgen bis zu drei automatische Wiederholungsversuche, die bis auf die unten beschriebenen Fälle sofort starten. Ein Lauf, der mindestens fünfzehn Minuten Fortschritt macht, erhält ein neues Versuchskontingent. So kann lange Arbeit Unterbrechungen überstehen. Die Richtigkeit des Ergebnisses musst du trotzdem prüfen.

Beendet Codex einen Lauf, weil das gewählte Modell ausgelastet ist, plant Tale die automatische Wiederholung eine Minute später. Der fehlgeschlagene Versuch zählt weiterhin für die normale Wiederholungsgrenze und bei automatisierten Starts für die stündliche Grenze. Tale lässt das bisherige Konto weiter zur Auswahl zu, wechselt kein Modell und pausiert keine anderen Agenten. Die Wartezeit garantiert nicht, dass das Modell danach verfügbar ist. Verweigert eine dieser Grenzen weitere Arbeit, kann die Aufgabe mit einem fehlgeschlagenen Lauf unter In Bearbeitung bleiben. Die Spalte allein bedeutet nicht, dass noch ein Agent arbeitet.

Reagiert ein Agent nicht mehr, gibt er also standardmäßig 45 Minuten lang nichts aus und arbeitet kaum, stoppt seine Sandbox ihn. Der Lauf schlägt dann ohne automatische Wiederholung fehl, weil eine Wiederholung höchstwahrscheinlich genauso stehen bliebe. Der Hinweis sagt, dass der Agent nicht mehr reagiert hat, und Anzeigen am Lauf im Verlauf der Aufgabe zeigt, was er zuletzt ausgegeben hat.

Eine automatische Wiederholung setzt die Arbeit der Person fort, die den Lauf gestartet hat. Sie startet deshalb nur dort, wo diese Person den Lauf jetzt selbst starten könnte: Das Projekt muss noch aktiv sein, und sie muss die Aufgabe weiterhin ändern dürfen. Archiviert ein Admin das Projekt, verlässt die Person die Organisation oder darf sie die Aufgabe nicht mehr ändern, startet keine weitere Wiederholung, und der Lauf bleibt fehlgeschlagen. Das gilt auch für eine Erwähnung, die den Agenten erst nach dem Ende seines Laufs erreicht. Sobald das Projekt wiederhergestellt ist, kann jeder, der die Aufgabe ändern darf, Erneut ausführen nutzen.

Bevor ein neuer Lauf mit der Arbeit beginnt, kann sich eine kurze Verbindungsstörung zum Abo-Broker innerhalb desselben Laufs beheben. Hat der Lauf die vollen Berechtigungen des Agenten, sendet Tale höchstens drei GET-Anfragen mit mindestens fünf und danach zehn Sekunden Abstand. Für die Anfragen und die Annahme des Ergebnisses gilt ein gemeinsames Budget von 60 Sekunden. Innerhalb dieses Abrufs hält Tale die vom Broker verlangte Wartezeit ein oder bricht ab, wenn sie nicht mehr ins Budget passt. Diese Wartezeit wird nicht auf einen späteren Lauf übertragen; die Regeln für Wiederholungen und stündliche Starts gelten weiterhin. Datenbank- und DNS-Prüfungen sowie das Schließen der Verbindung können die abschließende Ablehnung verzögern. Diese Anfragen zählen weder als zusätzlicher Aufgabenstart noch als automatische Wiederholung. Vor einer weiteren Anfrage und vor der Rückgabe eines Tokens prüft Tale den Lauf und den Zugang erneut. Für eingeschränkte Läufe von Mitgliedern, POST-Broker, abgelehnte Zugänge und pausierende Broker-Konten ändert sich nichts.

Ein Agent, der über einen Abo-Broker arbeitet, kann sein Token mitten in der Arbeit verlieren, wenn der Broker das Konto erneuert. Die Wiederholung setzt die Konversation dann mit einem neuen Token fort, ohne den Versuchszähler zu erhöhen: Sie zeigt denselben Stand wie der Lauf, den sie ersetzt. Zeigte dieser keinen oder hatte er mindestens fünfzehn Minuten gearbeitet und damit ein neues Versuchskontingent erhalten, steht dort Nach einer Token-Erneuerung fortgesetzt. Nach zwei solchen Unterbrechungen in Folge zählt eine weitere wie jeder andere Fehler.

Ein Lauf kann auch gar nicht erst starten, weil alle Konten seines Abo-Brokers nach Erreichen eines Rate-Limits pausieren. Seine Wiederholung wird dann sofort eingereiht, startet aber erst, sobald das erste Konto wieder verfügbar ist, spätestens eine Minute später. Die Wartezeit verbraucht keinen Versuch, wenn der abgelehnte Lauf unmittelbar auf einen HTTP-429-Fehler desselben Agenten folgt. Diese eine Wartezeit erhöht auch nicht die stündliche Zahl automatisierter Starts der Aufgabe: Der Fehler wegen des Rate-Limits wurde bereits gezählt. Eine weitere Ablehnung wegen der Broker-Wartezeit direkt danach oder eine nach einem anderen Fehler zählt für beide Grenzen.

Wenn der Agent nicht fertig wird

Scheitert ein Lauf und wiederholt ihn nichts mehr, weil die automatischen Wiederholungen aufgebraucht sind oder eine Wiederholung an der Ursache nichts ändern würde, sagt die Aufgabe das ganz oben: Der Agent konnte diese Aufgabe nicht fertigstellen, dazu, was schiefging und wer es beheben kann. Erneut ausführen startet den Agenten dort erneut, wenn du die Aufgabe ändern darfst.

Tale benachrichtigt außerdem die Person, die den Lauf gestartet hat, und alle, die die Aufgabe verfolgen: mit der Benachrichtigung Agenten-Lauf fehlgeschlagen und, wenn die Organisation ein verbundenes Postfach hat, per E-Mail. Benachrichtigt wird nur, wer das Projekt noch öffnen kann. Startet ein neuer Lauf auf der Aufgabe, gilt die ungelesene Benachrichtigung als gelesen. Unter Einstellungen > Benachrichtigungen schaltest du diese Hinweise mit Agenten-Eskalationen ab.

Arbeit, die eine Automatisierung oder ein anderer Agent startet

Ein Projektagent kann auch an die Arbeit gehen, ohne dass jemand auf Agent starten klickt: durch eine geplante Automatisierung oder durch einen anderen Agenten des Projekts, der das Tool Andere Agenten auf Aufgaben starten hat, etwa einen Manager-Agenten, der startbereite Arbeit verteilt und Fragen beantwortet. Die Zeitleiste führt einen solchen Lauf als Automatisierung, für Inhaber, Admins und Entwickler mit einem Link zum Automatisierungslauf, oder als delegiert, gestartet von dem Agenten, der ihn angefordert hat. Der Agent erfährt, wer ihn gestartet hat. Eine mitgegebene Nachricht liest er als Nachricht dieser Automatisierung oder dieses Agenten, nie als Prüfung durch eine Person: Widerspricht sie der Beschreibung oder dem Kommentar einer Person, haben diese Vorrang.

Der Lauf arbeitet im selben Auftrag wie der Lauf, der ihn angefordert hat: im Auftrag der Person, die jenen gestartet hat, oder bei einer Kette, die ein Zeitplan begonnen hat, in niemandes Auftrag; ihre Kosten zählen dann als Automatisierungskosten. Diese Person oder der Zeitplan muss beim Start des Laufs im Projekt handeln dürfen: Verliert die Person die Rolle Redakteur, wird der Zeitplan pausiert oder die Automatisierung aus dem Projekt entfernt, unterbleibt der nächste Start. Ein Agent, den ein anderer Agent gestartet hat, kann keine weiteren Agenten starten, und ein Lauf, den ein Mitglied gestartet hat, kann gar keine starten. Ein solcher Start prüft außerdem, was eine Person übersehen könnte: Eine Aufgabe, die von einer offenen Aufgabe blockiert wird, startet nicht, und ein Agent kann sich nicht selbst auf einer anderen Aufgabe starten (self_start). Ein Agent, der schon an anderen Aufgaben arbeitet, wird trotzdem gestartet, in einem eigenen Worker. Sind alle Agenten-Worker deiner Organisation belegt, wartet der Lauf, startet von selbst, sobald einer frei wird, und der Start antwortet started mit dem Grund, warum er wartet (waitingReason); Aufgabe lesen zeigt dasselbe, solange der Lauf wartet. Eine automatische Wiederholung eines solchen Laufs startet sofort, egal was ihr Agent sonst gerade tut.

Ein delegierter Lauf legt sein Ergebnis unter In Prüfung für den gespeicherten Reviewer ab. Wird die Arbeit an einer dort wartenden Aufgabe wieder aufgenommen, zieht das ihre offene Prüfanfrage zurück, ohne das Ergebnis anzunehmen. Ein Start, der die Karte stehen lässt (moveToInProgress: false), wird unter einer Karte, die auf ihre Prüfung wartet, und unter einer erledigten oder abgebrochenen Karte abgelehnt, damit frühere Arbeit nie zur Beurteilung steht, während darunter neue Arbeit läuft. Ein Manager, der die Frage eines Agenten beantwortet, setzt ihn fort und nennt dabei den fragenden Lauf und die Prüfung, auf die er wartet. Die Fortsetzung geschieht nur, solange das noch die offene Frage der Aufgabe ist. Wurde inzwischen entschieden (Erledigt, Abgebrochen oder eine andere Verschiebung), gibt es einen neueren Lauf oder eine neuere Prüfung oder wurde die Zuständigkeit geändert, antwortet der Agent mit stale_question; nichts wird zugewiesen, zurückgezogen, verschoben oder gestartet. Verlangt deine Organisation ein unabhängiges menschliches Review, darf die Person, in deren Auftrag der Lauf arbeitet, sein Ergebnis nicht annehmen.

Arbeit abbrechen oder pausieren

Mit Lauf abbrechen stoppst du den aktiven Agenten. Abbrechen kann den Lauf, wer die Aufgabe ändern darf, und auch die Person, die ihn gestartet hat, selbst wenn die Aufgabe inzwischen beim Agenten liegt. Auch das Verschieben einer laufenden Agentenaufgabe aus In Bearbeitung kann den Lauf abbrechen. Lies die Bestätigung vorher. Pro Aufgabe kann nur ein Agentenlauf aktiv sein.

Bei einer Aufgabe mit zuständiger Automatisierung stoppt das Verschieben den Lauf und legt die Aufgabe in einem Schritt dort ab, wohin du sie verschoben hast. Wird die Verschiebung abgelehnt, etwa weil du eine übergeordnete Aufgabe mit noch offenen Teilaufgaben nach Erledigt verschiebst, arbeitet der Lauf weiter, und die Aufgabe bleibt in In Bearbeitung. Lauf abbrechen im Bereich der Automatisierung auf der Aufgabe verschiebt sie nach Abgebrochen; offene Teilaufgaben verhindern das ebenso. Willst du den Lauf stoppen und die Aufgabe offen lassen, verschiebe sie stattdessen nach Zu erledigen.

Ein Admin kann die Aufgabenautomatisierung für die Organisation ausschalten. Neue Läufe starten dann nicht; bestehende Arbeit endet regulär. Organisationslimits und Budgets gelten weiterhin für jeden Lauf. Siehe Richtlinien und Limits.

Die passende Zuständigkeit wählen

Weise einer Person Arbeit zu, die menschliches Urteilsvermögen oder Zugriff außerhalb der Agentenrechte braucht. Nutze einen Projektagenten für eine klar begrenzte Aufgabe mit seinen konfigurierten Dateien und Tools. Eine Automatisierung passt zu festen Abläufen mit mehreren Schritten, Auslösern oder Connector-Freigaben. Mitglieder können nur eine für Aufgaben gebaute Automatisierung wählen, also einen der Einträge unter Automatisierungen bei Zuständig.

Für den ersten Lauf folge Deinen ersten Agenten erstellen. Halte die Aufgabe so klein, dass du ihr Ergebnis selbst prüfen kannst.