El cold start importa menos que el time-to-first-useful-action: la latencia agentic debe medirse donde el usuario percibe progreso

Dos segundos de infraestructura no equivalen a una respuesta de dos segundos. AWS publicó mejoras importantes de cold start, pero el propio diseño de agentes contiene otras esperas: selección de modelo, reasoning, búsqueda, conexión a herramientas, serialización y validación. Para una persona, lo que importa no es cuándo la microVM quedó lista, sino cuándo el sistema muestra progreso creíble o completa la primera parte útil del trabajo. Esto sugiere una taxonomía más rica de latencia. Sin ella, un equipo puede celebrar una mejora de plataforma que apenas cambia la experiencia porque el cuello de botella vive en otra etapa.

El primer KPI debería ser timetofirstusefulaction. No es lo mismo que primer token. Un agente puede escribir “estoy trabajando” inmediatamente y tardar un minuto en hacer algo. Una acción útil puede ser cargar el archivo correcto, confirmar el alcance, recuperar un dato o completar una consulta verificable. Definir ese evento obliga a producto e ingeniería a acordar qué progreso tiene valor. En algunos workflows, una vista parcial sirve; en otros, mostrar resultados incompletos confunde. La métrica depende de la naturaleza de la tarea y debe existir junto al tiempo total.

La sesión puede calentarse antes de que llegue la solicitud final. AWS sugiere iniciar un entorno cuando el usuario entra en la experiencia, de modo que la infraestructura se prepare mientras lee o escribe. Ese patrón puede funcionar si el costo y la privacidad están controlados. No conviene abrir recursos caros para cada visita casual. El sistema puede usar señales de intención y perfiles históricos para decidir cuándo prewarm. También necesita cerrar rápidamente sesiones abandonadas. Optimizar latencia sin lifecycle crea exactamente el tipo de gasto invisible que una plataforma agentic debería evitar.

La latencia también tiene una distribución, no un promedio. Una experiencia que normalmente tarda tres segundos pero algunas veces tarda cuarenta puede sentirse menos confiable que otra estable en seis. Por eso P50, P75, P95 y P99 cuentan historias distintas. Los agentes añaden variabilidad por herramientas externas y modelos. Un dashboard debería descomponer cada run por fase y mostrar qué componente explica la cola larga. Cuando un proveedor mejora cold start, es posible verificar si baja realmente el P95 del workflow completo o si solo mueve unos segundos en casos que nunca eran el problema principal.

La interfaz puede convertir espera en progreso sin mentir. Mientras una tarea larga avanza, estados estructurados como “archivo validado”, “fuente consultada” o “borrador listo para revisar” reducen incertidumbre. No se trata de animaciones vacías. Cada estado debe corresponder a un checkpoint real del runtime. Esa visibilidad permite que la persona interrumpa si detecta un error antes del final. También crea telemetría de producto: podemos ver en qué fase abandona la gente y qué parte merece optimización. La mejor experiencia no oculta latencia; la hace comprensible y controlable.

Implicación para Goatify. Deberíamos medir startuplatency, firstusefulaction, checkpointlatency y totaltime por habilidad. El router puede elegir runtime y modelo según el SLO del caso: un agente de atención prioriza reacción rápida; una auditoría nocturna prioriza costo y completitud. Con datos reales, podemos decidir cuándo prewarm y cuándo dejar escalar a cero. Así evitamos vender velocidad con una cifra aislada. Vendemos una experiencia donde cada segundo está conectado con un progreso observable y un costo que la empresa entiende. Además, podemos comparar versiones de una habilidad sin confundir una respuesta temprana con un trabajo realmente adelantado, y priorizar optimizaciones donde el usuario siente la espera.