Architecture multi-agent : pourquoi un seul agent doit écrire

Découper un gros agent IA en petits agents spécialisés, c'est le réflexe naturel dès qu'un assistant grossit. Trop d'outils, trop de responsabilités, un prompt qui déborde : on découpe, comme on a découpé les monolithes en microservices.

J'ai défendu ce découpage ici en mars et les arguments restent bons. Mais la production m'a appris une nuance qui change tout et c'est elle que cet article déplie : on ne découpe pas n'importe quoi. On peut distribuer l'intelligence. On ne distribue pas le droit d'écrire. C'est une leçon apprise en construisant des agents et enchaînements pilotés par des modèles de langage, pas en théorie.

Pour que tout le monde puisse suivre, on va dérouler un exemple volontairement simple : un assistant IA qui gère un blog de cuisine par messagerie. Son utilisatrice lui écrit « ajoute ma recette de tarte aux prunes », « crée une page Menus d'été », « réponds à ce commentaire ». L'assistant lit et écrit directement dans le site. Tout ce qui suit s'applique à n'importe quel agent qui modifie un système pour de vrai : une boutique, un CRM, un espace de travail.

Trois mots avant de commencer

Trois termes reviennent partout, avec une image pour chacun :

• un outil, c'est un bouton que le modèle peut appuyer : créer une recette, lire une page, publier une réponse ;
• un agent, c'est le modèle, plus ses consignes écrites, plus la liste des boutons qu'on l'autorise à appuyer ;
• un sous-agent, c'est un collègue à qui l'agent passe le dossier quand la demande sort de son périmètre. Celui qui distribue les dossiers, c'est le superviseur.

Le pattern superviseur et pourquoi on l'adopte

Quand l'assistant grossit, le découpage classique ressemble à ceci :

  utilisatrice
      |
  superviseur       aucun outil metier : il route, puis il redige
      |
      +-- recettes   creer, modifier, classer les recettes    ecrit
      +-- pages      composer les pages du blog               ecrit
      +-- lecteurs   repondre aux commentaires                ecrit

Un superviseur sans aucun outil métier, dont le seul rôle est de comprendre la demande, de la confier au bon spécialiste, puis de rédiger la réponse finale. Trois sous-agents derrière lui, chacun avec son prompt, ses outils, son périmètre.

Les raisons d'adopter ce pattern sont solides. Un agent unique qui porte tous les outils voit sa fenêtre de contexte se remplir de descriptions inutiles. Ses permissions deviennent impossibles à délimiter. Un changement de prompt pour un cas d'usage en casse un autre. La spécialisation règle tout cela sur le papier.

Sur le papier seulement. Parce que ce schéma contient un détail qui va tout déterminer : les trois spécialistes écrivent. Chacun peut modifier le blog. Et chaque modification passe par une frontière.

Où ça casse : la frontière

Suivez une demande banale : « Crée une page Menus d'été avec mes trois dernières recettes ».

Le superviseur reçoit le message. Il rédige une note de transmission pour le sous-agent pages : du texte libre qui résume ce qu'il a compris. Le sous-agent pages se réveille avec cette note pour tout bagage, travaille, écrit dans le site, puis rédige un compte rendu. Le superviseur lit le compte rendu et répond à l'utilisatrice.

Quatre passages de relais. Chacun peut échouer en silence.

Le compte rendu se perd en route. Un sous-agent travaille avec un plafond d'étapes, une limite au nombre d'actions qu'il peut enchaîner avant d'être coupé. S'il atteint ce plafond juste après avoir créé la page mais avant d'avoir rédigé son compte rendu, le superviseur reçoit une feuille blanche. Une feuille blanche ressemble à un échec. Il annonce donc un échec et propose de réessayer, alors que la page existe. L'utilisatrice réessaie : la voilà avec deux pages.

Le consentement ne traverse pas. L'utilisatrice a dit « oui, publie ». Ce oui reste sur le bureau du superviseur, alors que c'est le sous-agent qui exécute. Entre les deux, il n'y a que la note de transmission. Si la note reformule mal, le sous-agent redemande une confirmation qu'elle a déjà donnée. Vu de l'extérieur, l'assistant a l'air de ne pas écouter.

La mémoire ne traverse pas non plus. Le sous-agent arrive sans avoir lu la conversation : chaque délégation démarre sur une feuille blanche. « Mes trois dernières recettes », « comme la dernière fois », « le même style que la page d'accueil » : tout ce que le superviseur oublie de recopier dans sa note n'existe pas pour le spécialiste.

