La couche de décision : où Jev, l'API Decisions et leur écosystème se placent dans une pile d'agent

Le billet précédent comparait Jev et l'API Decisions d'OpenAI sur le prix, la vitesse et les entrées. Celui-ci parle de placement : quels appels d'un agent sont des décisions plutôt que de la génération, ce qui se trouve au-dessus et au-dessous d'un modèle de décision, et lesquels des outils apparus autour des deux leaders en octobre 2026 méritent d'être connus. En bref : un modèle de décision est un appel de fonction typé assorti d'une probabilité, et l'architecture qui en profite est celle qui avait déjà un classifieur, un routeur ou une garde écrits sous forme de prompt et d'expression régulière.

Deux chaînes

Un contrôle en mode chat enchaîne prompt, texte généré, analyseur, validation, nouvel essai, action. Un contrôle en mode décision enchaîne état et question bornée, décision typée, contrôle de politique, action. Le second supprime l'analyseur et le nouvel essai, et c'est là que partent à la fois la latence et le coût.

Seules les pages qui passent deux décisions bon marché atteignent le modèle coûteux. Le billet de Firecrawl présente son propre produit comme l'entrée dont une couche de décision a besoin : des pages vivantes converties en markdown propre ou en JSON typé ; Valyu fait de même pour la recherche dans les dépôts réglementaires, les articles et les données de marché, et le motif que son auteur recommande est récupération d'abord, décision ensuite, génération en dernier.

Garder une action

Le cas d'usage qu'OpenAI nomme en premier, « choisir la prochaine action d'un agent », est aussi celui où la couche de politique compte le plus. Le modèle propose ; le code garde la liste blanche.

Le seuil n'appartient pas au modèle. Les deux éditeurs disent de le fixer à partir de données étiquetées, et le billet précédent listait pourquoi : sensibilité à l'ordre, état rembourré, lecture littérale. La confiance est une entrée d'une politique, jamais la politique.

Les couches

Deux remarques sur les couches. OpenRouter sert Jev par son propre point d'entrée, POST /api/alpha/decisions, qu'un SDK de chat compatible OpenAI ne peut pas appeler, et dont le nom entre en collision avec le produit d'OpenAI. Et les sorties structurées ne sont pas une couche de décision : elles contraignent la forme du texte généré après que le modèle a décidé quoi dire, ce qui conserve la latence de génération ; elles restent le bon outil dès que la réponse est un objet plutôt qu'un choix.

L'écosystème, par distance aux deux leaders

Le troisième anneau est le plus intéressant pour les architectes. Les réimplémentations communautaires exposent le truc au grand jour : une classification contrainte avec préfixe optimisé sur un modèle à poids ouverts, qu'un ingénieur a mesurée 2 à 3 fois plus rapide que la génération libre, loin des 40 à 200x de TypeSafe mais obtenue avec des poids que vous contrôlez. L'Elephant-1 de 9B de Base Labs se place à moins d'un point de d1-ultra sur l'index d'Artificial Analysis, selon les sources qui concordent, ce qui suggère que l'index est proche de la saturation ou que de petits modèles dédiés suffisent à la tâche.

Qui fait quoi

Placer les options

La conclusion honnête : une couche de décision mérite sa place quand un agent fait déjà beaucoup de petits choix bornés par tâche, et elle se rembourse deux fois, une fois en latence et une fois dans le code d'analyse et de nouvel essai qui disparaît. Elle ne remplace pas la génération, ne détient pas l'autorité, et sa confiance est un nombre à calibrer, pas une promesse. Commencez par le classifieur que vous avez déjà sous forme de prompt, remplacez-le par une question typée, mesurez sur vos étiquettes, et gardez la liste blanche dans le code.