Créer un workflow d’agents IA avec un superviseur

Un workflow d’agents IA organise la manière dont un travail passe d’un rôle à un autre. Il définit les entrées, les livrables, les décisions et les conditions de fin. Le superviseur suit ce travail et choisit la suite dans le cadre qui lui est confié.

Commencez par le résultat et ses critères. Ajoutez ensuite les rôles nécessaires pour le produire et le vérifier. Une équipe de huit agents n’est pas une amélioration si elle multiplie les échanges sans rendre le résultat plus utile.

Ce que superviseur et workflow apportent chacun

Le superviseur doit savoir ce qui peut commencer, ce qui manque et qui peut faire le travail. Il délègue les contributions, suit les dépendances et examine les résultats. Son mandat précise les décisions qu’il peut prendre et celles qui reviennent à une personne.

Le workflow décrit un circuit réutilisable : produire, vérifier, corriger, accepter. Une condition peut orienter le résultat vers une autre étape. Une boucle peut relancer une correction. Une validation peut suspendre le circuit jusqu’à une décision humaine.

Dans Stellary, la coordination de projet organise des cartes et des contributeurs dans un mandat. Les workflows décrivent des étapes et leurs sorties. Vous pouvez utiliser un workflow pour traiter une contribution à un projet coordonné.

Choisir les rôles à partir du travail

Ces rôles peuvent correspondre à des agents distincts, à plusieurs missions d’un même agent ou à une contribution humaine. La séparation est particulièrement utile lorsque l’indépendance de la revue change la confiance dans le résultat.

L’orchestration multi-agents documentée par Anthropic distingue également plusieurs formes de délégation. Leurs détails de fonctionnement sont propres au fournisseur ; pour Stellary, vérifiez les capacités du moteur et les outils réellement disponibles.

Écrire un contrat pour chaque passage de relais

Une bonne mission indique le résultat attendu, les sources, les actions autorisées, le périmètre à préserver et la preuve de fin. La mission suivante doit pouvoir utiliser le livrable sans relire une longue conversation.

Pour une exploration, demandez par exemple trois options comparables, leurs sources et les raisons de les écarter ou de les tester. Pour une implémentation, demandez un changement identifiable et les contrôles exécutés. Pour une revue, demandez les critères vérifiés et les écarts observés.

Évitez les consignes comme « aide l’autre agent » ou « améliore tout ». Elles laissent le rôle, l’accès et la fin de mission indéfinis. Un bon contrat réduit l’ambiguïté avant qu’un superviseur n’essaie de la résoudre pendant l’exécution.

Exemple de workflow de création

1. 01

   Cadrer

   Le pilote relie l’objectif, les critères et les sources à une carte.

2. 02

   Explorer

   Un agent examine les options et signale les inconnues qui changent le choix.

3. 03

   Créer

   L’exécutant produit le livrable dans son périmètre autorisé.

4. 04

   Vérifier

   Un autre intervenant inspecte le résultat et les critères.

5. 05

   Corriger ou accepter

   Les écarts confirmés repartent en correction ; une revue satisfaisante autorise la suite prévue.

L’exploration n’est pas obligatoire pour une tâche connue. L’optimisation ne précède pas une correction fonctionnelle. Le circuit doit pouvoir sauter une étape qui n’apporte rien à la mission, selon les conditions définies.

Dans l’exemple d’une application complète, la revue doit couvrir le parcours utilisateur et les données. Pour un rapport de projet, elle porte d’abord sur les faits, leurs sources et les décisions attendues.

Donner des critères au vérificateur et à l’arbitre

Un vérificateur ne doit pas simplement noter la qualité sur dix. Il doit ouvrir le livrable et rapprocher chaque critère d’un fait observable. Un score peut aider une condition de workflow, mais il ne remplace pas les éléments qui expliquent ce score.

L’arbitre compare ensuite des options selon les critères prévus. Pour une fonctionnalité, il peut comparer correction, coût d’intégration et maintien du contrat. Pour une recherche, il peut comparer qualité des sources, résultats et incertitudes.

Lorsqu’un compromis sort du mandat, la bonne sortie est une question précise. « Faut-il conserver cette fonctionnalité au prix d’un report ? » doit parvenir à la personne qui porte l’engagement. Le rôle d’arbitre ne crée pas une autorité générale sur les décisions du projet.

Organiser les boucles de correction