Et l'état se fragmente. Le sous-agent recettes crée une recette et confirme : elle existe bien en base. Mais créer une recette ne l'affiche nulle part : il faut l'ajouter à une page et les pages appartiennent à un autre sous-agent. Aucun des deux ne voit le tableau entier. L'assistant confond alors « ça existe en base » avec « un visiteur le voit » et soutient mordicus que tout va bien pendant que l'utilisatrice regarde une page vide.

Ces quatre pannes ont un point commun : le modèle n'a rien fait de faux. Chaque agent, pris isolément, a bien travaillé. Ce qui échoue, c'est la transmission. La frontière entre les agents est faite de texte libre et le texte libre perd de l'information à chaque passage.

Le signe qui ne trompe pas, c'est le jour où vous vous surprenez à écrire dans un prompt une règle du genre « au plus une modification par délégation, même si l'utilisateur en a demandé plusieurs ». Ce n'est pas une contrainte métier. C'est une cicatrice d'architecture déguisée en politique d'exécution.

Ce que dit l'état de l'art

Ce diagnostic n'est pas une opinion isolée. Trois sources, trois angles, même conclusion.

Mastra le dit dans sa documentation : gardez un seul agent quand la tâche est courte, fortement couplée et couverte par un jeu d'outils raisonnable. Pour tout ce qu'un bon agent gère déjà, des agents supplémentaires n'ajoutent que du coût et une surface de debug plus large.

LangChain donne le critère qui manque : les actions de lecture sont intrinsèquement plus parallélisables que les actions d'écriture. Le multi-agent excelle sur les requêtes en largeur, celles où l'on part chercher de l'information dans dix directions à la fois. Il échoue sur les domaines qui exigent que tous les agents partagent le même contexte. Un assistant qui modifie un système en conversant, c'est exactement ce second cas.

Cognition avait publié la position la plus tranchée, « Don't Build Multi-Agents ». Leur suite, « Multi-Agents: What's Actually Working », est plus utile encore parce qu'elle dit ce qui marche plutôt que ce qui échoue :

Les systèmes multi-agent fonctionnent le mieux aujourd'hui quand les écritures restent mono-thread et que les agents supplémentaires apportent de l'intelligence plutôt que des actions.

Et une observation qu'on lit trop vite : la plupart des montages multi-agent en production se limitent à des sous-agents en lecture seule, qui ressemblent davantage à des appels d'outils qu'à de la vraie collaboration entre agents. Ce n'est pas une critique. C'est la forme qui tient.

Le principe : un seul écrit, plusieurs pensent

L'écriture est mono-thread. L'intelligence est distribuée.

Un seul agent écrit. Il porte la mémoire de la conversation, le consentement de l'utilisatrice, le ton, la voix. Il est le seul à avoir de l'autorité sur l'état du système.

Les spécialistes, eux, cessent d'être des collègues à qui on passe le dossier. Ils deviennent des consultants : on les appelle pour un avis, ils réfléchissent dans leur coin avec leurs propres consignes, ils rendent une réponse structurée et ils ne touchent jamais au site. Techniquement, ce ne sont plus des agents mais des outils pilotés par un modèle.

  L'ECRIVAIN  ·  un seul agent, une seule voix, une seule autorite

  outils d'ecriture      consolides par famille
  outils de lecture      deterministes, gratuits, testables
  outils d'intelligence  les consultants, aucun droit d'ecriture
      composer_page      intention + etat du blog  ->  un plan
      rediger            brief + contraintes       ->  les textes
      relire             etat apres ecriture       ->  ce qui cloche

Reprenez la demande de tout à l'heure. « Crée une page Menus d'été avec mes trois dernières recettes » : l'écrivain lit le site, appelle le consultant composer_page qui lui rend un plan, demande une seule fois confirmation, écrit les blocs, appelle relire pour vérifier le résultat et répond. La mémoire, le oui et l'état du site ne quittent jamais le même contexte. Les quatre pannes du chapitre précédent ne sont pas corrigées une par une : elles deviennent impossibles à exprimer.

La nuance importante : la spécialisation ne disparaît pas. Chaque consultant garde son contexte isolé, son prompt dédié, son modèle si besoin différent. Ce qui disparaît, c'est son droit d'écrire.

