La semaine dernière, j'ai écrit sur NeMoCo, un système auto-supervisé qui apprend à catégoriser les structures neuronales de la même manière que le cerveau catégorise le monde — à partir d'une expérience brute et non étiquetée, sans qu'on lui indique quelles sont les catégories. Je suis revenu plusieurs fois à la même phrase : les étiquettes sont un raccourci, c'est la structure qui compte.

Cette semaine, j'ai construit l'autre moitié de cette idée, dans le domaine où je travaille réellement. Je fais tourner un assistant IA personnel — Aura — qui gère la mémoire, achemine les tâches et tente d'être réellement utile d'une session à l'autre. Il s'appuie sur une flotte de modèles : Claude pour le codage en production, une poignée de modèles cloud pour la recherche et le design, et un modèle local qui ne consomme rien. Le problème est le même que celui résolu par NeMoCo, mais inversé. NeMoCo apprend la structure à partir des données brutes. J'avais la structure — une liste d'agents, chacun ayant un rôle — et j'avais besoin que le système décide quel modèle doit effectuer quelle tâche, en temps réel, dans le cadre d'un budget qui s'épuise.

Ce moteur de décision est ce que j'ai construit cette semaine. Il comporte trois parties : un classificateur qui lit une tâche et décide du type de travail qu'elle représente, un routeur qui l'associe à la meilleure chaîne de modèles compte tenu du quota en temps réel, et un tableau de bord qui présente l'ensemble comme un cerveau vivant et pulsant. Il s'agit de la rédaction technique — ce que fait chaque pièce, pourquoi elle a cette forme, et les échecs qui ont conduit à la conception.

Le problème : Une liste n'est pas un routeur

La configuration naïve est un tableau statique : cet agent exécute ce modèle, cet autre agent exécute cet autre modèle. C'est simple, et c'est faux, pour trois raisons.

Premièrement, le budget s'épuise. Claude fonctionne avec un quota hebdomadaire et un quota de session glissant, et ils évoluent indépendamment. Un jour, le quota hebdomadaire était à 15 % tandis que le quota de session était à 71 % — et comme l'ancien routeur ne surveillait que le chiffre hebdomadaire, il a indiqué « Claude disponible, mode NORMAL » et a dirigé le travail de codage directement dans un mur. L'interface en ligne de commande a refusé chaque appel pendant trois heures avec « Vous avez atteint votre limite de session » alors que le tableau de bord continuait d'afficher que tout allait bien. Un routeur qui ne lit pas la limite réellement contraignante n'est pas un routeur, c'est une supposition.

Deuxièmement, la qualité n'est pas un seul chiffre. Un modèle qui écrit du bon code n'est pas forcément bon pour la récupération de long contexte ou la génération d'interface. Noter chaque modèle avec un seul score « qualité » est inutile — cela ne permet pas de savoir quel modèle devrait diriger le codeur par rapport au chercheur. Chaque agent doit être évalué sur son propre axe.

Troisièmement, le réviseur ne doit pas hériter des points aveugles de l'auteur. Je paire délibérément un rédacteur et un réviseur — le codeur écrit, le diagnostiqueur révise — et ils doivent exécuter différents familles de modèles, sinon le réviseur ne fait que répéter les mêmes erreurs. La première version du routeur faisait toujours atterrir les deux têtes sur le même modèle parce qu'elle départageait les égalités par la latence. Cela annihilait toute la conception.

Alors la table statique devait disparaître. Ce qui l'a remplacée est un moteur de décision qui lit l'état en direct et calcule, par tâche, la meilleure chaîne de modèles.

Le classificateur : lecture de la tâche

La première pièce est un classificateur qui lit une tâche et décide quel type de travail elle représente. L'entrée est une phrase — « le point de terminaison de paiement renvoie 500 en production depuis le déploiement » — et la sortie est un verdict : type, niveau et priorité.

La première version était pure regex. Elle fonctionnait, mais elle était fragile exactement de la manière dont la regex l'est toujours. « Log parser » a été mal dirigé vers les opérations (c'est un composant de code, pas une tâche d'opérations). « Checkout facture deux fois les clients » ne contenait aucun vocabulaire d'erreur, donc il a été classé comme unknown et est passé au travers vers l'agent principal — lors d'un incident en production. « Throwing 500s » ne correspondait pas au modèle de code de statut parce que le « s » final rompait la frontière de mot. Chacun de ces cas était une mauvaise direction réelle que j'ai corrigée une à la fois, et chaque correction était une nouvelle règle de regex. C'est le signe que vous luttez contre le mauvais outil.

