Déléguer une tâche à un agent

Un agent de projet travaille sur une tâche et remet son résultat pour relecture. Assigne le travail, démarre l’exécution et garde les retours sur la tâche pour que l’agent et le relecteur partagent le même contexte. Il te faut le droit de modifier la tâche : un Éditeur ou un rôle supérieur l’a sur toutes les tâches du projet, un Membre sur celles qu’il a créées ou qui lui sont attribuées. Il faut aussi un fournisseur fonctionnel, un environnement d’agent compatible et de la capacité de sandbox.

Préparer et démarrer la tâche

1. Crée une tâche avec le résultat attendu, les critères de fin et les fichiers d’entrée.
2. Choisis un agent de projet sous Assigné à.
3. Si tu peux modifier le projet, choisis une personne ou un agent indépendant sous Relecteur, ou conserve le Choix par défaut du projet. Initialement, le projet attribue les relectures à la personne autorisée qui a créé la tâche ou le projet. Désigner un responsable et un relecteur explique ce choix, les permissions et les transferts en attente.
4. Clique sur Démarrer l'agent ou passe la tâche à En cours. Si tu assignes l’agent dès la création de la tâche, Créer et démarrer l'agent dans Créer une tâche le fait dans la même étape.

L’assignation seule ne démarre pas l’exécution. Une tâche déjà assignée peut rester dans Backlog tant que l’équipe n’a pas décidé de la lancer. Tant que personne n’a démarré l’agent, la tâche affiche à toute personne qui peut le démarrer Démarrer l'agent et la mention L’agent attend que tu le démarres. Une fois démarré, l’agent utilise la description, les commentaires et les fichiers d’entrée dans sa sandbox. La fiche d’exécution indique s’il attend ou travaille. Une exécution qu’un Membre démarre s’en tient à sa tâche et se passe des secrets de l’agent ; Exécutions démarrées par un Membre détaille ce qui change.

Les agents reçoivent la consigne de rédiger les mises à jour, les comptes rendus, les tâches associées et les questions dans la langue du titre et de la description de la tâche. Si ces éléments ne permettent pas de déterminer une langue, ils utilisent la langue par défaut de l’organisation pour les agents. Un identifiant, un trimestre ou un titre issu d’un modèle ne détermine pas cette langue. Changer la langue de ton interface ne change pas celle de la tâche ; tu peux demander explicitement à l’agent d’en changer.

Les commentaires de progression d’un workflow peuvent contenir des traductions pour chaque langue d’interface prise en charge. Le même commentaire enregistré s’affiche alors dans la langue choisie par chaque lecteur. Les commentaires sans traduction conservent leur texte d’origine.

Lire et accepter le résultat

L’agent publie son compte rendu dans un commentaire et joint les fichiers produits comme livrables. Il passe ensuite la tâche à En revue. Un relecteur humain reçoit une notification et, si l’envoi d’e-mails est configuré, un e-mail. Un agent relecteur lit la relecture en attente depuis sa propre tâche ; lui attribuer une relecture ne le démarre pas automatiquement.

Tale liste les fichiers livrés ou ignorés dans un commentaire système distinct, affiché dans la langue de ton interface. Ce commentaire signale aussi un compte rendu absent ou raccourci. Le compte rendu conserve ainsi la langue de la tâche.

Pour une relecture humaine, lis le compte rendu, ouvre les livrables et compare-les aux critères de fin. Passe la tâche à Terminé seulement lorsque tu acceptes le travail. Tale enregistre la décision ; l’agent qui a produit le résultat ne peut pas l’approuver lui-même.

Pour une relecture attribuée à une personne, Relecteur détermine la notification et la file de revue sans réserver la décision à cette personne. Les autres personnes qui peuvent modifier la tâche peuvent aussi accepter le résultat, sous réserve des règles de relecture indépendante et de compétences de l’organisation. Une relecture en attente attribuée à un agent doit être explicitement transférée à une personne autorisée avant une approbation humaine. Changer de relecteur ne réassigne pas le travail de réalisation ; Désigner un responsable et un relecteur donne les détails.

