Multi-agent

Quand un cabinet d'avocats prépare un dossier complexe, une seule personne ne fait pas tout. Quelqu'un recherche les textes applicables, quelqu'un d'autre épluche la jurisprudence, un troisième analyse le cas, et un associé rédige la synthèse finale. Chacun son métier.

L'idée du multi-agent, c'est de reproduire cette organisation avec des IA. Sur notre dossier juridique, on aurait un agent de recherche de textes, un agent de jurisprudence, un agent d'analyse et un agent de synthèse. Chacun avec ses propres instructions, ses propres outils, et parfois même son propre modèle : un modèle rapide et bon marché pour trier, un modèle plus puissant pour raisonner. Un agent orchestrateur distribue le travail et assemble les résultats.

Sur le papier, c'est séduisant. Chaque agent a une consigne courte et précise au lieu d'un prompt à rallonge qui essaie de tout couvrir. On peut tester, améliorer ou remplacer chaque agent séparément. Et quand les tâches sont indépendantes, comme chercher les textes et la jurisprudence, elles peuvent tourner en parallèle.

Mais (il y a toujours un mais) plus d'agents ne veut pas automatiquement dire meilleur résultat. Chaque agent supplémentaire ajoute des appels au modèle, donc du coût et de la latence. Il faut écrire et maintenir l'orchestration. Les informations doivent passer d'un agent à l'autre, et chaque passage est une occasion d'en perdre un morceau : l'agent de synthèse ne voit que ce que les autres ont bien voulu lui transmettre. Et quand le résultat final est faux, bon courage pour trouver lequel des quatre s'est trompé.

C'est un peu comme dans une vraie équipe. Mettre quatre personnes sur une tâche qu'une seule pouvait faire en une heure, c'est rarement quatre fois plus rapide, et c'est souvent une réunion de plus.

La bonne question n'est donc pas "combien d'agents ?", mais "est-ce que les responsabilités sont vraiment séparables ?". Si chaque agent a un rôle clair, des entrées et des sorties bien définies, et que le travail se découpe proprement, le multi-agent a tout son sens. Sinon, un seul agent bien conçu, avec les bons outils, fera souvent mieux, plus vite et moins cher.

Seulement, dès qu'on commence à connecter beaucoup d'outils et plusieurs agents, un autre problème apparaît : chaque connexion est une intégration spécifique à écrire. Comment standardiser tout ça ? C'est là qu'arrive MCP, le sujet du prochain post.