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 est une étape de validation que l’exécutant applique à sa propre architecture avant de lancer le moindre agent. Nos tests montrent que cette 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 se déroule en parallèle. Quand un problème survient, il se manifeste rarement seul : un agent échoue, ce qui prive le consolidateur 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.

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 revue de code 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.

1. Nesting

Une sous-tâche est-elle elle-même susceptible de spawner 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 maximum. Au-delà, la complexité de coordination dépasse les bénéfices du parallélisme.

Nos tests ont identifié des cas où un agent, recevant un prompt ambigu sur sa propre portée, interprétait 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.

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 limites de débit de l’API utilisée ? 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 contrôle 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 intégré au processus.

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

Nos tests montrent que 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). Ces deux catégories 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.

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 en cas limites 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 revue de code avant merge — des points de vérification à coût fixe qui évitent des corrections à coût élevé.

Sources