Modifier Relecteur pendant que la tâche attend En revue transfère la demande enregistrée. La notification de l’ancien relecteur humain disparaît des demandes non lues ; une nouvelle personne reçoit la demande, tandis qu’une relecture attribuée à un agent attend cet agent. Le Choix par défaut du projet utilise la sélection actuelle du projet. Une modification simultanée de la relecture ou du résultat fait refuser le transfert : relis l’état actualisé avant de réessayer.

Configurer un relecteur indépendant

1. Crée un agent de projet distinct pour les relectures. Sous Skills, connectors & outils, accorde-lui Trouver des tâches, Lire une tâche et Revoir les résultats des tâches d’autres agents. Cette dernière permission est désactivée au départ et n’est pas proposée aux nœuds agent des automatisations.
2. Choisis cet agent comme relecteur par défaut du projet, ou explicitement sous Relecteur sur une tâche. Pour une relecture déjà en attente, utilise le champ de la tâche pour la transférer ; changer le choix du projet ne suffit pas.
3. Donne au relecteur sa propre tâche et la consigne d’examiner uniquement les relectures qui lui sont attribuées. Démarre cette tâche directement ou par une planification existante. Ne démarre pas une nouvelle exécution de réalisation sur la tâche dont le résultat est examiné.
4. Demande au relecteur de lire la relecture actuelle, d’examiner le compte rendu et les livrables réels, puis d’enregistrer des résultats de vérification concrets et un retour. Sa décision doit porter sur la même exécution terminée et les mêmes éléments que ceux qu’il a lus ; un résultat modifié exige une nouvelle lecture et un nouvel examen.

Pour une relecture attribuée à un agent, task_get.reviewFiles liste les pièces jointes et les livrables par pages de 50. Pour continuer, passe reviewFiles.page.continueCursor comme reviewFileCursor. Avec task_review, operation: "stage_file", la valeur actuelle de expected: {approvalId, runId, evidenceRevision} et une fileId de cette liste, le relecteur peut copier un fichier disponible de 20 Mio au plus dans son espace de travail. Il doit ensuite ouvrir le chemin renvoyé et examiner le contenu : la copie seule ne prouve pas que le fichier a été relu.

Un unavailableReason explique pourquoi un fichier ne peut pas être copié : stockage non pris en charge, métadonnées absentes ou ambiguës, taille trop élevée ou lien avec un document protégé. Les règles d’accès aux documents continuent de s’appliquer. Si la source ou le relecteur change, il faut relire l’état actuel. Si les droits changent pendant le transfert, l’opération refuse de confirmer le succès. Des octets déjà transférés avec autorisation peuvent rester dans l’espace de travail, sans permettre une décision devenue obsolète.

L’approbation passe la tâche examinée à Terminé. Une demande de modifications enregistre le retour et passe la tâche à À faire, en conservant son assignation. Aucune décision ne démarre une autre exécution. Même une mention d’agent dans ce retour ne déclenche pas de travail : une personne autorisée, un coordinateur ou une planification doit démarrer la tentative suivante séparément. L’activité indique l’agent relecteur et sa décision.

Pour une demande de modifications enregistrée, le coordinateur appelle task_start_agent avec taskId et resumeFrom: {kind: "review_repair", approvalId, runId}. Ces identifiants désignent la revue refusée et l’exécution de réalisation qu’elle a examinée. Le serveur choisit l’agent de cette réalisation et inclut les commentaires enregistrés du relecteur ainsi que feedbackCommentId dans les consignes de correction. Un complément dans feedback doit tenir avec ce texte et son préfixe d’identification dans la limite existante de 10 000 unités de code UTF-16.

La correction ne démarre que si la tâche est encore À faire, confiée au même agent, avec la même réalisation terminée comme dernière exécution. Une revue plus récente ou une modification intermédiaire du statut, de l’assignation ou de l’archivage empêche le démarrage, même si la valeur précédente a ensuite été rétablie. La réponse stale_repair ne change rien : le coordinateur relit la tâche et abandonne l’intention dépassée. Il ne réessaie jamais sans cette vérification explicite. La correction suit le cycle normal et soumet une nouvelle revue à la fin ; moveToInProgress: false est refusé.

