Ce que 1 000 sessions d'agents nous ont appris sur le routing LLM
Building in public : le panel Agent Sessions

Tu déploies un agent. Tu appuies sur run. Et après, plus rien. Il tourne quelque part, il consomme des tokens, il prend des décisions, il appelle des tools. Tu as des logs. Peut-être un compteur de tokens. Mais tu n'as aucune idée du nombre de turns que cette session a réellement faits, si le modèle a changé en cours de route, si la session a divergé et récupéré, ou si elle est coincée dans un tool loop depuis 20 minutes.

Ce n'est pas un edge case de niche. C'est l'état par défaut quand on fait tourner des agents en production.

Alors on a construit quelque chose pour y remédier.

L'angle mort

Quand tu opères un gateway LLM partagé, un qui gère du trafic sur plusieurs workspaces, des dizaines de clés API, et un mix de cas d'usage chat et agentique, tu développes une anxiété très spécifique. Tu vois des requêtes entrer et des réponses sortir. Tu vois les token counts. Mais une session d'agent n'est pas une requête. C'est une série de requêtes, reliées par le contexte, l'intention et les appels d'outils, et aucune primitive d'observabilité standard ne te dit comment ça se passe.

La question qui revenait en interne était simple : cette session se comporte normalement, ou il y a un problème ?

Tu ne peux pas répondre à cette question depuis des logs de requêtes individuelles. Tu peux y répondre si tu trackes la session dans son ensemble.

Ce qu'on a buildé

Ces dernières semaines, on a sorti le panel Agent Sessions dans le dashboard HiWay2LLM. Il a deux couches.

La première, c'est un moniteur de sessions en direct : sessions actuellement actives, leur nombre de turns en cours, leur statut de divergence, et si une session active a franchi le seuil qui signale généralement un problème. Il se rafraîchit en temps réel. Quand quelque chose cloche, tu le vois immédiatement, tu ne l'apprends pas dans le rapport de coûts du lendemain.

La deuxième, c'est l'analytics sur 30 jours sur tout le trafic agentique de ton workspace. C'est là que les choses intéressantes habitent.

Les métriques qui ont changé notre façon de penser

Turns par session

Ça paraît évident jusqu'à ce que tu réalises à quel point personne ne le mesure vraiment.

Les tokens mesurent le volume. Les turns mesurent le comportement. Un agent qui fait 4 turns de 10 000 tokens chacun fait quelque chose de fondamentalement différent d'un agent qui fait 40 turns de 1 000 tokens, même si le total de tokens est identique.

Les turns par session te disent à quel point tes agents raisonnent en profondeur avant de converger vers une réponse. Ils te disent quand une tâche est genuinement complexe par opposition à un agent qui tourne en rond. Ils te disent si ta stratégie de prompting est serrée ou si le modèle erre.

Dès qu'on a commencé à afficher les turns moyens par session à côté des coûts en tokens, notre lecture des performances des agents a complètement changé. On a arrêté de demander "combien coûte cet agent ?" et on a commencé à demander "combien de turns lui faut-il, et pourquoi ?"

Taux de divergence et taux de récupération

Un agent diverge quand il s'écarte du comportement attendu, dérive du contexte, tool calls circulaires, raisonnement qui arrête de converger. La divergence arrive. La vraie question n'est pas si ça arrive, mais si l'agent récupère.

Un agent qui diverge et récupère en deux turns est en bonne santé. Un agent qui diverge et boucle pendant 30 turns est un problème. Ces deux cas sont identiques dans un token count brut. Ils sont complètement différents dans les session analytics.

On tracke à la fois le taux de divergence (à quelle fréquence les sessions déraillent) et le taux de récupération (parmi celles-là, combien reviennent sur les rails). Un workspace avec un taux de divergence de 12% et un taux de récupération de 90% est en très bonne forme. Un workspace avec 5% de divergence et 40% de récupération a un problème structurel, faible taux d'échec, mais quand ça merde, ça merde vraiment.

Regarder ce ratio dans le temps t'en dit plus sur la fiabilité de tes agents que n'importe quelle trace de session individuelle.

L'affinité modèle

Celle-là, on ne s'y attendait pas. On pensait que les workspaces allaient utiliser des modèles différents selon les tâches, Opus pour le raisonnement lourd, Haiku pour les ops simples, peut-être un mix selon l'heure ou la complexité de la requête. C'est le comportement rationnel et cost-optimisé.

Ce n'est pas ce qu'on a vu.

Une fois qu'un workspace trouve un modèle qui marche pour son use case, il y reste. La distribution sur les sessions tend à se consolider vers un ou deux modèles qui prennent plus de 80% du trafic. Ça arrive progressivement, souvent sans aucune décision explicite, les développeurs testent un modèle, ça marche, ils arrêtent d'expérimenter, et l'affinité se verrouille.

