La latencia de un agente se mide hasta la decisión útil, no hasta la primera respuesta

La métrica heredada queda corta. En software interactivo aprendimos a mirar tiempos de respuesta porque una espera visible deteriora la experiencia. En agentes, esa medida sigue importando, pero puede esconder el costo principal. Un sistema puede responder en segundos y necesitar quince minutos de coordinación adicional para terminar la tarea. Otro puede tardar más en el primer paso y entregar un resultado listo para usar. Comparar únicamente latencia del modelo favorece la velocidad de conversación, no necesariamente la velocidad de trabajo. La métrica debería seguir el recorrido completo hasta una decisión o artefacto verificable.

El tiempo del usuario es parte del sistema. Si una persona debe copiar información entre aplicaciones, explicar de nuevo lo que ya dijo o revisar diez archivos para encontrar cuál es definitivo, ese esfuerzo pertenece al costo de la automatización. No desaparece porque ocurra fuera del modelo. Una evaluación seria puede registrar minutos de atención humana, número de interrupciones y cantidad de decisiones que el agente devolvió sin contexto suficiente. Este enfoque evita celebrar una tarea «automática» que en realidad requiere vigilancia constante y múltiples correcciones manuales.

La primera respuesta puede ser solo un checkpoint. En trabajos largos, una interacción temprana puede tener valor aunque no sea el resultado final: confirmar alcance, señalar información faltante o mostrar un plan. El error aparece cuando el producto trata ese momento como éxito. Conviene diferenciar tiempo hasta primera señal útil, tiempo hasta primera propuesta y tiempo hasta cierre verificado. Cada métrica responde una pregunta distinta. El usuario puede tolerar una ejecución larga si recibe señales confiables de progreso y sabe cuándo realmente necesita intervenir.

Las herramientas introducen colas invisibles. Navegar, descargar, subir, esperar una API o ejecutar código puede dominar el tiempo total. Optimizar el modelo no cambia necesariamente esas fases. Un equipo debería instrumentar cada etapa y observar dónde se acumula espera. Tal vez la mejora más valiosa sea paralelizar búsquedas, reutilizar un archivo ya validado o eliminar una comprobación redundante. El análisis de rendimiento se vuelve entonces un problema de sistema distribuido, no una competencia por milisegundos de inferencia.

La velocidad sin verificación crea deuda. Un agente puede parecer rápido si declara éxito inmediatamente después de llamar una herramienta, pero la organización paga después cuando descubre que el archivo no cambió o el correo no salió. Añadir una lectura posterior aumenta algunos segundos y reduce incidentes. Por eso conviene medir latencia hasta estado verificado. La verificación no es una penalización externa: forma parte de la entrega. Una métrica que termina antes de comprobar el efecto incentiva precisamente comportamientos que deterioran confiabilidad.

Los percentiles importan más que el promedio. Una automatización que normalmente termina en dos minutos y una vez al día tarda cuarenta puede causar más problemas que otra ligeramente más lenta pero estable. Observar p50, p95 y fallos de larga cola revela experiencias que el promedio esconde. También conviene separar tareas terminadas de abandonadas. Si los casos difíciles desaparecen de la estadística porque el usuario intervino, el sistema parece mejor de lo que es. El rendimiento debe incluir la distribución completa de resultados y escalaciones.

Una métrica práctica. Proponemos medir «tiempo hasta salida verificable» junto con minutos de atención humana y tasa de reanudación exitosa. Esa combinación muestra si el agente acelera trabajo, si exige demasiada supervisión y si puede recuperarse sin repetir todo. Para Goatify, esto permitiría comparar versiones de una habilidad con una pregunta empresarial clara: ¿el cliente llega antes a un resultado utilizable con menos coordinación? Si la respuesta es sí, la mejora importa aunque el modelo interno tarde algunos segundos adicionales.