Si la réponse se perd, le même agent coordinateur peut répéter l’appel protégé depuis une exécution active et actuellement autorisée, y compris une occurrence ultérieure. replayed: true renvoie le runId et le repairReceipt d’origine, conserve la première exécution à l’origine de la demande et ne lance aucun nouveau travail. Le reçu confirme un démarrage passé, pas que l’exécution est toujours active. Le droit de déléguer et l’accès au projet sont revérifiés à chaque appel. Les limites de simultanéité et de trois démarrages automatisés par tâche sur une heure restent applicables aux nouveaux démarrages. Des échecs répétés sans changement doivent mener à une tâche d’investigation distincte plutôt qu’à des réessais sans limite.

Pour retrouver une décision après une réponse perdue lors d’une occurrence précédente du relecteur, lis task_get.reviewDecision. Ce champ contient le dernier reçu natif validé, ou null si une revue en attente, humaine ou liée à un workflow plus récente existe, ou si le reçu est indisponible. Compare les identifiants de revue et d’exécution à l’intention enregistrée, puis lis séparément l’état actuel de la tâche. Un reçu historique ne décrit pas sa colonne actuelle et null ne prouve pas qu’aucune décision n’a été enregistrée. La répétition immédiate et identique de task_review exige toujours la même exécution émettrice active.

Pour les deux décisions, le relecteur doit être différent de l’agent qui a effectivement produit le résultat. Il lui faut une exécution active avec des droits sur tout le projet et la permission de relecture toujours accordée ; une exécution démarrée par un Membre ne peut pas décider d’une relecture. Une politique d’indépendance humaine ou des justificatifs de compétences requis orientent les nouvelles relectures vers la chaîne humaine ; une relecture déjà attribuée à un agent exige un transfert explicite à une personne autorisée. Les approbations de workflows et les questions adressées à une personne conservent leurs décisions humaines. Avant une décision, lis pendingReview.agentReviewBlockedReason pour connaître un problème actuel de source, de permission, d’identité ou de politique. Si le travail concerne GitHub, le relecteur doit vérifier lui-même le commit cité et ses contrôles : Tale enregistre ses éléments, mais ne vérifie pas indépendamment l’état actuel de GitHub et ne fusionne pas de Pull Request avec cette décision.

Réattribuer une relecture enregistrée

Avec Réattribuer les relectures en attente des agents, un manager peut confier une relecture en attente à un autre agent admissible du même projet. Le destinataire doit déjà disposer de Revoir les résultats des tâches d’autres agents, de l’accès nécessaire au travail et être indépendant de l’agent qui l’a réalisé. Le manager ne peut pas se désigner lui-même ni convertir une relecture humaine ou liée à un workflow. L’agent qui a réalisé le travail ne peut pas en réattribuer la relecture. Cette permission est distincte de celle qui permet de rendre une décision et ne lance aucun travail.

Le manager lit task_get, reprend les identifiants complets de l’approbation, de l’exécution source et du relecteur enregistré ainsi que evidenceRevision, puis appelle task_delegate_review avec ces valeurs attendues, le reviewerAgentId complet du destinataire et un motif. Une modification de la source, des éléments examinés, des permissions ou de la politique bloque le transfert. L’attribution de la tâche, son état et les réglages des futurs relecteurs restent inchangés. Si une exécution est nécessaire, le démarrage normal se fait sur la propre tâche de relecture du destinataire, jamais sur la tâche d’implémentation examinée.

Si la réponse se perd, le manager lit task_get.reviewDelegation et le pendingReview actuel. Le reçu indique les identifiants de l’ancienne et de la nouvelle approbation, les deux relecteurs, la source, les éléments examinés, le manager, l’exécution émettrice, le motif et la date. Il décrit une opération passée et ne prouve ni que la relecture reste en attente ni qu’un relecteur a démarré. Une répétition identique exige la même exécution active et autorisée du manager, ainsi qu’une approbation suivante et des éléments inchangés. Une occurrence ultérieure rapproche le reçu de l’état actuel au lieu de répéter une ancienne intention.