Maintenant, le classificateur essaie d'abord un modèle peu coûteux — `deepseek-v4-flash:cloud` lit la tâche et renvoie un verdict JSON. Si le modèle est indisponible, il revient au classificateur regex. Le modèle est le chemin principal ; le regex est le filet de sécurité. C'est la même leçon que NeMoCo : ne pas étiqueter manuellement chaque cas, apprendre la structure et laisser le transfert s'opérer.

Le classificateur reçoit également le quota en direct de son appelant, afin de ne jamais s'écarter du routeur. L'appelant lit l'état du quota et le transmet ; le classificateur ne lit pas directement le fichier de quota. La règle clé : le travail en production n'est jamais rétrogradé vers un modèle faible, aussi serré soit le budget. Un incident en production est classé comme `prod` même lorsque Claude est épuisé — il n'est pas discrètement réorienté vers un agent léger et signalé comme terminé. Il bloque, et le protocole de transfert s'active. Le risque de qualité est pire que le risque de quota, et la conception n'oublie jamais lequel est lequel.

Le routeur : le moteur de décision

Le routeur est où se produit la véritable réflexion. Il prend le verdict du classificateur et l'état en direct du fournisseur, puis calcule une chaîne de modèles par niveau de tâche.

Le noyau est basé sur les axes. Chaque agent est noté sur son propre axe de compétence — le codeur sur la génération de code, le diagnostiqueur sur le raisonnement de débogage, le chercheur sur la récupération de faits, le créatif sur la génération d'interface utilisateur, l'opérateur sur l'appel d'outils, le principal sur l'orchestration. La qualité effective d'un modèle est son score de référence synthétique fois sa fiabilité observée lors des sessions réelles. Un modèle qui obtient de bons résultats aux benchmarks mais qui commet des erreurs en production est rétrogradé. C'est la couche « apprendre à partir des performances réelles » : le benchmark représente la capacité synthétique, les données de fiabilité sont ce qui a réellement tenu.

La formule de notation est la matrice de poids de Bander : `score = quality·Wq − cost·Wc − latency·Wl + claudeBonus`. Le coût est un relatif échelon de 0 à 1, pas des dollars réels — parce qu'Ollama Cloud n'a pas de prix par appel et que Claude est un abonnement, vous ne pouvez pas les mettre à l'échelle min-max honnêtement l'un contre l'autre. Et il y a un seuil de qualité strict : un candidat qui obtient un score inférieur à ce seuil sur son propre axe est éliminé avant le classement, donc un modèle bon marché mais stupide ne peut jamais gagner uniquement sur le prix.

Le routeur gère également le problème de décorrélation — en obligeant les têtes du codeur et du diagnostiqueur à appartenir à différentes familles de modèles afin que le réviseur n'hérite pas des points aveugles du rédacteur. Il gère aussi le économie des sous-agents : un sous-agent exécute une tranche du travail de son parent, et une délégation peut se déclencher jusqu'à 20 fois, donc les chaînes de sous-agents pondèrent le coût bien au-dessus de tout échelon standard. C'est ce qui exclut Claude des chaînes de sous-agents sans interdiction stricte — avec un poids de coût de 0,45, il ne peut tout simplement pas gagner.

Le tableau de bord : Le cerveau robotique

Le tableau de bord est la partie la plus difficile à saisir en texte. Il représente l'ensemble du système sous la forme d'un cerveau vivant.

Il existe une vue 3D du cerveau — une structure neuronale rendue par WebGL où chaque agent est une région, et vous pouvez faire orbiter, zoomer et cliquer sur une région pour explorer sa chaîne de modèles, ses statistiques et son sélecteur de remplacement. Et il y a un « centrepiece du cerveau électronique » dans la vue en grille : un tableau de circuit SVG où les agents sont des nœuds de workflow reliés par des traces de signal animées, l'ensemble pulsant plus rapidement ou plus lentement en fonction de l'activité en direct.

Le cerveau n'est pas seulement une décoration. C'est de la télémétrie rendue visible. Le tableau de bord déduit l'activité par agent à partir de la croissance des fichiers de session entre les sondages — le signal le plus fort indiquant qu'un agent travaille réellement — et la représente sous forme d'impulsions de signal se déplaçant le long des traces de circuit. Lorsque le système est inactif, le cerveau ralentit à un rampement. Lorsqu'il est occupé, les traces s'accélèrent. Vous pouvez voir le cerveau penser.

