Lo que 1.000 sesiones de agentes nos enseñaron sobre el enrutamiento LLM
Building in public: el panel Agent Sessions

Despliegas un agente. Le das a run. Y después, nada. Está vivo en algún lugar, consumiendo tokens, tomando decisiones, llamando a tools. Tienes logs. Quizás un contador de tokens. Pero no tienes ni idea de cuántos turns ha hecho esa sesión en realidad, si el modelo cambió a mitad de ejecución, si la sesión divergió y se recuperó, o si lleva 20 minutos atascada en un tool loop.

Esto no es un edge case de nicho. Es el estado por defecto cuando corres agentes en producción.

Así que construimos algo para solucionarlo.

El punto ciego

Cuando operas un gateway LLM compartido, uno que gestiona tráfico en múltiples workspaces, decenas de claves API, y una mezcla de casos de uso de chat y agénticos, desarrollas un tipo muy específico de ansiedad. Puedes ver las requests entrando y las respuestas saliendo. Puedes ver los token counts. Pero una sesión de agente no es una request. Es una serie de requests, unidas por el contexto, la intención y las tool calls, y ninguna primitiva de observabilidad estándar te dice cómo va esa sesión.

La pregunta que seguía apareciendo internamente era simple: ¿esta sesión se está comportando con normalidad, o hay algo que falla?

No puedes responder esa pregunta desde logs de requests individuales. Puedes responderla si trackeas la sesión como un todo.

Lo que construimos

En las últimas semanas, lanzamos el panel Agent Sessions dentro del dashboard de HiWay2LLM. Tiene dos capas.

La primera es un monitor de sesiones en directo: sesiones actualmente activas, su turn count en progreso, su estado de divergencia, y si alguna sesión activa ha cruzado al territorio que típicamente señala problemas. Se refresca en tiempo real. Cuando algo parece mal, lo ves de inmediato, no te enteras en el informe de costes del día siguiente.

La segunda es la analytics a 30 días sobre todo el tráfico agéntico de tu workspace. Aquí es donde viven las cosas interesantes.

Las métricas que cambiaron nuestra forma de pensar

Turns por sesión

Parece obvio hasta que te das cuenta de lo rara que es la gente que realmente lo mide.

Los tokens miden el volumen. Los turns miden el comportamiento. Un agente que hace 4 turns de 10.000 tokens cada uno está haciendo algo completamente diferente a uno que hace 40 turns de 1.000 tokens, incluso si el total de tokens es el mismo.

Los turns por sesión te dicen con qué profundidad razonan tus agentes antes de converger en una respuesta. Te dicen cuándo una tarea es genuinamente compleja frente a cuándo un agente está dando vueltas en círculos. Te dicen si tu estrategia de prompting es precisa o si el modelo está vagando.

En cuanto empezamos a mostrar el promedio de turns por sesión junto a los costes en tokens, nuestra lectura del rendimiento de los agentes cambió por completo. Dejamos de preguntar "¿cuánto cuesta este agente?" y empezamos a preguntar "¿cuántos turns necesita, y por qué?"

Tasa de divergencia y tasa de recuperación

Un agente diverge cuando se aparta del comportamiento esperado, deriva de contexto, tool calls circulares, razonamiento que deja de converger. La divergencia pasa. La pregunta interesante no es si pasa, sino si el agente se recupera.

Un agente que diverge y se recupera en dos turns está sano. Un agente que diverge y entra en bucle durante 30 turns es un problema. Ambos casos son idénticos en un token count bruto. Son completamente diferentes en las session analytics.

Trackeamos tanto la tasa de divergencia (con qué frecuencia las sesiones se descarrilan) como la tasa de recuperación (de esas, cuántas vuelven al camino). Un workspace con un 12% de tasa de divergencia y un 90% de tasa de recuperación está en muy buena forma. Un workspace con un 5% de divergencia y un 40% de recuperación tiene un problema estructural, tasa de fallo baja, pero cuando las cosas se tuercen, se tuercen de verdad.

Ver esta ratio a lo largo del tiempo te dice más sobre la fiabilidad de tu agente que cualquier traza de sesión individual.

Model affinity

Esta nos sorprendió más. Esperábamos que los workspaces usaran modelos diferentes para tareas diferentes, Opus para razonamiento pesado, Haiku para operaciones simples, quizás una mezcla según la hora del día o la complejidad de la request. Ese es el comportamiento racional y optimizado en costes.

No es lo que vimos.