Demander des modifications

Explique les changements attendus dans un commentaire et mentionne l’agent assigné avec @. Cette mention est une instruction : un agent actif peut la recevoir pendant son exécution, tandis qu’un agent inactif démarre une reprise de la conversation précédente. Le résultat revient à En revue.

Si tu as démarré une exécution, tes mentions continuent de la guider même après que la tâche est passée à l’agent, par exemple parce que ta mention lui a confié une tâche qui t’était attribuée. Quand l’environnement de l’agent redémarre pour prendre en compte un commentaire, comme le font tous les environnements sauf Claude Code, la suite de l’exécution revient à l’auteur du commentaire : elle compte dans ses limites, et ses appels de connectors se font en son nom.

Un commentaire sans mention conserve une note sans déclencher cette action. Le sélecteur de mentions indique si l’agent ne peut pas répondre, par exemple lorsque l’automatisation des tâches est désactivée ou suspendue, ou lorsque tu peux commenter la tâche sans pouvoir la modifier.

Pour une tâche pilotée par une automatisation, mentionne celle qui en est responsable pour demander une nouvelle exécution. Mentionner une autre automatisation ne lui transfère pas la tâche et ne la démarre pas. Automatisations présente les workflows qui coordonnent plusieurs étapes.

Une tâche ne peut avoir qu’une seule exécution en file d’attente, en cours ou en attente à la fois, quelle que soit l’automatisation qui l’a démarrée. Répéter une demande de démarrage tant qu’elle est active renvoie à l’exécution existante, même si elle nomme une autre automatisation. Une fois celle-ci terminée, un nouveau démarrage peut créer une autre exécution et répéter le travail. Vérifie donc l’exécution actuelle et ses effets avant une nouvelle tentative.

Confier la file de travail à un agent coordinateur

Un agent coordinateur est un agent de projet dont les instructions consistent à lire tout le tableau, à distribuer le travail prêt et à répondre aux questions de routine que laissent les autres agents, pour que les personnes ne voient que ce qui demande leur intervention. Il lit avec Trouver des tâches et Lire une tâche ; aucun de ces deux outils ne modifie quoi que ce soit.

Lire toute la file de travail par passages

Trouver des tâches renvoie au plus 50 tâches à la fois. Tant qu’une page indique isDone: false, son continueCursor, renvoyé comme cursor avec les mêmes arguments, donne la page suivante ; la dernière page indique isDone: true. Un curseur qui revient avec d’autres filtres, un autre ordre ou depuis l’exécution d’un autre projet est refusé, tout comme un curseur abîmé : il n’est jamais lu comme la première page. Un total n’apparaît que lorsqu’une seule page contient toutes les tâches correspondantes.

Pour parcourir toute une file de travail, utilise order: "created". Les tâches arrivent alors dans l’ordre de leur création, de la plus ancienne à la plus récente, et gardent leur place : un passage cite donc chaque tâche au plus une fois, dans l’état où elle se trouve quand sa page est lue. L’ordre par défaut regroupe les tâches par statut et garde, pour chacun, l’ordre de sa colonne : une tâche qui bouge pendant que le coordinateur tourne les pages peut alors manquer ou apparaître deux fois.

Chaque tâche listée contient pendingReview: null ou les valeurs enregistrées approvalId, runId de réalisation et reviewer typé. Un relecteur trouve sa file avec status: "in_review" et son identifiant d’agent dans reviewerAgentId. Ce filtre porte sur le destinataire enregistré de la relecture, pas sur l’agent chargé de la réalisation ni sur le choix actuel du projet. Conserve ce filtre à chaque requête avec curseur. Le coordinateur parcourt aussi toutes les tâches in_review pour repérer les relectures d’agents supprimés, puis lit task_get.pendingReview.agentReviewBlockedReason pour déterminer la correction nécessaire. Les relectures d’agents restent dans cette file de tâches ; la file personnelle de l’accueil concerne les demandes humaines.