Une boucle utile transmet les écarts, leur contexte et la méthode de contrôle. Le correcteur doit savoir ce qui a échoué et ce qu’il peut modifier. Sans cela, il risque de refaire une grande partie du travail ou de corriger un symptôme différent.

Après plusieurs échecs similaires, changez quelque chose : stratégie, exécutant, données ou critère devenu incohérent. Répéter la même mission avec le même message ne constitue pas un progrès. Le pilotage Stellary prévoit un changement de stratégie ou une réaffectation après deux corrections infructueuses avec la même approche et le même exécutant.

Une question peut aussi suspendre la branche concernée. Les travaux indépendants peuvent continuer lorsque leurs prérequis sont satisfaits. C’est une différence importante entre une attente explicite et une boucle qui consomme des appels sans nouvelle information.

Faire travailler les agents en parallèle

Le parallélisme est utile lorsque les tâches peuvent avancer sans se modifier mutuellement. Deux explorateurs peuvent comparer des sources différentes. Deux développeurs qui modifient le même contrat doivent d’abord se mettre d’accord sur ce contrat.

Dans la coordination Stellary, les ressources d’écriture partagées peuvent être réservées et le travail sur un dépôt commun sérialisé. La bonne question n’est donc pas « combien d’agents lancer ? », mais « quelles contributions sont réellement indépendantes ? ».

Prévoyez un ordre d’intégration et une revue du résultat commun. Des contributions réussies séparément peuvent encore mal s’assembler. Le guide de coordination sans collisions approfondit ce point.

Choisir les modèles et les outils par mission

Une extraction courte et une investigation de code difficile n’ont pas le même besoin. La sélection de modèles actuelle fournit des candidats à évaluer. Le coût utile est celui du résultat accepté, en comptant les reprises et la revue.

Un modèle local peut être pertinent pour certaines étapes. Il faut vérifier sa capacité à utiliser les outils du moteur choisi. Un modèle qui produit un texte correct n’est pas automatiquement capable d’exécuter un circuit agentique sous les permissions prévues.

Tester le workflow avant de le réutiliser

Rejouez le cas nominal, un résultat incorrect, une source manquante et une question qui exige une réponse humaine. Vérifiez où le circuit s’arrête, ce qui est conservé et comment le travail reprend.

Gardez les livrables de chaque étape et une chronologie lisible. Vous devez pouvoir expliquer pourquoi le résultat a été accepté et quelle correction l’a rendu acceptable. Pour une recherche et développement, conservez aussi les pistes rejetées et les résultats négatifs.

Commencez avec un créateur et un vérificateur, puis ajoutez les rôles dont l’utilité apparaît dans les essais. Le workflow devient une méthode de travail réutilisable lorsque ses entrées, ses erreurs et sa fin sont compréhensibles par l’équipe.

Définir les entrées et sorties d’une condition

Si une condition décide d’une correction, précisez la donnée qu’elle lit. Une sortie structurée comme « critères satisfaits » doit être produite selon une consigne et accompagnée des preuves de revue. Un champ absent doit mener à une attente ou une erreur lisible, jamais à une acceptation implicite.

Les étapes Stellary peuvent exposer des variables typées utilisables par les conditions. Gardez un nom et une signification stables. Modifier cette signification sans revoir les branches peut orienter un résultat vers la mauvaise suite, même si chaque agent produit un texte plausible.

Conserver un responsable du résultat commun

Le superviseur doit pouvoir expliquer quel livrable représente l’ensemble. Plusieurs fichiers ou réponses ne composent pas toujours un résultat intégré. Pour un rapport, vérifiez la cohérence des faits ; pour une application, rejouez le parcours complet ; pour une recherche, reliez la décision aux expériences.

La revue finale doit porter sur cette version commune. Si une correction modifie un élément déjà vérifié, les critères concernés doivent être revus. L’historique des étapes aide à identifier ce qui reste valable sans refaire tous les contrôles indistinctement.

Mettre ce workflow en place dans Stellary

La page d’orchestration présente le cadre produit et le guide des agents les réglages à vérifier. Commencez avec une carte, un exécutant et un relecteur. Le premier passage est réussi quand le relecteur retrouve le livrable, rejoue le critère et peut demander une correction sans reconstruire tout le contexte.

Le scénario décrit ici reste une recette à adapter. Aucun gain de temps ni niveau d’autonomie n’est déduit de ce seul exemple.