Una vez que un workspace encuentra un modelo que funciona para su caso de uso, se queda ahí. La distribución entre sesiones tiende a consolidarse hacia uno o dos modelos manejando más del 80% del tráfico. Esto ocurre gradualmente, a menudo sin ninguna decisión explícita, los ingenieros prueban un modelo, funciona, dejan de experimentar, y la afinidad se bloquea.

La model affinity es una señal útil porque te dice si tu estrategia de routing está funcionando como pretendes. Si se supone que estás usando el perfil AGENT con selección automática de modelo pero tus sesiones están golpeando siempre el mismo endpoint, algo en tu configuración no coincide con tu intención.

La señal inesperada: el turn count como detector de bucles

Aquí hay algo de lo que nadie habla: la señal de alerta temprana más fiable de un tool loop no es el token count. No es la latencia. No es la tasa de errores.

Es un número de turns anormalmente alto por sesión.

Cuando el turn count de una sesión sube significativamente por encima de la baseline que observas en tu tráfico normal, casi siempre es un agente atascado. El modelo sigue llamando a un tool, recibe un resultado que no sabe cómo manejar, y llama al tool de nuevo. Cada turno añade más turnos. La sesión nunca termina.

Aprendimos esto mirando los datos. Las sesiones que habían sido flagueadas manualmente como "algo salió mal" se agrupaban en turn counts muy por encima de la mediana del workspace. No necesariamente pesadas en tokens, algunas eran ligeras en tokens porque cada tool call era barata. Pero el número de ciclos de ida y vuelta era la pista.

Así que construimos una capa de alerting encima. Cuando el turn count de una sesión activa supera claramente el rango normal observado para ese workspace, aparece en el monitor. No como un hard block, de eso se encarga Guardian. Como un flag: esta sesión se está comportando de forma diferente a tu baseline. Vale la pena revisarla.

El objetivo no es parar todas las sesiones largas. Algunas tareas legítimas genuinamente necesitan muchos turns. El objetivo es separar "tarea compleja" de "agente atascado", y la forma más rápida de hacerlo es comparar con lo que parece normal para tu workspace específico, no un umbral global.

Lo que cambia

La analytics sin acción es solo ruido. La razón por la que construimos este panel es que los datos alimentan directamente las recomendaciones de routing.

Cuando vemos un workspace con una media de 7 turns por sesión en un perfil CHAT, podemos mostrar un prompt: cambiar al perfil AGENT mejoraría la coherencia de las sesiones y reduciría la tasa de divergencia. La analytics está observando. La lógica de routing puede responder.

El bucle se cierra: observar sesiones, aprender patrones, mejorar el routing, medir de nuevo. Esa es la infraestructura que no teníamos hace seis meses.

Esto también cambia cómo pensamos el producto en sí. Cada métrica que mostramos en analytics es una métrica sobre la que podemos optimizar en la capa de routing. La model affinity nos dice dónde aplicar selección inteligente de modelo. La tasa de recuperación nos dice dónde reforzar el manejo de divergencias. La distribución de turn counts nos dice cómo calibrar los guardrails a nivel de sesión.

Nada de esto era visible cuando solo teníamos logs por request.

Building in public

Una cosa que no esperábamos aprender: el patrón de model affinity es prácticamente universal. Entramos pensando que los workspaces agénticos mostrarían un uso diverso de modelos a medida que optimizan para diferentes tareas. Lo que encontramos es que la mayoría de los workspaces no están optimizando a esa granularidad, encuentran algo que funciona y se quedan con ello.

No es una crítica. Es una realidad de flujo de trabajo. Los ingenieros están ocupados. Si un modelo funciona, no sigues experimentando. El insight para nosotros es que el valor del routing inteligente es mayor de lo que pensábamos, precisamente porque la mayoría de los equipos no lo hacen manualmente. La infraestructura necesita hacerlo por ellos.

La segunda cosa que no esperábamos: lo rápido que aparece la señal de turn count en los datos. Asumíamos que necesitaríamos acumular muchas sesiones antes de que la distribución se volviera significativa. En la práctica, incluso volúmenes de tráfico modestos producen una baseline clara rápidamente. La señal es estable.

Eso es lo que nos enseñaron 1.000 sesiones de agentes. No una lista de métricas obvias. La forma en que los agentes se comportan realmente cuando los observas con atención, y qué hacer cuando esa forma parece torcida.

---

Lecturas relacionadas: Vimos a un agente de IA quemar 200 $ a las 3 de la mañana, Tu gateway LLM no sabe que estás corriendo un agente.