En bref

Dispatcher des agents sans vérifier la cohérence de la décomposition expose à des erreurs difficiles à diagnostiquer après coup : conflits d’écriture sur un fichier partagé, boucles d’appels imbriqués, outputs manquants parce que les fichiers sources n’existaient pas. Le Step 0bis (point de contrôle n°0bis, auto-critique pré-dispatch) est une étape de validation que l’orchestrateur (agent principal qui décompose une tâche et pilote les sous-agents) applique à sa propre architecture avant de lancer le moindre agent. Ce type de vérification détecte des conflits structurels invisibles à la lecture du plan initial.

Le problème : des erreurs en cascade difficiles à isoler

Une orchestration multi-agents (déploiement coordonné de plusieurs agents LLM en parallèle, souvent appelé « Pieuvre » — un orchestrateur + N sous-agents + 1 consolidateur) se déroule en parallèle. Quand un problème survient, il se manifeste rarement seul : un agent échoue, ce qui prive le consolidateur (agent final chargé d’agréger les outputs des sous-agents) d’un input, ce qui produit une synthèse incomplète, ce qui invalide une décision en aval. La source initiale — une hypothèse incorrecte dans le plan de départ — est enfouie sous plusieurs couches d’effets secondaires.

En clair : quand un plan d’orchestration a un défaut de conception, on ne le voit pas au moment du lancement. On le voit 5 à 10 minutes plus tard, après avoir dépensé [ordre de grandeur estimé : $0.50 à $5 selon les modèles] dans une série d’appels LLM qui produisent un résultat inutilisable, sans savoir lequel des agents a failli.

Ce comportement en cascade n’est pas propre aux agents LLM. En aviation, les listes de contrôle pré-décollage existent précisément parce qu’une vérification omise au sol peut provoquer un enchaînement d’incidents en vol dont la cause devient difficile à remonter. En développement logiciel, la code review avant merge joue le même rôle : détecter les incohérences avant qu’elles n’entrent en production et contaminent d’autres parties du système.

Le Step 0bis transpose cette logique à l’orchestration d’agents : vérifier la cohérence de l’architecture avant de la déployer, pendant qu’il est encore possible de la corriger à coût nul.

Quatre points de contrôle

La vérification porte sur quatre dimensions indépendantes. Chacune correspond à une classe d’erreur distincte. La checklist complète tient en 4 questions fermées — on passe ou on ne passe pas.

En clair : 4 questions, 4 oui/non. Si un seul « non » → on reprend le plan avant de dispatcher. Temps total d’exécution : moins d’une minute pour un orchestrateur habitué.

1. Nesting

Une sous-tâche est-elle elle-même susceptible de spawner (créer dynamiquement) des agents supplémentaires ? Si oui, l’architecture devient récursive et les niveaux d’imbrication se multiplient. La règle pratique : un niveau de nesting (imbrication d’agents dans d’autres agents) maximum. Au-delà, la complexité de coordination dépasse les bénéfices du parallélisme.

On observe régulièrement des cas où un agent, recevant un prompt ambigu sur sa propre portée, interprète sa tâche comme nécessitant elle-même une décomposition en sous-agents. Restructurer la décomposition initiale — en précisant la portée de chaque agent — résout le problème avant le dispatch (lancement coordonné des agents).

2. Dépendances cachées

Deux agents écrivent-ils dans le même fichier ? L’output de l’agent A est-il utilisé comme input par l’agent B ? Les dépendances cachées transforment des tâches supposément indépendantes en tâches séquentielles masquées — incompatibles avec le parallélisme.

Ce point de contrôle oblige à tracer explicitement les flux de données entre agents. Si une dépendance existe, deux options : restructurer la décomposition pour l’éliminer, ou sérialiser les agents concernés plutôt que de les lancer en parallèle.

3. Parallélisme faisable

Le nombre d’agents planifiés est-il compatible avec les contraintes de rate limits (quotas de requêtes par minute imposés par l’API) du tier API utilisé ? Lancer 20 agents simultanément sur un tier qui tolère 5 requêtes concurrentes produit des timeouts, pas du parallélisme.

