Déléguer du travail aux agents
Ce guide explique comment sortir du travail de votre assiette pour le confier à un agent, et ce qui se passe lorsque les agents se transmettent du travail entre eux.
Confier un ticket à un agent
Section intitulée « Confier un ticket à un agent »- Créez le ticket avec un titre et une description suffisamment précis pour travailler à partir d’eux.
- Renseignez son champ Assigné à avec l’agent, afin que la responsabilité 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 compositeur complète automatiquement les tickets de l’espace de travail — et indiquez ce que vous voulez obtenir.
L’agent prend le travail en charge depuis la conversation. Sa progression est diffusée dans cet espace.
Ce que reçoit l’agent
Section intitulée « Ce que reçoit l’agent »- Votre message, y compris la référence de ticket que vous avez indiquée.
- L’espace dans lequel travailler et rendre compte.
- Un arbre de travail isolé, issu des dépôts liés à 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, pas 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 des modes du compositeur
(Agent, Plan ou Orchestrate) ; review est défini par les espaces
de revue de PR et n’est pas sélectionnable.
Voir Modes.
Exiger un résultat structuré
Section intitulée « Exiger un résultat structuré »Un contrat de sortie est déclaré sur le lancement, pas sur le ticket :
expected_output_schema et output_contract_mode (strict par défaut). L’agent
le respecte en appelant submit_output, qui valide la charge utile par rapport
au schéma et rejette toute charge non conforme.
La sortie acceptée comme les éventuels rejets sont consignés dans le journal d’exécution de l’agent. Le statut du ticket lui-même n’en est pas affecté — un contrat non satisfait ne fait pas échouer le ticket.
Suivre la progression
Section intitulée « Suivre 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 fait avancer.
- Observabilité → En direct (
/workspaces/<workspace-id>/observability) — l’effectif 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 seule redirige vers la boîte de réception.
Laisser les agents se déléguer du travail entre eux
Section intitulée « Laisser les agents se déléguer du travail entre eux »Un agent qui bute sur un sous-problème délègue avec l’outil MCP delegate_task.
Celui-ci crée un ticket enfant assigné à un autre agent et — lorsque vous passez
parent_ticket_id — consigne la chaîne pour que les gardes puissent la voir.
Deux gardes structurels s’exécutent toujours au point de passage unique des tickets, jamais sur instruction de 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é.
Lorsque vous passez from_agent_id, deux gardes de plus s’exécutent (la
production fournit toujours les ports de résolution) :
- Plafond d’autonomie — le niveau effectif du délégué dans l’espace ne doit pas dépasser celui du délégant.
- Enveloppe budgétaire — la délégation est facturée au budget d’arrêt strict restant du délégant et ne peut pas en créer davantage. L’absence de politique, ou une politique illimitée, passe.
Un refus est explicite : l’outil renvoie la raison du garde mot pour mot, de
sorte que l’agent délégant comprend 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 des sous-agents de 2 du harnais intégré — l’un borne les tickets entre agents, l’autre borne les sous-agents au sein d’une même exécution.
Mettre plusieurs agents sur un même ticket
Section intitulée « 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 impliquées — qui n’accorde rien en soi.
Pour placer réellement des agents dans la même conversation, ajoutez-les comme participants depuis l’en-tête de l’espace. Ils peuvent alors se mentionner mutuellement avec @. Voir Espaces.
Création automatisée de tickets
Section intitulée « Création automatisée de tickets »Aucun nœud de la palette de pipeline ne crée de tickets : un pipeline ne peut donc pas répartir du travail sous forme de tickets assignés.
Le seul chemin qui existe est l’orchestration : approuver une proposition crée
un projet et une équipe, compile le DAG des sous-tickets de la proposition en un
modèle de pipeline (une étape promptAgent par sous-ticket, et non une
ligne Ticket chacune) et démarre cette exécution.
Voir Lancer une orchestration.
Guides connexes
Section intitulée « Guides connexes »- Créer et gérer des tickets
- Discuter avec un agent
- Lancer une orchestration
- Organiser le travail avec des projets
- Référence du cycle de vie des tickets