Un passage peut durer plus longtemps qu’une exécution. Avant la fin de son exécution, le coordinateur note un point de reprise dans un commentaire sur sa propre tâche : le passage, son ordre et ses filtres, le continueCursor suivant et la dernière tâche examinée. Son exécution suivante retrouve ce commentaire avec Lire une tâche et reprend à partir de là. Quand un passage se termine, ou que son curseur est refusé, le passage suivant commence à la première page. Une lecture qui échoue n’est pas une file vide : le coordinateur la signale et s’arrête.

Distinguer le travail en cours, terminé ou en attente

Lire une tâche désigne les sous-tâches, les tâches bloquantes et les commentaires par leurs identifiants, et remonte vers les commentaires plus anciens avec commentCursor. Il liste aussi les exécutions des agents de projet sur la tâche, de la plus récente à la plus ancienne, chacune avec les 500 premiers caractères du message transmis à son démarrage, ainsi que l’exécution d’automatisation de la tâche et une éventuelle demande de revue en cours :

• Une exécution avec live: true est en file d’attente ou en cours, et rien d’autre ne démarre sur la tâche avant qu’elle se termine.
• Une exécution achevée, en échec ou annulée est terminée ; settledAt en indique le moment.
• retryPending: true signifie qu’une nouvelle tentative automatique reste prévue pour la dernière exécution en échec et que son quota de tentatives le permet. Laisse Tale s’en charger. false signifie qu’aucune tentative n’est en attente pour cette exécution ; si le champ manque sur une ancienne plateforme, cet état est inconnu. Il ne donne ni l’heure de réinitialisation du fournisseur ni l’autorisation de relancer : relis d’abord la tâche, son responsable, ses exécutions et sa revue, puis respecte l’attente du fournisseur et tout retryAfter renvoyé lors d’un refus de démarrage.
• Un workflowRun qui attend une question (ask) ou une approbation (approval) attend une personne. Une pendingReview désigne son relecteur humain ou agent ; le coordinateur lui laisse la décision, sauf s’il est lui-même le relecteur indépendant désigné et dispose de la permission requise.

La réponse ne contient ni transcriptions, ni textes d’erreur, ni résultats, et rien qui vienne d’un autre projet.

Répondre à une question de routine

Une question de routine est une question à laquelle le coordinateur peut répondre à partir de ce que le projet consigne déjà. Écris le même protocole dans les instructions des agents qui travaillent et dans celles du coordinateur :

1. L’agent qui travaille pose la question dans un commentaire de la tâche, avec une clé de question stable, ses éléments de preuve et la question. Il indique dans son résultat l’identifiant du commentaire et celui de son exécution (Lire une tâche montre cette exécution comme l’exécution active de sa tâche), puis termine son exécution au lieu d’attendre à l’intérieur. Mentionner le coordinateur dans ce commentaire ne démarre rien : le commentaire d’un agent ne démarre jamais un agent.
2. Lors de son passage suivant, le coordinateur ne répond que tant que la tâche attend encore cette question : l’exécution qui l’a posée est la plus récente de la tâche et elle est terminée, aucune exécution n’est active sur la tâche, et la tâche attend la revue de cette exécution-là (pendingReview.runId). De cette lecture, il retient l’identifiant de l’exécution et pendingReview.approvalId. Si quelqu’un a entre-temps fait avancer la tâche, en acceptant le résultat, en annulant la tâche ou en demandant des modifications, la question n’est plus au coordinateur : il la signale au lieu d’y répondre.
3. Il publie sa réponse dans un commentaire qui cite l’identifiant du commentaire de la question ; la réponse reste sur la tâche quoi qu’il arrive ensuite. Il relance ensuite l’agent avec Lancer d'autres agents sur des tâches, en passant resumeFrom: {runId, approvalId} avec les deux identifiants qu’il a retenus, et un message qui commence par la clé de la question, l’identifiant de l’exécution et l’identifiant du commentaire de réponse : une lecture ultérieure avec Lire une tâche ne montre que les 500 premiers caractères du message d’un démarrage. Au moment où il a lieu, le démarrage vérifie que c’est encore la question ouverte de la tâche. Ce n’est qu’alors qu’il retire la demande de revue en cours, sans valider le résultat, et relance l’agent.
4. Si le démarrage répond stale_question, la question a été dépassée entre la lecture du coordinateur et le démarrage : une décision a été prise, il existe une exécution ou une revue plus récente, ou l’assignation a changé. Rien n’a été modifié. Le coordinateur relit la tâche et abandonne la question devenue caduque. Il ne relance pas, et jamais sans resumeFrom.
5. Si la réponse au démarrage se perd, le coordinateur relit la tâche avant de tenter quoi que ce soit d’autre : une exécution plus récente dont le message commence par cette clé de question, cet identifiant d’exécution et cet identifiant de commentaire de réponse signifie que le démarrage a abouti. Si le même démarrage est renvoyé, il répond stale_question et ne change rien.