Et un message court reste court. « Passe la tarte aux prunes en vedette » ne déclenche aucune délégation : l'écrivain répond seul. Dans le pattern superviseur, chaque message, même trivial, traversait une frontière.

L'objection du monolithe et comment la lever

Objection immédiate et elle est fondée : si un seul agent porte tous les outils, on retombe sur le monolithe qu'on voulait fuir. La recherche sur la sélection d'outils est claire, la précision décroche au-delà de dix à quinze outils.

La réponse tient en un mot : mesurez. Chaque outil doit être décrit au modèle, avec son nom, ce qu'il fait et la forme de ses paramètres. Ce mode d'emploi repart en entier à chaque message. Un assistant de quelques dizaines d'outils peut ainsi expédier l'équivalent de vingt pages de texte de descriptions à chaque appel, avant même que l'utilisatrice ait dit un mot. Ça se mesure en une heure, avec un script qui compile chaque description exactement comme le fait votre framework avant d'appeler le modèle. Aucun appel de modèle, aucun token dépensé.

Et la mesure révèle presque toujours la même chose : le poids vient de familles d'outils. Dix outils ajouter_bloc_menu, ajouter_bloc_titre, ajouter_bloc_grille, c'est dix façons de dire « ajoute quelque chose à la page ». Une famille se consolide en un seul outil dont un paramètre porte le type. Dix boutons deviennent un bouton et une liste déroulante.

Deux leçons de mesure, au passage :

Mesurez le total, pas le pire cas. Les descriptions partent à chaque appel : c'est la somme qui se paie en tokens, pas le plus gros outil.

Redatez vos contraintes. Si une famille a été éclatée en dix outils, c'est souvent à cause d'une limite de fournisseur, du genre des plafonds des sorties structurées, ce mécanisme qui oblige le modèle à répondre exactement dans la forme demandée. Ces limites bougent régulièrement et en général vers le haut. Une décision d'architecture prise sous une limite fournisseur porte une date de péremption que personne n'écrit. Vérifiez la vôtre : la contrainte qui a justifié votre découpage n'existe peut-être plus.

Consolidez d'abord, fusionnez ensuite. Dans cet ordre. La consolidation n'est pas un bonus, c'est la condition : sans elle, la fusion produit un agent obèse qui choisit mal ses outils ; avec elle, l'écrivain unique porte souvent moins qu'un seul de vos anciens sous-agents.

Ce que l'écriture mono-thread supprime

L'argument le plus convaincant n'est pas ce que le principe apporte, c'est ce qu'il permet de ne jamais construire. Toute la machinerie qui gère la frontière disparaît avec elle :

• Les comptes rendus entre agents et les garde-fous qui détectent quand ils arrivent vides ou tronqués
• La comptabilité des coûts par délégation, pour savoir quel sous-agent a dépensé quoi
• Les règles défensives du type « une seule modification par délégation »
• Les blocs de prompt expliquant à chaque spécialiste ce qu'il ne peut pas voir
• Les workflows de suspension et reprise, ces machines à état qui mettent une opération en pause le temps qu'un humain réponde et qui n'existent que parce qu'un sous-agent ne peut pas attendre

Ce dernier point mérite une phrase : avec un seul écrivain, une opération en attente de confirmation n'est plus un workflow suspendu à persister et à reprendre. C'est un état, dans une conversation qui continue.

Ce qu'on décompose et ce qu'on ne décompose pas

Rien de tout cela ne contredit l'article de mars. L'agent monolithique casse, la décomposition reste la bonne réponse, MCP et A2A restent la bonne plomberie : le premier pour brancher les agents aux outils, le second pour les faire dialoguer.

La nuance, c'est ce qu'on décompose.

On décompose l'intelligence : les contextes, les prompts, les modèles, les spécialités. C'est là que la séparation paie, parce qu'elle isole du raisonnement et que le raisonnement se parallélise bien.

On ne décompose pas l'autorité d'écriture. Elle reste à un seul endroit, avec la mémoire et le consentement. Une écriture répartie sur plusieurs agents, c'est un consensus à reconstruire à chaque tour et personne ne construit un consensus fiable avec du texte libre entre deux modèles.

Le parallèle microservices dit la même chose, si on le pousse un cran plus loin. On a découpé les services. On n'a jamais découpé la propriété des données : chaque donnée appartient à un service et un seul et les autres la lisent. C'est exactement la règle qui manque à la plupart des architectures multi-agent.

Un agent qui écrit. Plusieurs qui pensent.

Le reste, c'est de la plomberie.