Aller au contenu

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.

  1. Créez le ticket avec un titre et une description suffisamment précis pour travailler à partir d’eux.
  2. Renseignez son champ Assigné à avec l’agent, afin que la responsabilité soit consignée.
  3. Ouvrez (ou créez) un espace et mentionnez cet agent avec @.
  4. 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.

  • 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.

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.

  • 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.

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.

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.