Demandez à cinq personnes qui construisent avec des agents en ce moment ce que signifie l'orchestration d'agents, et vous obtiendrez cinq réponses différentes. Pour l'une, c'est LangGraph ou CrewAI qui achemine une tâche entre des modèles. Pour une autre, c'est un agent « manager » qui confie du travail à des spécialistes. Pour quelqu'un d'autre encore, c'est une couche de gouvernance qui n'implique presque pas d'agents du tout.
Un fil r/AI_Agents a mis un nom sur cette frustration :
Suis-je le seul à être agacé que « orchestration » signifie désormais littéralement tout en IA ?
Son argument : les éditeurs utilisent ce mot pour désigner au moins trois couches différentes, la coordination d'agents, l'acheminement des workflows et la gouvernance, et après 27 commentaires, personne ne s'était mis d'accord sur où l'une s'arrête et où l'autre commence.
La confusion ne relève pourtant pas vraiment de la sémantique. On demande au mot « orchestration » de décrire deux tâches réellement différentes, et la plupart de ce qui est commercialisé sous ce nom n'en accomplit qu'une seule.
La tâche numéro un, c'est l'acheminement. La tâche numéro deux, c'est d'être responsable.
La tâche numéro un est technique : étant donné une tâche, décider quel modèle ou quel outil traite quelle étape, transmettre le contexte, relancer en cas d'échec. C'est ce que font réellement la plupart des frameworks d'orchestration, LangGraph, CrewAI, les pipelines personnalisés, et c'est un problème raisonnablement résolu.
La tâche numéro deux est un problème de management, pas d'acheminement : qui est responsable de faire avancer réellement un objectif, quels agents existent et pourquoi, et que se passe-t-il quand l'un d'eux ne justifie plus sa place. Presque rien de ce qui est commercialisé comme de « l'orchestration » n'accomplit cette tâche. Un fil populaire sur le même subreddit a pointé ce manque sans détour, en affirmant que de nombreuses architectures multi-agents ajoutent des rôles de manager et de reviewer qui ne sont jamais confrontés à quoi que ce soit de réel, un organigramme sans aucune traçabilité de responsabilité derrière lui. Quelle que soit votre opinion sur cette critique, elle pointe vers le même trou : un routeur n'est pas une couche de management, et l'appeler ainsi ne le rend pas tel.
Même les cadrages les plus rigoureux du secteur n'y parviennent pas. Le modèle inner-loop/outer-loop d'un éditeur d'automatisation de charges de travail pour l'entreprise divise le travail des agents en une couche d'exécution (raisonnement, appels d'outils) et une couche de gouvernance (état, relances, approbations), et cela s'arrête là : une couche d'exécution et une couche de gouvernance des processus, jamais une couche qui se demande qui est responsable de l'objectif.
Le vrai goulot d'étranglement, ce n'est pas l'acheminement, c'est la supervision
Cet écart se manifeste par un problème très concret et pratique dès qu'une équipe dépasse un seul agent. Un fil r/AI_Agents consacré exactement à cela a constaté que faire tourner un seul agent de codage reste gérable, mais que superviser plusieurs agents en même temps devient rapidement le véritable goulot d'étranglement, pas l'acheminement entre eux, mais la charge pure que représente le fait de repérer ce que l'un d'eux fait mal. Une personne l'a formulé plus simplement en cherchant des outils « d'orchestration / chief of staff » pour garder ses agents et ses projets organisés : ce qu'elle cherchait réellement n'était pas un routeur, mais quelque chose pour porter le travail de coordination qu'une personne se retrouvait à faire à la main.
C'est le problème que la tâche numéro deux doit résoudre. Une couche qui se contente d'acheminer des messages entre modèles n'y touche pas. Ce qui aide vraiment, c'est quelque chose qui retire la charge de supervision des épaules d'une personne, pas seulement la logique de transmission des épaules d'un modèle.
Ce que signifie l'orchestration d'agents chez Tability
C'est exactement ce que l'Agent Manager de Tability est conçu pour faire. Il n'y a pas de liste fixe d'agents en attente d'être assignés. Vous commencez avec un objectif, une métrique, une valeur de départ, une échéance, la même forme qu'un key result dans un framework OKR, pas une tâche à faire. Un Agent Manager prend en charge cet objectif, le décompose en un plan, et détermine seulement ensuite quels spécialistes le plan nécessite réellement. Tability appelle l'unité qui en résulte une Agency : un manager plus l'équipe que son propre plan a demandée, actuellement plafonnée à six au total, le temps que le système apprenne où la coordination commence à se dégrader avec une équipe plus nombreuse.
« Tability agit comme la couche de contexte métier et d'orchestration », comme l'a formulé l'équipe en décrivant son propre dispositif d'équipes d'agents qui se recrutent elles-mêmes, et c'est là que se situe la distinction qui compte. Il ne s'agit pas de décider quel modèle traite quelle étape. C'est la couche qui porte l'objectif, le plan, et la trace de ce qui a réellement bougé, ce qui est exactement la tâche que les frameworks d'acheminement n'ont jamais été conçus pour accomplir.
C'est aussi exactement la même discipline opérationnelle que StratOps applique déjà aux équipes humaines, un propriétaire, une cadence, une trace visible de la progression par rapport à un chiffre réel, simplement étendue pour couvrir des agents recrutés pour un objectif plutôt qu'embauchés pour un rôle.
Des équipes construisent déjà la tâche numéro deux à la main
Ce n'est pas un besoin hypothétique. Un fil r/AI_Agents demandant si quelqu'un avait essayé un schéma d'« agent manager assignant du travail à des agents spécialistes » a reçu des dizaines de réponses de personnes qui font déjà exactement cela, avec des résultats mitigés. Un praticien a décrit comment il donnait une spec à un agent, le laissait découper le travail en modules, puis générait et faisait tourner des agents distincts de codage, de test et de revue pour chacun, réduisant un projet qui avait pris six semaines de 40 heures à environ dix heures de travail supervisé. D'autres ont averti que ce même schéma peut tout aussi bien produire une « architecture absurde » pleine d'agents faisant ce qu'un seul agent bien outillé, ou un simple script déterministe, aurait pu faire plus vite et moins cher.
Les deux sont vrais, et c'est bien là le sujet. Le schéma manager-plus-spécialistes est réel et il fonctionne, mais savoir si une instance donnée de ce schéma justifie la surcharge dépend entièrement du fait qu'il soit ancré dans un objectif réel ou assemblé parce que cela ressemblait au type de dispositif qu'un système « sérieux » est censé avoir. C'est ce jugement qu'Agent Manager rend structurel, en dérivant l'équipe du plan, plutôt que de le laisser à qui assemble des fils à la main cette semaine-là.
| Dimension | Dispositif multi-agents ad hoc | Tability Agent Manager |
|---|---|---|
| Comment l'équipe est décidée | Assemblée à la main, fil par fil, avant que le travail ne commence | Dérivée du plan une fois l'objectif défini |
| Qui est responsable de l'objectif | En général, personne en particulier | L'Agent Manager, pour cet objectif |
| Que se passe-t-il si un agent n'apporte rien | Il continue de tourner, sauf si quelqu'un le remarque par hasard | Il n'est pas recruté à nouveau au cycle suivant |
| Où se situe la charge de supervision | Sur une personne, et elle augmente avec chaque agent ajouté | Portée par la couche elle-même, check-ins et rapports |
| Comment sauriez-vous que ça fonctionne | Vous ne le sauriez pas, sans lire les logs | La métrique de l'objectif lui-même |
La taille de l'équipe n'est pas la variable intéressante. Qui en est responsable, si.
À quoi cela ressemble en pratique
Dans un déploiement récent, un objectif unique, faire passer la valeur du trafic de 15 000 $ à 20 000 $, a été confié à un Agent Manager. Remarquez ce qui ne s'est pas passé : personne n'a décidé à l'avance que l'équipe avait besoin d'une personne SEO, d'un spécialiste des réparations et d'un spécialiste RP. Le manager a d'abord décomposé l'objectif en un plan, et c'est le plan qui a produit ces trois rôles, dans cette combinaison, spécifiquement pour cet objectif. Un objectif différent aurait recruté une équipe différente. La mise en place d'une équipe opérationnelle a pris environ deux minutes, sans compter le temps de réflexion entre les étapes, et Tability a publié l'ensemble sous forme de speedrun de la mise en place.
Prenez du recul et les chiffres deviennent plus intéressants, et plus mesurés que ce à quoi on s'attendrait d'un système conçu pour faire monter les agents en puissance. Une version antérieure du système d'agents auto-recruteurs de Tability était passée à 20 agents à partir de seulement quatre managers, avec l'intention affichée de continuer à monter au-delà de 100. Mais la taille de l'équipe par Agency se situe actuellement à six (un manager plus cinq spécialistes), un plafond délibéré, le temps que l'équipe apprenne où la coordination commence à se dégrader avec un effectif plus important. Même au sein d'un système conçu précisément pour cela, l'objectif n'est pas un fan-out illimité. C'est une équipe qui ne grandit que lorsque le plan appelle réellement plus de bras.
Le goulot d'étranglement, selon l'équipe elle-même, n'a jamais été de faire faire le travail aux agents. C'était de suivre ce qui revenait : rapports, propositions, questions, mises à jour. C'est la même charge de supervision que décrivait le fil multi-agents évoqué plus haut, et c'est, d'une certaine manière, un bon signe : cela signifie que les agents accomplissaient suffisamment de vrai travail pour générer de vraies choses à examiner, et non simplement des comptes-rendus de statut les uns sur les autres.
Mettre en place l'équipe avant l'objectif est l'erreur habituelle
Le réflexe, quand on commence à faire travailler des agents, est d'esquisser l'équipe en premier. Un orchestrateur ici, un reviewer là, un spécialiste pour chaque fonction à laquelle on peut penser, décidés à l'avance, avant même qu'une seule tâche réelle n'existe pour en justifier un seul.
La solution n'est pas une meilleure bibliothèque de prompts pour ces rôles. C'est de ne pas du tout concevoir l'équipe en amont. Vous assignez l'objectif, vous laissez le plan révéler exactement ce dont il a besoin, et vous traitez l'existence continue de chaque agent comme quelque chose qui doit être regagné à chaque cycle, et non accordé une fois pour toutes à la mise en place.
C'est aussi là que la plupart des dispositifs d'orchestration bricolés échouent en silence : pas sur l'acheminement technique, mais sur la responsabilité. Aucun objectif auquel un agent donné soit réellement rattaché, aucune cadence fixe pour vérifier s'il a fait bouger quoi que ce soit, aucun endroit unique où un collègue peut regarder pour voir ce qui est réel par rapport à ce qui tourne simplement. Vous vous retrouvez avec une quantité de production, et un travail de supervision croissant que personne n'a signé pour faire.
Par où commencer
Avant d'ajouter le prochain agent à votre dispositif, trois questions sont plus utiles que n'importe quelle comparaison de frameworks :
- Existe-t-il un seul endroit où vous pourriez vérifier si le travail de cet agent a fait avancer l'objectif, sans lire un journal de conversation ?
- Si vous le retiriez, une personne devrait-elle reprendre la charge de supervision, ou rien ne changerait-il vraiment ?
- A-t-il été recruté parce que le plan l'exigeait, ou parce que cela ressemblait au type de rôle qu'une équipe comme celle-ci est censée avoir ?
Si vous faites déjà tourner des agents via Claude ou Codex, aucune de cette infrastructure ne disparaît. Tability ne remplace ni vos modèles ni vos outils. Il se place au-dessus d'eux comme la couche qui porte l'objectif, le plan, et la trace de ce qui s'est réellement passé, afin que vous puissiez répondre à ces trois questions sans fouiller dans un journal de conversation.
Essayez Tability gratuitement, ou réservez 30 minutes avec nous et nous examinerons votre dispositif réel, agent par agent, pour vous aider à déterminer qui est réellement responsable de quoi. Avec ou sans Tability, cela vaut la peine de connaître la réponse.
.jpg)
.png)
(1).png)
