89% de los equipos observa sus agentes. Solo 52% los evalúa. Ahí es donde se rompen

Hay un patrón que se repite en cada equipo que lleva un agente más allá del prototipo. Primero instalan tracing, porque el primer incidente en producción es imposible de depurar sin él. Después respiran tranquilos, porque ahora "tienen visibilidad". Y meses más tarde descubren que la visibilidad les mostró cien fallas y no les dio ningún mecanismo para evitar la número ciento uno. Los datos de 2026 muestran que ese patrón no es anecdótico: es la norma de la industria.

Los números del State of Agent Engineering

La encuesta de LangChain se levantó entre el 18 de noviembre y el 2 de diciembre de 2025 con 1,340 respuestas, mayoritariamente de tecnología (63%) y con fuerte presencia de organizaciones pequeñas — 49% con menos de 100 personas. Los datos relevantes:

• 57.3% tiene agentes corriendo en producción, y 30.4% los está desarrollando con planes concretos de despliegue.
• Calidad: 32% la señala como el principal bloqueador — exactitud, relevancia y consistencia. La latencia le sigue con 20%, y el costo cayó respecto al año previo.
• 89% implementó alguna forma de observabilidad, pero solo 62% tiene tracing detallado. Entre los equipos ya en producción, la observabilidad sube a 94% y el tracing completo a 71.5%.
• 52.4% corre evaluaciones offline sobre conjuntos de prueba; solo 37.3% hace evaluación online sobre tráfico real, y apenas 25% combina ambas.
• 59.8% depende de revisión humana para casos delicados, y 53.3% usa LLM-as-judge para escalar la medición de calidad.
• 75%+ emplea múltiples modelos en producción o desarrollo, y 57% no hace fine-tuning: se apoya en modelos base con prompt engineering y RAG.

Por qué observabilidad sin evals no cierra el ciclo

La distinción es sencilla pero tiene consecuencias caras. Un trace te muestra la secuencia de ejecución detrás de una petición: las llamadas al modelo, las invocaciones de herramientas, las transiciones de estado, las lecturas y escrituras de memoria. Es forense — sirve después de que algo salió mal, y sirve muy bien. Lo que no hace es responder la pregunta que importa antes de desplegar: ¿este cambio mejoró el sistema o lo empeoró?

Ahí está el problema real de tener 89% de observabilidad contra 52% de evals: la mayoría de los equipos puede ver las fallas pero no cerró el ciclo hacia la mejora sistemática. Cada ajuste de prompt, cada cambio de versión de modelo, cada herramienta nueva se despliega confiando en que las pruebas manuales de un par de casos representan el universo de conversaciones reales. No lo representan, y el modo de falla característico es una regresión silenciosa: el agente sigue respondiendo, sigue sin lanzar errores, y empieza a equivocarse en un subconjunto de casos que nadie está mirando.

Que el 75% de los equipos use múltiples modelos vuelve esto más agudo, no menos. Cada proveedor actualiza sus modelos en su propio calendario, y un comportamiento que ajustaste con prompt engineering — sin fine-tuning, como el 57% — puede cambiar sin que tú hayas tocado una línea de código. Sin una suite de evaluación, la primera señal de esa regresión es un cliente molesto.

Cómo lo abordamos nosotros

Nuestra práctica en SmartDevs es tratar los evals como parte del entregable, no como una fase posterior que llega "cuando haya tiempo". En concreto:

• El dataset nace del negocio, no del equipo técnico. Los primeros veinte o treinta casos de prueba salen de conversaciones reales que el cliente ya tuvo, con la respuesta correcta definida por quien conoce el negocio. Es la parte aburrida y es la que determina si todo lo demás sirve.
• Cada incidente de producción se convierte en un caso de prueba. Es el bucle que la mayoría no cierra: el trace mostró la falla, la falla se corrigió, y el caso queda en la suite para que no regrese. Sin ese paso, la observabilidad solo genera anécdotas.
• LLM-as-judge para escalar, humano para lo delicado. La combinación que reporta la encuesta — 53.3% y 59.8% respectivamente — coincide con lo que funciona en la práctica: el juez automático cubre volumen sobre criterios objetivables (¿respetó el límite de autoridad?, ¿usó la herramienta correcta?), y el criterio humano se reserva para lo ambiguo.
• Evaluación online, no solo offline. Solo 25% de los equipos combina ambas, y es justo la combinación que detecta lo que el conjunto de prueba nunca anticipó, porque los usuarios reales hacen preguntas que nadie escribió en un dataset.

La conclusión incómoda

Cerrar el ciclo no es glamoroso: es curar datasets, escribir funciones evaluadoras, calibrar umbrales y mantener todo eso vigente conforme evolucionan el producto y los modelos por debajo. Es trabajo de ingeniería sostenido, y es exactamente el trabajo que separa un agente que sobrevivió la demo de uno que sobrevive el año.

Nuestra recomendación práctica, si ya tienes un agente en producción y estás en el 89% con observabilidad: no agregues otra herramienta de monitoreo. Toma los últimos treinta traces donde algo salió mal, conviértelos en casos de prueba con su respuesta esperada, y córrelos antes de cada despliegue. Ese ejercicio de una tarde te mueve del 89% al 52% del que sí mide — y es el cambio de mayor retorno que puedes hacerle hoy a un sistema agéntico.