Why Your Multi-Agent Network Works in Demo but Falls Apart in the Wild

Au cours de l'année écoulée, la façon dont les gens construisent avec l'IA a changé de manière significative.

Au lieu de partir de l'architecture, des APIs et de la logique d'orchestration, on peut partir de l'intention. Tu décris ce que tu veux, tu raffines par itération, et un système fonctionnel commence à prendre forme. Cette bascule, qu'on appelle vibe coding, a rendu possible la mise en place de workflows agent-based en une fraction du temps qu'il fallait avant, et dans bien des cas sans s'engager d'emblée sur une structure rigide.

Ce n'est pas seulement plus rapide : cela change entièrement la façon dont les systèmes sont conçus. Des équipes l'utilisent pour prototyper des workflows logistiques, automatiser des processus internes, et explorer de nouvelles catégories d'applications sans se figer dans une structure rigide.

Ce que ça n'a pas fait, c'est supprimer la complexité qui vient avec le fait de faire tourner ces systèmes une fois qu'ils dépassent la phase de prototype initial. Au moment où ces réseaux d'agents commencent à interagir avec de vrais outils, de vraies données, et de vrais patterns d'usage, un set de contraintes différent commence à apparaître.

Le système fonctionne une fois. Puis il fonctionne à nouveau, légèrement différemment. Puis un nouvel edge case apparaît, un outil se comporte de manière inattendue, ou un agent route une tâche d'une manière qui n'avait jamais été prévue. Rien n'est manifestement cassé, mais le système n'est plus quelque chose que tu peux entièrement raisonner.

Ce que tu vois à ce moment-là n'est pas un bug — c'est la transition d'un agent vers un système d'exploitation pour agents.

Au Cognizant AI Lab, c'est le problème sur lequel nous avons concentré notre travail avec neuro-san, un framework open source (Apache 2.0) pour construire des systèmes multi-agents. L'objectif n'est pas seulement de rendre les réseaux d'agents faciles à créer, mais de les faire tenir une fois qu'ils commencent à interagir avec de vrais outils, de vraies données, et de vrais patterns d'usage.

Ce que nous avons trouvé, c'est que le même set de problèmes émerge à chaque fois que cette transition se produit. Ils ne sont pas liés à un cas d'usage ou à un modèle spécifique — ils sont structurels.

Une des raisons pour lesquelles le vibe coding paraît si efficace au début, c'est qu'il enlève le besoin de penser explicitement à l'orchestration. Tu décris une tâche, et le système génère un réseau d'agents avec des responsabilités définies, établit comment ils communiquent, et produit quelque chose qui se comporte assez cohéremment pour valider l'idée.

À cette échelle, la structure paraît intuitive parce qu'elle est encore assez petite pour être raisonnée directement. Tu peux suivre comment une requête traverse le système et comprendre pourquoi un résultat particulier a été produit.

Cette intuition ne tient plus à mesure que le système grandit.