Les défaillances de boucle multi-agents sont des défaillances de conception organisationnelle, pas des défaillances d'instruction.

La plupart des configurations multi-agents finissent par rencontrer le même mur : des agents qui rebondissent entre eux, des relecteurs qui demandent une énième passe de polissage, des chercheurs qui génèrent des sous-sujets à l'infini, des appels d'outils qui s'emballent jusqu'à atteindre la limite de récursion. Les documentations des frameworks appellent cela des « boucles » et proposent un paramètre de maximum d'itérations. Une hypothèse qui gagne du terrain est que ce paramètre ne traite qu'un symptôme, et que le vrai problème réside dans l'organisation des agents.

Le schéma qui revient sans cesse : quand les agents sont conçus comme des pairs (le chercheur parle à l'analyste, l'analyste parle au rédacteur, le rédacteur repasse au relecteur), personne n'est clairement propriétaire du résultat. Chaque agent peut demander plus de travail à un autre agent. Le graphe a des conditions d'arrêt sur le papier, mais aucun agent n'a l'autorité de déclarer « c'est fini, arrêtez l'exécution ». Cette autorité est implicite et se dilue dans le réseau de pairs.

La solution est de traiter le réseau d'agents comme un organigramme avec des lignes hiérarchiques explicites, et non comme un salon de discussion de pairs. Couches proposées :

• Président (autorité de plus haut niveau, peut terminer)
• Bureau de la stratégie
• Directeur de division
• Chef d'équipe
• Travailleur spécialisé
• AQ et Politique en tant que bureaux d'état-major distincts qui peuvent rejeter et escalader mais ne peuvent pas générer de nouveau travail sans limite

Mécanismes clés :

• Un propriétaire de mission responsable par exécution
• Un propriétaire par flux de travail
• Profondeur de délégation finie
• Contrat de retour typé par travailleur : statut, preuve, résultat, blocages, action suivante
• Autorité du manager uniquement pour rouvrir ou terminer
• La mémoire réside dans les couches d'autorité ; les spécialistes reçoivent un contexte limité

Le mode de défaillance de récursion du relecteur est notamment éliminé lorsque les vérificateurs sont structurellement autorisés à un seul rejet, puis doivent escalader.

Les frameworks existants ont déjà les primitives :

• CrewAI — processus hiérarchique où un manager valide la sortie du travailleur
• LangGraph — superviseurs, sous-agents et limite de récursion explicite
• OpenAI Agents SDK — orchestration de type manager distincte des transferts entre pairs
• AutoGen — GroupChatManager
• Anthropic — système de recherche orchestrateur-travailleur

L'idée sous-utilisée : traiter le manager non pas comme un modérateur d'un chat de groupe ouvert, mais comme une ligne hiérarchique formelle avec autorité de terminaison.

Deux préoccupations ouvertes :

1. La hiérarchie peut devenir son propre goulot d'étranglement — si chaque décision remonte, le président devient un point unique de latence et de défaillance.
2. L'escalade en tant que fonctionnalité ne fonctionne que si le sommet a une réelle autorité d'arrêt. Si le président appelle simplement un autre LLM qui appelle d'autres LLMs, la boucle s'est juste déplacée d'un étage.

Dépôt avec les couches d'organigramme proposées : github.com/jeongmk522-netizen/agentlas_org_chart