Une question venant d’une tâche permanente, qu’une planification démarre avec moveToInProgress: false, n’attend aucune revue. Le coordinateur y publie seulement sa réponse, et l’exécution de l’occurrence suivante de la planification la lit. Ni le coordinateur ni personne d’autre ne démarre la tâche plus tôt pour transmettre la réponse.

Les questions d’une automatisation et les approbations de workflows restent l’affaire des personnes. Un coordinateur peut décider d’une relecture de travail d’agent uniquement par le parcours indépendant décrit plus haut, quand elle lui est attribuée. Lire ou reprendre une tâche n’approuve pas son résultat.

Traiter une attente ou un échec

Un échec récupérable donne lieu à jusqu’à trois nouvelles tentatives après la tentative initiale, qui démarrent aussitôt sauf dans les cas décrits plus bas. Une exécution qui progresse pendant au moins quinze minutes reçoit une nouvelle réserve de tentatives. Cela aide le travail long à reprendre après une interruption, sans prouver que le résultat est correct.

Si Codex termine une exécution parce que le modèle choisi est saturé, Tale programme la nouvelle tentative automatique une minute plus tard. La tentative échouée compte toujours pour la limite habituelle des relances et, pour les démarrages automatisés, pour la limite horaire. Tale garde le compte précédent parmi les comptes admissibles, sans changer de modèle ni mettre les autres agents en pause. Cette attente ne garantit pas que le modèle sera disponible. Si l’une de ces limites refuse la suite, la tâche peut rester En cours avec une exécution en échec : cette colonne seule ne signifie pas qu’un agent travaille encore.

Quand un agent ne répond plus, c’est-à-dire qu’il n’affiche rien et ne fait presque rien pendant 45 minutes par défaut, sa sandbox l’arrête et l’exécution échoue sans nouvelle tentative automatique : une relance s’arrêterait très probablement de la même façon. L’avis indique que l’agent ne répondait plus, et Voir, sur l’exécution dans l’historique de la tâche, montre ce qu’il a affiché en dernier.

Une nouvelle tentative automatique poursuit le travail de la personne qui a démarré l’exécution : elle ne démarre donc que là où cette personne pourrait la lancer maintenant. Le projet doit encore être actif, et cette personne doit toujours avoir le droit de modifier la tâche. Si un administrateur archive le projet, ou si cette personne quitte l’organisation ou perd le droit de modifier la tâche, aucune nouvelle tentative ne démarre et l’exécution reste en échec. Il en va de même pour une mention qui n’atteint l’agent qu’après la fin de son exécution. Une fois le projet restauré, toute personne qui peut modifier la tâche peut utiliser Relancer.

