« Nous en sommes un peu à l’ère de l’arbre de transmission pour les agents. » C’est ainsi que Justin Schroeder décrit le travail avec l’IA aujourd’hui. Vers 1900, une usine avait une seule grosse machine à vapeur. De longues barres en rotation portaient sa force à travers les murs, et une courroie descendait de la barre vers chaque machine. Aujourd’hui, dit-il, on place un grand modèle au milieu et on y rattache chaque tâche. Sa réponse : des agents spécialisés, de petits agents construits chacun pour une ou deux tâches.
La comparaison va plus loin qu’une belle image. Les usines ont reçu le moteur électrique, et pendant des décennies elles ont gardé la même organisation. Ce qui les a vraiment changées, c’est une prise : une tension et une fréquence communes, pour que chacun puisse acheter un moteur et le placer près d’une machine. Les agents n’ont pas encore de prise. Cette partie de la conférence parle de là où nous en sommes, maintenant.
Schroeder dirige Standard Agents, une petite entreprise qui veut écrire ce standard. Il commence par un avertissement : la conférence contient des prévisions, et les prévisions vieillissent mal. Ses premières diapositives sont des cartes postales françaises de 1899 qui imaginaient la vie en l’an 2000. La série, En l’an 2000, montre des pompiers ailés, un bus tiré par une baleine et une école du futur. Certaines se sont trompées, d’autres sont tombées étrangement juste. Gardez-les en tête pour la fin.
Une machine à vapeur, une courroie par machine
Un arbre de transmission est une longue barre en rotation qui porte la force d’un moteur vers de nombreuses machines. Sur les photos d’usine que montre Schroeder, les arbres courent le long des plafonds et sous les planchers. Chaque poste de travail a une courroie qui monte jusqu’à l’arbre. Arrêtez la machine à vapeur, et toutes les machines s’arrêtent. Les courroies happaient les vêtements et les mains. C’était peu efficace et dangereux, et ça marchait.
Son idée : le travail avec l’IA a la même forme. Un grand modèle est au milieu. Les skills (des instructions empaquetées qu’un modèle peut charger) et les serveurs MCP (une façon standard de brancher un outil sur un modèle) sont les arbres. Chaque tâche, des e-mails au code, a sa courroie qui remonte vers ce modèle. Les skills et MCP ne sont pas un problème, dit-il. C’est simplement ainsi que le travail se fait aujourd’hui.
Ce qu’il veut à la place, c’est ce que les usines ont obtenu plus tard : chaque poste avec sa propre force motrice.
Une usine en 1900, l’IA aujourd’hui
La même forme, à un siècle d’écart
Usine, vers 1900Travail IA, aujourd’hui
ÉnergieUne machine à vapeur au sous-solUn grand modèle au milieu
DistributionDes arbres dans les murs et les solsLes skills et les serveurs MCP
Chaque posteUne courroie jusqu’à l’arbreChaque tâche rattachée au modèle
Le risqueDes courroies et des arbres partoutUn agent qui peut tout atteindre
Un agent, c’est le logiciel autour du modèle
Demandez à une salle ce qu’est un agent, dit Schroeder, et chaque réponse sera différente. La sienne est courte : un logiciel déterministe qui utilise les résultats non déterministes d’un modèle pour atteindre un objectif. C’est aussi ce qu’on appelle un harnais, et pour lui les deux mots veulent désormais dire la même chose.
En construire un paraît facile. Vous appelez le modèle, il demande un outil, vous lancez l’outil et lui renvoyez le résultat. Cette boucle tient en quelques lignes. La rendre fiable, c’est la partie difficile : garder la boucle en vie pendant des appels lents, changer de fournisseur de modèle, et reprendre une exécution qui a échoué à mi-chemin.
Il construit l’agent par couches, du modèle jusqu’aux règles. La couche du haut est celle qui compte le plus pour une entreprise. Un agent de code comme Codex peut faire autant d’étapes qu’il veut. Une entreprise qui veut un seul processus mené à bien n’en veut pas. Pour elle, un agent qui ne s’arrête pas est un bug.
Ce que Schroeder appelle un agent
Le modèle n’est qu’une couche, les règles sont au-dessus
- Règles de l’agentCombien d’étapes il peut faire, et quand il doit s’arrêter.
- HooksDu code qui s’exécute à des moments fixes, à chaque fois.
- OutilsDes fonctions, de petits prompts pour les tâches annexes, des sous-agents.
- Prompt systèmeQui est l’agent, et à quoi il sert.
- Le modèleLa base sur laquelle tout le reste repose.
Souvent, un système de fichiers et l’exécution de code viennent avec.
Une entreprise de chauffage ne veut pas d’un agent pour tout
Le conseil courant, dit Schroeder, est de ne pas construire d’agents du tout. Construisez des serveurs MCP, donnez un assistant conversationnel à chaque employé, et laissez le grand modèle faire le reste. Pourtant, dans les entreprises américaines ordinaires, tout le monde construit des agents. Même les équipes qui livrent des serveurs MCP ont souvent un agent derrière chaque appel.
Il y voit trois raisons.
- L’intégration. Les entreprises veulent que le travail soit branché au plus près de leur façon de fonctionner.
- La confiance. Elles ne croient pas qu’un modèle qui peut tout toucher se limitera à ce qu’il doit faire.
- L’efficacité. Peu leur importe comment le travail est fait. Elles veulent qu’il soit bien fait, à chaque fois.
Son exemple est une entreprise de chauffage et de climatisation. Elle tourne sur des dizaines de petits processus : des campagnes locales pour le jour où la climatisation tombe en panne, la capture de prospects, l’accueil des clients, les prévisions de ventes. Chaque processus est une ligne avec un début et une fin. Ensemble, ils sont l’entreprise.
Cette entreprise n’a aucune envie d’un agent qui reprend tout, même s’il marche. Les processus marchent déjà, alors tout confier d’un coup est un trop grand risque. Ce qu’elle achètera, c’est un seul processus fait parfaitement. Prenez l’entretien de la flotte. Un camion tombe en panne et quelqu’un le signale. Quelqu’un fixe la priorité et réserve une réparation. Les dossiers sont mis à jour, et le camion reprend la route. Cette ligne, et seulement elle, est le travail de l’agent.
Un processus dans une entreprise de chauffage
Tout le travail de l’agent tient en une ligne, du début à la fin
- SignalerUn camion a un problème, et l’incident est noté.
- ÉvaluerQuelqu’un fixe la priorité.
- PlanifierUne réparation est réservée.
- Mettre à jourLes dossiers sont modifiés.
- Remettre en serviceLe camion retourne dans la flotte.
Un début, une fin. Le reste ne regarde pas l’agent.
Un agent Gmail ne peut pas aller voir Twitter
La confiance se voit le mieux avec l’e-mail. Schroeder compare deux montages. Le premier est un assistant généraliste avec une skill Gmail. Il a reçu quelques instructions sur Gmail, et vous espérez qu’il fera ce qu’il faut. Le second est un agent Gmail. Il connaît toute l’API Gmail et n’a aucun autre outil.
Demandez maintenant à chacun, pendant qu’il rédige un e-mail, d’aller voir Twitter. L’agent Gmail répond non. Il ne peut pas : il n’a aucun outil pour ça. L’assistant généraliste répond oui, et pourrait faire bien plus. L’exagération est de Schroeder : il lit que des outils populaires ont été piratés et coupe la production « par mesure préventive », pendant qu’il consulte vos e-mails. « C’est un peu exagéré, dit-il, mais pas tant que ça. »
Il dessine donc beaucoup de petits agents : un agent Gmail, un agent Figma, un agent Google Sheets. Un orchestrateur leur confie le travail, éventuellement via MCP. Il cite une conférence sur l’intérieur d’un agent populaire, qui confie ses sous-tâches à de tout petits agents.
Rien de tout cela n’est nouveau, ajoute-t-il. Les ingénieurs connaissent depuis longtemps le principe du moindre privilège (donner à chaque partie seulement les accès dont elle a besoin) et la séparation des responsabilités. Son image pour ça, c’est le jour du lancement d’Apollo 11. Quelques astronautes sont partis vers la Lune, et derrière eux se tenait toute une équipe d’experts, chacun dans son domaine.
J’ai écrit sur la même limite, vue de l’autre côté, dans Un agent peut porter votre demande, pas votre autorité. Un outil que l’agent n’a pas est une règle qu’il ne peut pas enfreindre.
La même demande, deux montages
L’agent qui n’a qu’un outil ne peut faire qu’une chose
- Quelques instructions pour utiliser Gmail
- Tous les autres outils à portée
- Vous espérez qu’il fera ce qu’il faut
- Connaît toute l’API Gmail
- N’a aucun autre outil
- « Aller voir Twitter ? » Impossible.
Un modèle faible peut gagner une tâche étroite
L’efficacité est la troisième raison, et elle commence par un problème : on ne peut pas se fier aux benchmarks publics. Schroeder montre des classements où un modèle bon marché bat un modèle de pointe. Il cite un billet selon lequel les premières victimes des benchmarks sont les gens trop occupés pour essayer les modèles eux-mêmes. C’est exactement l’entreprise de chauffage.
Il appelle ça l’effet lampadaire. Un homme qui a perdu ses clés les cherche sous le lampadaire, parce que c’est là qu’il voit clair, pas parce qu’il les a perdues là. Les scores publics sont le lampadaire. La réponse est ailleurs : une évaluation de votre propre processus. Un agent Gmail avec une seule tâche est facile à tester. Vous lui envoyez des e-mails et vous vérifiez qu’il traite chacun correctement, à chaque fois. Tester un grand assistant sur la même tâche est bien plus dur, parce que son contexte est rempli de tout le reste.
Les petits agents permettent aussi d’utiliser ce qu’on appelle des modèles « en dents de scie ». Un modèle peut exceller dans un domaine et être médiocre ailleurs, sans logique qu’on pourrait deviner. Schroeder a un projet personnel qui donne à chaque modèle le même prompt pour un petit monde en 3D. Le monde qu’il préfère vient d’un modèle de Tencent qui, selon lui, est mauvais en presque tout mais excellent en 3D. Tout ce monde a coûté 60 cents de dollar à générer.
Le coût suit la même logique. Selon Schroeder, DeepSeek V4 Flash coûte 137 fois moins cher par tâche que Claude Fable. Il dit clairement qu’il ne fonctionnera pas comme Claude en général. Mais sur une petite tâche, comme suivre une flotte de camions, il suffit. Les tests de son équipe montrent beaucoup moins de tokens dépensés sur les petites tâches, mais il précise qu’aucun de ces chiffres n’est encore public.
Tâches étroites, modèles moins chers
Pour une petite tâche, le modèle bon marché suffit
137×moins cher par tâche : DeepSeek V4 Flash face à Claude Fable
60 centspour tout un monde en 3D, par un modèle faible presque partout ailleurs
Ce sont les chiffres de l’orateur. Les tests de tokens de son équipe ne sont pas encore publics.
Trente ans de la même usine
L’histoire revient ici, et Schroeder corrige son propre récit. Le moteur électrique n’a pas changé les usines, du moins pas tout de suite. Les patrons ont mis un moteur à la place de la machine à vapeur et ont gardé chaque arbre et chaque courroie. Ça a duré, dit-il, une trentaine d’années après le moteur à induction.
Les chiffres lui donnent raison. Nikola Tesla a breveté son moteur à induction en 1888. En 1899, a calculé l’économiste Paul David, les moteurs électriques fournissaient moins de 5 % de la force qui faisait tourner les machines des usines américaines. Le reste passait encore par les arbres et les courroies.
La version de Schroeder pour aujourd’hui : mettre à jour le modèle au milieu de toutes vos skills. Ça marche, c’est un peu plus efficace, et rien d’autre ne change.
Ce qui a changé les usines, dit-il, ce sont les standards. Avant eux, personne ne s’accordait sur le courant continu ou alternatif, sur la fréquence, sur la tension. Une usine qui voulait un moteur électrique devait en construire un adapté à son propre courant. En 1918, Londres avait à elle seule dix fréquences différentes. Une fois l’Amérique du Nord fixée sur 60 hertz, et l’Europe sur 50, le moteur est devenu un produit standard. Schroeder montre une fraiseuse d’établi de 1910 et une autre de 2021. Selon lui, côté alimentation, elles sont interchangeables.
Les économistes racontent une histoire plus complète, et je l’ai racontée dans la note sur Levi’s. Les grands gains sont arrivés quand les usines ont été reconstruites autour d’un moteur par machine : des bâtiments plus légers sur un seul niveau, et des machines placées librement. Les deux lectures se complètent. Le standard a rendu abordable un moteur par machine. Le nouveau plan d’atelier, c’est ce qui l’a rendu rentable.
L’électricité dans l’atelier
Le moteur est venu d’abord, la prise l’a diffusé
- Avant 1900Les arbresUne machine à vapeur, une courroie par machine.
- 1888Le moteurTesla brevette le moteur à induction.
- 1899Même usineLes moteurs fournissent moins de 5 % de la force, souvent à la place de la vapeur.
- 1918Pas de prise communeLondres a à elle seule dix fréquences différentes.
- EnsuiteLa prise60 hertz en Amérique du Nord, 50 en Europe. Un moteur par machine.
Ce que contiendrait une prise pour agents
Il n’existe aujourd’hui aucun standard pour construire un agent. « Nous inventons tout de A à Z », dit Schroeder. Il liste ce dont les agents ont besoin avant de pouvoir se diffuser comme les moteurs.
La tension dans la liste est voulue. Un agent ne doit dépendre d’aucun fournisseur, et pourtant chaque installation doit faire tourner exactement le même modèle. Pas un modèle proche : le même modèle, chez le même fournisseur, avec la même quantification. La quantification est une version compressée des poids d’un modèle, moins chère à faire tourner mais qui peut répondre autrement. Si l’un de ces éléments change, les évaluations que vous avez faites peuvent ne plus tenir.
La composition existe par morceaux : quelques protocoles permettent déjà aux agents de se parler, et il en faut plus, dit-il.
Son entreprise veut publier une spécification open source pour construire des agents spécialisés. Le but est un environnement d’exécution, un runtime, dans lequel on installe des agents, avec des runtimes concurrents, comme il en existe pour Node ou Python.
Ce qu’il faut aux agents, selon Schroeder
Cinq règles pour un agent qu’on peut installer
BesoinCe que ça veut dire
SpécialiséConçu pour un seul processus métier
HarnaisLivré complet et modifiableMême comportement chez vous que chez moi
PortableS’installe comme un paquetAvec npm ou pip
ÉpingléAucun fournisseur imposé, un modèle exactMême modèle, fournisseur et quantification
ComposableUne façon standard de parler aux autres agentsIl en existe. Il en veut plus
Sa carte postale du futur
Schroeder termine par ses propres prévisions, alors voici sa carte postale. Il prédit qu’il y aura moins d’outils qui vous laissent choisir votre modèle. « Qui s’en soucie ? » demande-t-il. Pas l’entreprise de chauffage, en tout cas. Choisir un modèle est un fardeau pour elle : elle veut seulement que le processus soit bien fait.
Pendant les questions, quelqu’un l’interroge sur la gouvernance. Les modèles changent tout le temps : comment une entreprise garde-t-elle la main sur une flotte d’agents qui tournent sur des modèles différents ? Sa réponse est une plateforme où le service informatique voit chaque petit agent. Chacun a ses propres évaluations : des tests privés sur son propre processus, pas des scores publics. Vient alors la partie que je trouve la plus utile. Si un agent fait bien son processus, ne le mettez pas à jour. Laissez-le tranquille jusqu’à ce que son modèle soit retiré.
Le chemin des usines, appliqué aux agents
Si l’histoire se répète, le standard arrive en dernier
- Aujourd’huiUn grand modèleChaque tâche lui est rattachée par les skills et MCP. L’arbre de transmission.
- À chaque modèleChanger le moteurMettre à jour le modèle du milieu, garder le reste.
- EnsuiteDe petits agentsUne tâche chacun. Un moteur par machine.
- PuisLa priseUn standard pour les installer et les faire tourner partout.
Quelques points à garder en tête avant de prendre cette carte postale pour une carte routière.
- À qui ça profite. Schroeder vend le standard qu’il défend. Son entreprise prépare la spécification et le runtime. L’argument peut quand même être juste.
- Ses chiffres. Les 137 fois et les économies de tokens viennent de ses propres tests, sur des tâches qu’il a choisies. Personne d’extérieur ne les a encore vérifiés.
- L’histoire. Un standard seul n’a pas réparé les usines. Il a aussi fallu les reconstruire autour du travail. Une prise pour agents n’aidera pas une équipe qui garde son vieux processus.
- Le coût du petit. Dix petits agents sur dix modèles, ce sont dix choses à surveiller. Sa réponse, des évaluations privées et pas de mise à jour avant le retrait d’un modèle, est saine. C’est aussi un travail que quelqu’un doit faire.
Les cartes postales de 1899 ont vu juste sur certains points et faux sur beaucoup d’autres, et personne ne pouvait savoir lesquels à l’époque. De petits agents avec une seule tâche chacun me semblent la bonne idée, pour la confiance et les évaluations plus que pour la facture de tokens. À quoi ressemblera leur standard, la question reste ouverte.
À vous d’essayer
La conférence dure 25 minutes, en anglais. La comparaison avec l’arbre de transmission commence à 2:18, l’exemple Gmail à 10:24, les modèles en dents de scie à 15:42, et les standards à 18:53.
- Agentic AI Foundation, Why Domain-specific Agents Are the Future, Justin Schroeder de Standard Agents.
- Paul A. David, « The Dynamo and the Computer », American Economic Review, 1990 : l’article de référence sur les décennies qu’a mis le moteur électrique à rapporter.
- Levi’s a refait son processus de développement avant d’ajouter des agents, le nouvel atelier pour les agents.
- Un agent peut porter votre demande, pas votre autorité, sur les limites qu’un agent ne peut pas franchir.
- Forkez le harnais de votre agent, gardez le meilleur, sur le test d’un harnais face à votre propre tâche.
Ensuite, choisissez dans votre travail un processus avec un début et une fin clairs. Notez ce dont un agent aurait besoin pour le faire, et ce qu’il ne devrait jamais toucher. Si la deuxième liste est plus longue que la première, dites-moi de quel processus il s’agit.
Texte brut: agents-line-shaft-era.md · Flux Atom · Toutes les notes