La stack agent se scinde en deux

L'erreur la plus coûteuse en conception d'agents aujourd'hui, c'est d'utiliser le même modèle pour tout. Vous sollicitez un modèle frontière pour décider d'appeler une API, puis ce même modèle pour formater le payload JSON. L'une de ces tâches nécessite un physicien ; l'autre, un employé de bureau compétent. Payer un tarif de physicien pour du travail administratif n'est pas seulement du gaspillage — c'est de la mauvaise ingénierie. Cela couple l'intelligence de votre agent à son coût opérationnel d'une manière qui dégrade les deux.

La sortie de Muse Ember par Meta rend cette scission concrète. C'est un petit modèle conçu spécifiquement pour ce que les agents passent réellement la majorité de leurs cycles à faire : appels d'outils, routage et extraction de données [1]. À 10 centimes par million de tokens en entrée, il sous-cote largement Claude Haiku 5.5 et GPT-6 Luna [3]. Meta affirme qu'il délivre plus d'intelligence par dollar sur ces tâches répétitives, tout en admettant franchement qu'il est à la traîne en programmation pure [1]. Cet aveu est la partie intéressante. Ils ne vendent pas un modèle qui fait tout ; ils vendent un modèle qui fait les corvées de l'agent à un coût extrêmement bas.

La couche d'exécution devient une commodité

Ces deux dernières années, l'architecture par défaut des agents était monolithique. Un seul modèle — généralement un modèle frontière — gérait la planification, le raisonnement, la sélection d'outils et le travail mécanique de structuration des sorties. Cela avait du sens quand les petits modèles ne pouvaient pas produire de manière fiable des appels de fonction valides ou suivre des instructions de routage. Mais ce seuil de fiabilité a été franchi. Muse Ember n'est pas le premier petit modèle à gérer l'utilisation d'outils avec compétence, mais son prix et le positionnement explicite de Meta comme moteur d'exécution pour agents signalent que cette couche est désormais un marché de commodité.

L'implication pour les builders est que l'architecture de votre agent présente maintenant une jointure évidente. La couche de raisonnement — là où vous avez besoin d'intelligence réelle pour décomposer des tâches, gérer l'ambiguïté ou écrire du code — reste sur un modèle frontière. La couche d'exécution — là où vous avez besoin de sorties structurées, rapides et fiables à partir de patterns connus — migre vers quelque chose comme Ember. Les deux couches peuvent être des modèles différents, de fournisseurs différents, optimisés pour des choses différentes.

Ce que cela implique pour l'évaluation

Cette scission complexifie l'évaluation de manière utile. Vous ne pouvez plus benchmarker votre agent comme une boîte noire unique et considérer le travail comme fini. Un agent qui route intelligemment mais formate mal ses appels d'outils a un problème différent de celui qui formate parfaitement mais route bêtement. Quand les modèles de raisonnement et d'exécution viennent de fournisseurs différents, vous avez besoin d'évaluations qui isolent chaque couche. Cela signifie des tests pour l'adhérence au schéma des appels d'outils, la précision du routage face aux variations de prompt, et la fidélité d'extraction qui s'exécutent indépendamment de vos évaluations de planification.

Cela change aussi votre façon d'envisager le fallback. Si votre modèle d'exécution est assez bon marché, vous pouvez vous permettre de l'exécuter plusieurs fois avec différents prompts et de voter sur la sortie — un pattern prohibitif avec les modèles frontière. La fiabilité par redondance devient une stratégie légitime quand les appels redondants coûtent des fractions de centime.

La leçon d'Instagram

Il y a un second signal qui mérite attention, bien qu'il vienne d'une autre direction. L'Effect Builder d'Instagram génère maintenant des filtres AR à partir de prompts IA [2]. Ce n'est pas de l'infrastructure agent — c'est une fonctionnalité grand public. Mais cela illustre le même pattern vu de l'autre côté : l'IA se déplace vers des rôles d'exécution où la sortie est un artefact structuré, pas une conversation. Un prompt produit un filtre, pas un message de chat. Le modèle fait de l'utilisation d'outils, simplement enveloppée dans une interface conviviale.

Pour les builders d'agents, c'est un rappel que la sortie structurée est en train de devenir l'attente par défaut, pas une capacité spécialisée. Quand les apps grand public traitent le prompt-vers-artefact comme une fonctionnalité normale, la capacité de votre agent à produire du JSON valide du premier coup cesse d'être impressionnante et devient un prérequis de base. La différenciation remonte en amont, vers le raisonnement qui décide quel JSON produire et pourquoi.

Le point à retenir en pratique est simple. Examinez la consommation de tokens de votre agent et séparez-la en travail de raisonnement et travail d'exécution. Si plus de la moitié de votre dépense concerne la génération de sorties structurées, les décisions de routage ou l'adhérence au schéma, vous avez une jointure où un modèle comme Muse Ember a sa place. La différence de coût n'est pas marginale — c'est un ordre de grandeur — et le bénéfice d'ingénierie du découplage entre intelligence et exécution se composera à mesure que les deux couches évoluent à des vitesses différentes.