Avant qu’une nouvelle exécution commence à travailler, une brève panne de connexion au courtier d’abonnement peut être surmontée au sein de cette même exécution. Si celle-ci dispose de tous les droits de l’agent, Tale effectue au plus trois requêtes GET, espacées d’au moins cinq puis dix secondes, avec un budget commun de 60 secondes pour les requêtes et l’acceptation du résultat. Pour cet accès au courtier, Tale respecte au moins l’attente demandée ou s’arrête si elle dépasse le budget restant. Cette attente n’est pas reportée sur une exécution ultérieure ; les règles de relance et la limite horaire des démarrages continuent de s’appliquer. Les vérifications en base de données et DNS, ainsi que la fermeture des connexions, peuvent retarder le refus final. Ces requêtes n’ajoutent ni démarrage de tâche ni tentative automatique. Tale vérifie à nouveau l’exécution et l’identifiant avant chaque nouvelle requête et avant de renvoyer un jeton. Les exécutions limitées des Membres, les courtiers POST, les identifiants refusés et les comptes en période d’attente conservent leur fonctionnement actuel.

Un agent servi par un courtier d’abonnement peut perdre son jeton en cours de travail, lorsque le courtier actualise le compte. La nouvelle tentative poursuit alors la conversation avec un nouveau jeton, sans faire avancer le compteur de tentatives : elle affiche le même compteur que l’exécution qu’elle remplace, ou Reprise après l'actualisation du jeton si celle-ci n’en affichait aucun ou avait travaillé au moins quinze minutes, ce qui lui a valu une nouvelle réserve de tentatives. Après deux interruptions de ce type d’affilée, une nouvelle interruption compte comme n’importe quel autre échec.

Une exécution peut aussi ne pas démarrer du tout, parce que tous les comptes de son courtier d’abonnement sont en pause après avoir atteint une limite de requêtes. Sa nouvelle tentative est alors mise en file d’attente aussitôt, mais ne démarre que lorsque le premier compte redevient disponible, au plus tard une minute après. Cette attente ne consomme aucune tentative si l’exécution refusée suit immédiatement un échec HTTP 429 du même agent. Cette seule attente n’ajoute pas non plus de démarrage au compteur horaire des démarrages automatisés de la tâche : l’échec dû à la limite de requêtes a déjà été compté. Un refus consécutif pour la même attente, ou un refus après un autre échec, compte pour les deux limites.

Quand l’agent ne peut pas terminer

Quand une exécution échoue et que plus rien ne la relance, parce que ses nouvelles tentatives automatiques sont épuisées ou qu’une nouvelle tentative ne changerait rien à la cause, la tâche l’indique tout en haut : L’agent n’a pas pu terminer cette tâche, avec ce qui s’est passé et qui peut y remédier. Relancer, à cet endroit, redémarre l’agent pour toute personne qui peut modifier la tâche.

Tale prévient aussi la personne qui a démarré l’exécution et toutes celles qui suivent la tâche : par la notification Échec de l’exécution de l’agent et, si l’organisation dispose d’une boîte mail connectée, par e-mail. Seules les personnes qui peuvent encore ouvrir le projet sont prévenues. Une nouvelle exécution démarrée sur la tâche marque la notification non lue comme lue. Tu peux désactiver ces avis avec Escalades d'agent dans Paramètres > Notifications.

Travail lancé par une automatisation ou un autre agent

Un agent de projet peut aussi être mis au travail sans que personne ait à cliquer sur Démarrer l'agent : par une automatisation planifiée, ou par un autre agent du projet qui dispose de l’outil Lancer d'autres agents sur des tâches, comme un agent coordinateur qui distribue le travail prêt et répond aux questions. La chronologie affiche une telle exécution comme automatisation, avec, pour les propriétaires, les admins et les développeurs, un lien vers l’exécution de l’automatisation, ou comme délégué, lancée par l’agent qui l’a demandée. L’agent apprend qui l’a démarré, et il lit un message transmis par cette automatisation ou cet agent comme venant d’eux, jamais comme la revue d’une personne : là où ce message contredit la description ou le commentaire d’une personne, ce sont ces derniers qui l’emportent.

