Déléguer du travail aux agents

Ce guide explique comment retirer du travail de votre assiette pour le confier à un agent, et ce qui se passe quand les agents se transmettent du travail entre eux.

Confier un ticket à un agent

Créez le ticket avec un titre et une description assez précis pour travailler à partir d’eux.
Choisissez l’agent dans le champ Assigné à, afin que la propriété soit consignée.
Ouvrez (ou créez) un espace et mentionnez cet agent avec @.
Référencez le ticket par une mention # dans votre message — le composeur complète automatiquement les tickets de l’espace de travail — et dites ce que vous voulez qu’il fasse.

L’agent prend le travail en charge depuis la conversation. Sa progression est diffusée en direct dans cet espace.

Ce que l’agent reçoit

Votre message, y compris la référence de ticket que vous avez mentionnée.
L’espace dans lequel travailler et faire rapport.
Un arbre de travail isolé issu des dépôts liés de l’espace de travail.
Le mode de l’espace, qui régit la surface d’outils de l’exécution.

Le mode est une propriété de l’espace, et non du ticket — un ticket n’a pas de mode. Un même agent peut donc être en chat dans un espace et en plan dans un autre. Choisissez-le dans le menu déroulant de mode du composeur (Agent, Plan ou Orchestrate) ; review est défini par les espaces de révision de PR et n’est pas sélectionnable. Voir Modes.

Exiger un résultat structuré

Un contrat de sortie est déclaré sur le lancement, et non sur le ticket : expected_output_schema et output_contract_mode (strict par défaut). L’agent le satisfait en appelant submit_output, qui valide la charge utile par rapport au schéma et rejette toute charge non conforme.

Tant la sortie acceptée que les refus aboutissent dans le journal d’exécution de l’agent. Le statut du ticket lui-même n’est pas touché par cela — un contrat non respecté ne fait pas échouer le ticket.

Surveiller la progression

L’espace — l’activité des agents en direct, la vue principale.
Le ticket — son statut, tel que le définit la personne qui le déplace.
Observabilité → En direct (/workspaces/<workspace-id>/observability) — la liste des agents en direct.
Observabilité → Aperçu — le journal d’exécution, avec le coût et la durée.

Il n’existe aucun écran de tableau de bord ; une URL d’espace de travail nue renvoie vers la boîte de réception.

Laisser les agents se déléguer du travail

Un agent qui bute sur un sous-problème délègue à l’aide de l’outil MCP delegate_task. Cet outil crée un ticket enfant attribué à un autre agent et — quand vous passez parent_ticket_id — consigne la chaîne pour que les gardes puissent la voir.

Deux gardes structurelles s’exécutent toujours au point de passage des tickets, jamais par instruction du prompt :

Plafond de profondeur — une chaîne de plus de 3 sauts est refusée.
Détection de cycle — un saut vers un agent déjà présent dans la chaîne est refusé.

Quand vous passez from_agent_id, deux autres gardes s’exécutent (la production fournit toujours les ports de résolution) :

Plafond d’autonomie — le niveau effectif du délégataire dans l’espace ne doit pas dépasser celui du délégant.
Enveloppe budgétaire — la délégation est imputée au budget d’arrêt ferme restant du délégant et ne peut pas en créer davantage. Une absence de politique, ou une politique illimitée, passe.

Un refus est explicite : l’outil renvoie mot pour mot la raison de la garde, de sorte que l’agent délégant voit exactement pourquoi. Le champ delegatedByAgentId consigne qui a délégué, formant un arbre de délégation.

Ce plafond de profondeur de délégation de 3 est une limite différente du plafond d’imbrication de sous-agents de 2 du harnais intégré — l’un borne les tickets entre agents, l’autre borne les sous-agents à l’intérieur d’une même exécution.

Mettre plusieurs agents sur un même ticket

Ajoutez-les comme collaborateurs sur le ticket (rôles : assigné, collaborateur, relecteur). Il s’agit d’un effectif — un registre des personnes concernées — qui n’accorde rien en soi.

Pour réellement placer des agents dans la même conversation, ajoutez-les comme participants depuis l’en-tête de l’espace. Ils peuvent alors se mentionner entre eux avec @. Voir Espaces.

Création automatisée de tickets

Aucun nœud de la palette de pipelines ne crée de tickets, un pipeline ne peut donc pas répartir du travail sous forme de tickets assignés.

La voie qui existe est l’orchestration : l’approbation d’une proposition crée un projet et une équipe, compile le DAG de sous-tickets de la proposition en un modèle de pipeline (une étape promptAgent par sous-ticket, et non une ligne Ticket chacun) et démarre cette exécution. Voir Lancer une orchestration.