Arbeit an Agenten delegieren

Diese Anleitung zeigt, wie du Arbeit an einen Agenten abgibst und was passiert, wenn Agenten Arbeit untereinander weitergeben.

Ein Ticket an einen Agenten übergeben

Lege das Ticket an mit einem Titel und einer Beschreibung, die präzise genug ist, um danach zu arbeiten.
Setze Zugewiesen an auf den Agenten, damit die Zuständigkeit festgehalten ist.
Öffne einen Bereich oder lege einen an, und erwähne diesen Agenten mit @.
Verweise in der Nachricht mit einer #-Erwähnung auf das Ticket — der Composer vervollständigt die Tickets des Arbeitsbereichs — und sag, was erledigt werden soll.

Der Agent nimmt die Arbeit aus der Unterhaltung auf. Sein Fortschritt läuft in diesen Bereich.

Was der Agent bekommt

Deine Nachricht, einschließlich der Ticket-Referenz, die du markiert hast.
Den Bereich, in dem er arbeitet und berichtet.
Einen isolierten Worktree aus den verknüpften Repos des Arbeitsbereichs.
Den Modus des Bereichs. Der bestimmt die Werkzeugfläche des Laufs.

Der Modus gehört zum Bereich, nicht zum Ticket — ein Ticket hat keinen Modus. Derselbe Agent kann deshalb in einem Bereich in chat sein und in einem anderen in plan. Du wählst ihn im Modus-Dropdown des Composers (Agent, Plan oder Orchestrate). review setzen PR-Review-Bereiche, und er ist nicht wählbar. Siehe Modi.

Ein strukturiertes Ergebnis verlangen

Ein Abschlussvertrag steht auf der Ausführung, nicht auf dem Ticket: expected_output_schema plus output_contract_mode (standardmäßig strict). Der Agent erfüllt ihn, indem er submit_output aufruft. Der Aufruf prüft die Nutzlast gegen das Schema und weist eine zurück, die nicht passt.

Angenommene Ausgabe und jede Ablehnung landen im Laufprotokoll des Agenten. Der eigene Status des Tickets bleibt davon unberührt — ein gescheiterter Vertrag lässt das Ticket nicht fehlschlagen.

Den Fortschritt verfolgen

Der Bereich — die Live-Aktivität des Agenten, die eigentliche Ansicht.
Das Ticket — sein Status, so wie ihn setzt, wer es verschiebt.
Observability → Live (/workspaces/<workspace-id>/observability) — die Live-Liste der Agenten.
Observability → Übersicht — das Laufprotokoll, mit Kosten und Dauer.

Es gibt keinen Dashboard-Bildschirm. Eine bloße Arbeitsbereichs-URL leitet zum Posteingang um.

Agenten aneinander delegieren lassen

Ein Agent, der auf ein Teilproblem stößt, delegiert mit dem MCP-Tool delegate_task. Es legt ein Unterticket an, das einem anderen Agenten zugewiesen ist, und hält — wenn du parent_ticket_id übergibst — die Kette fest, damit die Prüfungen sie sehen.

Zwei strukturelle Prüfungen laufen immer am Ticket-Engpass, nie als Anweisung im Prompt:

Tiefenobergrenze — eine Kette mit mehr als 3 Sprüngen wird abgelehnt.
Zykluserkennung — ein Sprung zurück zu einem Agenten, der schon in der Kette steht, wird abgelehnt.

Übergibst du from_agent_id, laufen zwei weitere Prüfungen (die Produktion stellt die Resolver-Ports immer bereit):

Autonomieobergrenze — die wirksame Stufe des Delegierten im Bereich darf die des Delegierenden nicht übersteigen.
Budgetrahmen — die Delegation bucht auf das verbleibende Budget des Delegierenden bis zum harten Stopp und kann kein weiteres erzeugen. Keine Richtlinie, oder eine unbegrenzte, geht durch.

Eine Ablehnung ist laut: Das Tool gibt den Grund der Prüfung wortgetreu zurück, der delegierende Agent sieht also genau, warum. Das Feld delegatedByAgentId hält fest, wer delegiert hat, und bildet einen Delegationsbaum.

Diese Tiefenobergrenze der Delegation von 3 ist eine andere Grenze als die Verschachtelungsobergrenze für Subagenten des eingebauten Harness von 2 — die eine begrenzt Tickets zwischen Agenten, die andere begrenzt Subagenten innerhalb eines einzelnen Laufs.

Mehrere Agenten auf ein Ticket setzen

Füge sie als Mitarbeiter am Ticket hinzu (Rollen: assignee, collaborator, reviewer). Das ist eine Besetzung — ein Nachweis, wer beteiligt ist — und gewährt für sich allein nichts.

Damit Agenten wirklich in derselben Unterhaltung sitzen, fügst du sie aus der Kopfzeile des Bereichs als Teilnehmer hinzu. Dort können sie einander mit @ erwähnen. Siehe Bereiche.

Tickets automatisch anlegen

Kein Knoten in der Pipeline-Palette legt Tickets an, eine Pipeline kann Arbeit also nicht als zugewiesene Tickets verteilen.

Der Weg, der existiert, ist die Orchestrierung: Die Freigabe eines Vorschlags legt ein Projekt und ein Team an, kompiliert den DAG der Untertickets aus dem Vorschlag in eine Pipeline-Vorlage (ein Schritt promptAgent je Unterticket, nicht je eine Zeile Ticket) und startet diesen Lauf. Siehe Eine Orchestrierung ausführen.