L’exécution agit pour le compte de la même personne que l’exécution qui l’a demandée : la personne qui a démarré cette exécution, ou personne si la chaîne a commencé par une planification, auquel cas ses dépenses comptent comme des dépenses d’automatisation. Cette personne, ou la planification, doit pouvoir agir dans le projet au moment où l’exécution démarre : si la personne perd le rôle Éditeur, si la planification est suspendue ou si l’automatisation est retirée du projet, le démarrage suivant n’a pas lieu. Un agent lancé par un autre agent ne peut pas lancer d’autres agents, et une exécution démarrée par un Membre ne peut en lancer aucun. Un tel démarrage vérifie aussi ce qu’une personne pourrait oublier : une tâche bloquée par une tâche ouverte ne démarre pas, et un agent ne peut pas se lancer lui-même sur une autre tâche (self_start). Un agent qui travaille déjà sur d’autres tâches est tout de même lancé, dans un worker distinct. Quand tous les workers d’agent de ton organisation sont occupés, l’exécution attend, démarre d’elle-même dès qu’un worker se libère, et le démarrage répond started avec la raison de l’attente (waitingReason) ; Lire une tâche montre la même chose tant que l’exécution attend. Une nouvelle tentative automatique d’une telle exécution démarre aussitôt, quoi que fasse son agent par ailleurs.

Une exécution déléguée dépose son résultat à En revue pour le relecteur enregistré. Reprendre une tâche qui y attend retire sa demande de revue en cours, sans valider le résultat. Un démarrage qui laisse la carte en place (moveToInProgress: false) est refusé sous une carte en attente de revue, ou sous une carte Terminé ou Annulé, afin qu’un travail antérieur ne soit jamais présenté au jugement pendant qu’un nouveau travail s’exécute dessous. Un coordinateur qui répond à la question d’un agent le relance en nommant l’exécution qui a posé la question et la revue qu’elle attend. La reprise n’a lieu que tant que c’est encore la question ouverte de la tâche. Si une décision a été prise entre-temps (Terminé, Annulé ou un autre déplacement), s’il existe une exécution ou une revue plus récente, ou si l’assignation a changé, l’agent répond stale_question et rien n’est assigné, retiré, déplacé ni démarré. Si ton organisation exige une relecture humaine indépendante, la personne pour le compte de laquelle l’exécution agit ne peut pas en accepter le résultat.

Annuler ou suspendre le travail

Utilise Annuler l'exécution pour arrêter l’agent actif. Toute personne qui peut modifier la tâche peut annuler son exécution, tout comme la personne qui a démarré celle-ci, même si la tâche est passée depuis à l’agent. Déplacer une tâche d’agent hors de En cours peut aussi annuler son exécution : lis la confirmation avant de continuer. Une tâche ne peut pas avoir deux exécutions d’agent actives en même temps.

Pour une tâche pilotée par une automatisation, le déplacement arrête l’exécution et place la tâche là où tu l’as déplacée, en une seule étape. Si ce déplacement est refusé, par exemple parce que tu passes à Terminé une tâche parente dont des sous-tâches restent ouvertes, l’exécution continue et la tâche reste dans En cours. Annuler l'exécution, dans le panneau de l’automatisation sur la tâche, passe la tâche à Annulé : les mêmes sous-tâches ouvertes l’en empêchent donc. Pour arrêter l’exécution tout en gardant la tâche ouverte, déplace-la plutôt vers À faire.

Un admin peut désactiver l’automatisation des tâches pour l’organisation. Cela bloque les nouveaux démarrages pendant que le travail déjà lancé se termine. Les limites et budgets de l’organisation s’appliquent toujours ; consulte Politiques et limites.

Choisir le bon responsable

Assigne une personne lorsque le travail demande un jugement humain ou un accès hors des droits de l’agent. Choisis un agent de projet pour une tâche délimitée utilisant ses fichiers et outils configurés. Une automatisation convient à un processus défini avec des étapes, des déclencheurs ou des approbations pour les opérations des connectors. Un Membre ne peut choisir qu’une automatisation conçue pour les tâches, c’est-à-dire l’une de celles listées sous Automatisations dans Assigné à.

Pour commencer, suis Créer ton premier agent. Choisis une tâche assez petite pour en vérifier toi-même le résultat.