Il existe également un sélecteur de niveau — six boutons (Niveau 1–4, un bouclier « Local » et une réinitialisation « Baseline ») permettant de forcer toute la flotte à se placer sur un niveau de qualité donné. Et les remplacements de modèle par agent, persistés dans un fichier, vous permettent d'épingler un modèle spécifique à un agent spécifique lorsque le choix du routeur en direct ne correspond pas à ce que vous souhaitez. Le tableau de bord est la surface de contrôle du cerveau.

Les échecs qui l'ont façonné

Chaque décision de conception ici est une cicatrice d'un véritable échec, et elles méritent d'être listées parce qu'elles constituent le contenu réel de la semaine :

• Le point aveugle de la limite de session. Le routeur ne tenait compte que du quota hebdomadaire et ignorait le quota de session qui était réellement contraignant. La correction : lire les deux, et laisser le plus serré l'emporter.
• Le bogue d'enveloppe de référence. Le benchmark rev1 a écrit son fichier dans une enveloppe `{value:[...]}` au lieu d'un tableau simple, donc chaque ligne manquait du champ `.model` et le router a reçu silencieusement une carte vide. Les données de référence n'ont jamais atteint le router, et rien ne s'est plaint. La correction : déballer la forme héritée afin que les anciens fichiers puissent encore être chargés.
• L'inversion axe‑rubrique. Le rubrique d'axe a attribué un score de 0.50 à opus sur le raisonnement de débogage — en dessous d'un modèle qui ne devrait jamais examiner du code de production. Le laisser réordonner les niveaux de production aurait fait du réviseur l'auteur. La correction : les niveaux de production ne sont pas reclassés par le rubrique. Un rubrique de mot-clé n'est pas une preuve suffisamment forte pour renverser une décision de conception déclarée.
• La spirale de la mort de la fenêtre de contexte. Placer un modèle de contexte de 131k en tête de la couche d'orchestration a débordé la fenêtre et déclenché la spirale de mort de la compaction. La correction : chaque candidat d'orchestration doit avoir une fenêtre largement au-dessus du budget de contexte plus la réserve.
• L'absence d'opération de fiabilité. Les journaux de session stockent le nom du modèle brut tandis que les candidats portent un préfixe de fournisseur, donc la couche de fiabilité ne trouve rien silencieusement. La correction : supprimer le préfixe avant la correspondance.

Ce que je retiens

Le post NeMoCo s'est terminé par : les étiquettes sont un raccourci, la structure est ce qui compte, et vous pouvez apprendre la structure à partir de l'expérience brute. Cette semaine a été la version ingénierie de cela. Je n'ai pas écrit à la main une règle pour chaque tâche — j'ai construit un classifieur qui lit la tâche et un routeur qui lit l'état en direct, et j'ai laissé la structure du travail décider de l'outil. Le classifieur basé sur les expressions régulières était l'approche « étiquettes », et il a échoué exactement là où les étiquettes échouent toujours : aux bords, sur les cas que vous n'aviez pas anticipés. Le classifieur assisté par modèle est l'approche « structure » : apprenez le motif, transférez-le, revenez en arrière avec élégance.

Et le tableau de bord du cerveau est la partie qui le rend réel. Lorsque vous pouvez observer les impulsions de signal courir le long des traces du circuit tandis que les agents travaillent réellement, et voir l'ensemble ralentir à un pas de tortue lorsqu'il est inactif, vous ne regardez plus un fichier de configuration. Vous regardez un système qui possède un pouls.

Le routeur est open-source dans l'esprit — c'est un ensemble de scripts dans mon espace de travail, `classify-job.mjs`, `model-router-core.ps1`, `quota-dashboard.mjs` — et il s'exécute sur un mélange de Claude, de modèles ollama cloud, et d'un modèle local qui ne consomme rien. Ce n'est pas un système d'entreprise verrouillé. C'est un moteur de décision que vous pourriez construire vous-même, et les échecs qui l'ont façonné en sont la partie utile.

C'est la leçon. Une liste est une liste. Un routeur est une décision. Et un cerveau est ce que vous obtenez lorsque la décision est prise en direct, dans le cadre d'un budget qui s'épuise, par un système qui apprend de ses propres erreurs.