Ce contrôle est souvent omis parce que la planification se fait en termes logiques (N tâches indépendantes), pas en termes de ressources. La vérification force à réconcilier les deux perspectives.

4. Fichiers requis

Tous les fichiers référencés dans les prompts des agents existent-ils réellement au moment du dispatch ? Un agent qui démarre sur une référence inexistante échoue immédiatement, sans possibilité de récupération.

Un simple ls ou une vérification d’existence avant dispatch suffit. L’erreur est triviale à détecter au moment de la planification, et coûteuse à diagnostiquer après le fait.

Auto-critique, pas audit externe

La distinction conceptuelle importante : le Step 0bis est appliqué par l’exécutant lui-même, sur sa propre planification, avant l’exécution. Ce n’est pas une revue externe. C’est un mécanisme d’auto-critique (remise en question par l’agent de son propre plan, sans intervention humaine ni agent tiers) intégré au processus.

En clair : le même orchestrateur qui a conçu le plan vérifie le plan. Pas de deuxième modèle, pas de validateur humain à ce stade — juste une passe de relecture structurée sur 4 critères précis.

Cela implique que l’exécutant peut, et doit, remettre en question la décomposition qu’il a lui-même construite. Dans la pratique, cette posture produit des signalements que la planification initiale n’aurait pas générés : “ce plan a l’air cohérent, mais ce point précis pose problème pour telle raison concrète”.

En pratique, les problèmes détectés sont majoritairement des conflits de nommage (plusieurs agents ciblant le même chemin de fichier avec des noms légèrement différents) et des boucles de nesting (un agent dont le prompt implique implicitement une sous-orchestration). Sur nos observations empiriques en R&D, ces deux catégories représentent la majorité [ordre de grandeur estimé : ~70 %] des tensions détectées au Step 0bis. Elles passent systématiquement inaperçues à la lecture du plan initial.

Limites

Le Step 0bis ne détecte que des problèmes structurels visibles avant exécution. Il ne protège pas contre les erreurs de contenu — un agent qui produit un output mal formaté, factuellement incorrect, ou incomplet par manque de contexte. Ces erreurs ne sont détectables qu’à l’examen des résultats.

En clair : le Step 0bis attrape les bugs de plomberie (qui écrit où, qui dépend de qui, les fichiers existent-ils). Il n’attrape pas les bugs de contenu (réponses fausses, hallucinations). Pour ceux-là, il faut relire les outputs — et idéalement croiser plusieurs agents indépendants.

La vérification est également bornée par ce que l’exécutant peut anticiper. Des contraintes système non documentées (quotas silencieux, limites de taille de fichier, comportements edge case — cas limites non prévus — de l’API) échappent au contrôle. Le Step 0bis réduit les risques prévisibles, pas les risques inconnus.

Enfin, la qualité de la vérification dépend de la précision de la décomposition initiale. Une décomposition vague produit une vérification vague. Si les périmètres des agents sont flous, les dépendances cachées le restent.

Ce qu’il faut retenir

  • Le Step 0bis est une étape de vérification auto-critique appliquée avant tout dispatch, portant sur quatre points : nesting, dépendances cachées, parallélisme faisable, fichiers requis.
  • Son objectif est de détecter les incohérences structurelles avant qu’elles ne se propagent en cascade dans une orchestration en cours d’exécution.
  • Les erreurs les plus fréquemment détectées sont les conflits de nommage et les boucles de nesting implicites — deux catégories invisibles à la lecture du plan.
  • Le mécanisme ne protège pas contre les erreurs de contenu ni contre les contraintes système non documentées.
  • L’analogie pertinente : la liste de contrôle pré-décollage en aviation ou la code review avant merge — des points de vérification à coût fixe qui évitent des corrections à coût élevé.

Signaux skill

  • Longueur : 96 lignes, légèrement sous le seuil bas de la fourchette concept (100-180). L’article est dense ; les 4 lignes manquantes ne correspondraient qu’à du remplissage. Le skill ne prévoit pas de règle explicite pour les cas où la densité justifie de rester sous le seuil — à clarifier dans les guidelines.