L'affinité modèle est un signal utile parce qu'elle te dit si ta stratégie de routing fonctionne comme prévu. Si tu es censé utiliser le profil AGENT avec une sélection de modèle automatique mais que tes sessions tapent toutes sur le même endpoint, quelque chose dans ta configuration ne correspond pas à ton intention.

Le signal inattendu : le nombre de turns comme détecteur de boucle

Voilà quelque chose dont personne ne parle : le signal précoce le plus fiable d'un tool loop, ce n'est pas le token count. Ce n'est pas la latence. Ce n'est pas le taux d'erreur.

C'est un nombre de turns anormalement élevé par session.

Quand le nombre de turns d'une session grimpe significativement au-delà de la baseline observée dans ton trafic normal, c'est presque toujours un agent coincé. Le modèle continue d'appeler un tool, reçoit un résultat qu'il ne sait pas comment gérer, et rappelle le tool. Chaque tour ajoute des tours. La session ne se termine jamais.

On a appris ça en regardant les données. Les sessions qui avaient été flaggées manuellement comme "quelque chose s'est mal passé" se regroupaient à des turn counts bien au-dessus de la médiane du workspace. Pas forcément token-heavy, certaines étaient même token-light parce que chaque tool call était bon marché. Mais le nombre de cycles aller-retour était le signe révélateur.

Alors on a construit une couche d'alerting par-dessus. Quand le turn count d'une session active dépasse nettement la plage normale observée pour ce workspace, ça remonte dans le moniteur. Pas comme un hard block, Guardian gère ça. Comme un flag : cette session se comporte différemment de ta baseline. Ça mérite un coup d'œil.

L'objectif n'est pas d'arrêter toutes les sessions longues. Certaines tâches légitimes nécessitent genuinement beaucoup de turns. L'objectif est de distinguer "tâche complexe" de "agent coincé", et la façon la plus rapide de le faire est de comparer avec ce que le normal ressemble pour ton workspace spécifique, pas un seuil global.

Ce que ça change

L'analytics sans action, c'est juste du bruit. On a construit ce panel parce que les données alimentent directement les recommandations de routing.

Quand on voit un workspace qui moyenne 7 turns par session sur un profil CHAT, on peut remonter un prompt : passer au profil AGENT améliorerait la cohérence des sessions et réduirait le taux de divergence. L'analytics surveille. La logique de routing peut répondre.

La boucle se ferme : observer les sessions, apprendre les patterns, améliorer le routing, mesurer à nouveau. C'est l'infrastructure qu'on n'avait pas il y a six mois.

Ça change aussi notre façon de penser le produit lui-même. Chaque métrique qu'on affiche dans l'analytics est une métrique sur laquelle on peut optimiser au niveau de la couche routing. L'affinité modèle nous dit où appliquer la sélection intelligente de modèle. Le taux de récupération nous dit où renforcer la gestion des divergences. La distribution des turn counts nous dit comment calibrer les guardrails au niveau session.

Rien de tout ça n'était visible quand on n'avait que des logs par requête.

Building in public

Une chose qu'on n'avait pas anticipée : le pattern d'affinité modèle est quasiment universel. On est parti en pensant que les workspaces agentiques montreraient une utilisation diverse des modèles au fur et à mesure qu'ils optimisent pour différentes tâches. Ce qu'on a trouvé, c'est que la plupart des workspaces n'optimisent pas à cette granularité, ils trouvent quelque chose qui marche et ils y restent.

Ce n'est pas une critique. C'est une réalité de workflow. Les devs sont occupés. Si un modèle marche, tu n'arrêtes pas d'expérimenter. L'insight pour nous, c'est que la valeur du routing intelligent est plus haute qu'on ne pensait, précisément parce que la plupart des équipes ne le font pas manuellement. L'infrastructure doit le faire pour elles.

La deuxième surprise : à quelle vitesse le signal de turn count apparaît dans les données. On pensait qu'il faudrait accumuler beaucoup de sessions avant que la distribution devienne significative. En pratique, même des volumes de trafic modestes produisent une baseline claire rapidement. Le signal est stable.

C'est ce que 1 000 sessions d'agents nous ont appris. Pas une liste de métriques évidentes. La forme de comment les agents se comportent vraiment quand tu les regardes attentivement, et quoi faire quand cette forme a l'air de travers.

---

Lectures liées : On a regardé un agent IA cramer 200 $ à 3 h du mat, Ton gateway LLM ne sait pas que tu fais tourner un agent.