Construire des workflows multi-agents avec MadoHub

Faire fonctionner un seul agent IA est simple. Faire tourner cinq agents qui dépendent les uns des autres est là où les choses deviennent intéressantes — et là où la plupart des outils échouent.

Cet article explique comment construire un workflow multi-agent dans MadoHub, depuis la disposition des tiles jusqu'à la configuration des règles de routage.

Commencez par le résultat

Avant de placer le moindre tile sur le canevas, décidez de ce que doit être la sortie finale. Travailler à rebours depuis le résultat vous force à réfléchir aux étapes intermédiaires nécessaires.

Par exemple, supposons que vous vouliez générer un point de terminaison API testé et documenté. Le résultat final est une pull request contenant l'implémentation, les tests et la documentation. En remontant à rebours :

• Un agent PR composer assemble le résultat final
• Un agent test writer produit les fichiers de test
• Un agent docs writer génère la documentation API
• Un agent code generator écrit l'implémentation
• Un agent spec parser extrait les exigences à partir d'une description en langage naturel

Placer les tiles sur le canevas

Chaque agent reçoit un tile. Dans MadoHub, les tiles sont des environnements d'exécution indépendants — chacun fonctionne dans son propre contexte avec sa propre configuration de modèle et son propre prompt système.

Placez le spec parser à gauche du canevas et le PR composer à droite. Les agents intermédiaires se placent entre les deux, approximativement dans l'ordre d'exécution. Cette disposition de gauche à droite reflète la manière dont les données circulent dans le système.

Définir les connexions

Les connexions sont des arêtes orientées entre les tiles. Quand vous tracez une connexion de la sortie du spec parser vers l'entrée du code generator, vous dites à MadoHub d'injecter la spécification analysée dans le prompt de génération de code.

Un tile peut avoir plusieurs entrées. Le test writer peut recevoir à la fois la spécification analysée et le code généré, afin d'écrire des tests qui correspondent à la spécification et appellent l'implémentation réelle.

Stratégies de routage

Toutes les connexions ne doivent pas se déclencher dès que la sortie amont apparaît. Chaque connexion dans MadoHub possède un trigger :

• on-complete : se déclenche une fois que la session de l'agent amont est détectée comme terminée
• on-idle : se déclenche une fois que le terminal de l'agent amont devient inactif
• on-keyword : se déclenche quand un mot-clé configuré apparaît dans la sortie amont
• always : se déclenche à chaque nouveau fragment de sortie, sans qu'aucun signal de fin ne soit requis

Sous le capot, on-complete et on-idle sont traités de la même façon — les deux attendent une brève minuterie d'inactivité (environ 8 secondes) après leur signal déclencheur avant de router. Considérez-les comme la même pause, avec deux raisons différentes de la démarrer, plutôt que comme deux stratégies indépendantes.

Chaque connexion possède aussi un transform, qui détermine ce qui est réellement envoyé en aval : raw (les dernières lignes telles quelles), summary (un résumé généré par IA), full-output (une fenêtre récente plus large), prompt-wrap (votre propre modèle avec des variables comme {output} et {round}), ou ai-routing (un prompt généré par IA et sensible au contexte, qui nécessite une clé API configurée).

Pour notre workflow API, vous pourriez configurer la connexion du spec parser vers le code generator en on-complete avec un transform full-output, puis configurer les connexions du code generator vers le test writer et le docs writer en on-complete avec un transform raw — les deux agents aval démarrent dès que la session du code generator signale sa fin, en travaillant à partir de la même sortie récente.

Gérer les échecs

Les agents échouent. Les modèles hallucinent. Les sorties ne correspondent pas toujours aux attentes. Un workflow multi-agent robuste a besoin de garde-fous pour qu'une boucle routée ne tourne pas indéfiniment.

La protection contre les boucles de MadoHub fonctionne par rounds plutôt que par validation de sortie : chaque connexion routée a un plafond maxRounds (5 par défaut, configurable de 1 à 20) et un cooldown entre les rounds (3 secondes par défaut, configurable jusqu'à 30), afin qu'un agent aval ne puisse pas être redéclenché plus vite qu'il ne peut réalistement répondre. Vous pouvez aussi définir un stopKeyword — n'importe quelle sous-chaîne insensible à la casse, comme "LGTM" — et la boucle s'arrête dès que la sortie d'un agent le contient.

C'est exactement ainsi que fonctionne le flow intégré Peer review de MadoHub : un auteur Claude Code et un relecteur Codex sont reliés en boucle avec le stopKeyword réglé sur "LGTM" — le relecteur continue d'envoyer des retours jusqu'à ce qu'il le dise, et la boucle s'arrête là. Le flow intégré Pipeline est plus simple : un transfert en deux étapes où le full-output du premier agent alimente le second agent une fois terminé. Le flow intégré Watcher est piloté par mots-clés de bout en bout, utilisant le transform ai-routing pour transformer une phrase correspondante en prompt de suivi sensible au contexte.

L'itération est l'objectif

Le vrai avantage des workflows multi-agents sur canevas, c'est la vitesse d'itération. Ajouter un nouvel agent — par exemple un relecteur sécurité entre le code generator et le PR composer — prend quelques secondes. Vous placez un tile, tracez deux connexions, et le workflow se met à jour.

Essayez de faire cela dans un système de pipeline-as-code. Vous éditeriez des fichiers de configuration, relanceriez des processus et espéreriez que le schéma valide encore. Sur le canevas, la boucle de retour est immédiate.