Lo caro de correr agentes nunca es lo que te molesta
Si corrés agentes de código a diario ya tenés una intuición sobre dónde se te va la plata. Probablemente apunte al reintento: ese momento en que el trabajo no pasa el control, vuelve a empezar, y lo ves en pantalla rehaciendo algo que ya había hecho.
Yo tenía esa intuición y escribí un plan de optimización de cinco puntos basado en ella. Después fui a la base de datos a buscar el número contra el cual iba a medir la mejora, y encontré que el reintento se había disparado una sola vez en toda la historia del sistema.
El gasto estaba en un paso que nunca me había irritado, precisamente porque funcionaba bien: la verificación previa a cerrar cada tarea, que se llevó 3.463 de los 11.968 dólares que gastó el sistema en total. Un 29% de la factura concentrado en el paso más aburrido.
La trampa se generaliza a cualquier cosa que automatices con modelos: lo que molesta son las excepciones, porque interrumpen; lo caro es la rutina, porque se multiplica. Sin telemetría por paso, optimizás lo que te irrita en lugar de lo que te cuesta.
El sospechoso obvio
Los cinco puntos del plan apuntaban al mismo lado: el ciclo de reintentos.
El razonamiento era sólido. Cuando un trabajo no pasa el control de calidad y hay que reintentarlo, se paga todo de nuevo: otro agente levantado, otra exploración del código, otra implementación, otro control. Es, con diferencia, la operación más cara del sistema. Y encima estaba mal implementada: descartaba la sesión anterior, así que el segundo intento arrancaba sin memoria del primero.
Todo eso era cierto. Los cinco puntos del diagnóstico estaban bien identificados. El plan arrancaba por hacer el reintento más inteligente y seguía con optimizaciones menores.
Después fui a la base de datos a buscar el número de base contra el cual iba a medir la mejora.
Lo que decían los datos
Encontré tres cosas que no encajaban con nada de lo que había escrito:
- Un solo item, en toda la historia del sistema, había llegado a generar retroalimentación de reintento.
- Cero abandonos. La rendición, que estaba cuidadosamente diseñada con su reporte estructurado de incidentes, nunca se había disparado.
- La tasa de aprobación en el primer intento era prácticamente del 100%.
El ciclo de reintentos que estaba por optimizar casi no corría. Había escrito un plan de mejoras para el camino menos transitado del sistema.
La explicación, cuando la busqué, tenía sentido: los errores no se estaban corrigiendo entre pasos del orquestador. Se corregían dentro del loop interno de cada agente, antes de que el trabajo llegara al control de calidad. El agente iteraba sobre su propio trabajo, se daba cuenta de sus errores y los arreglaba antes de entregar. Para el orquestador, eso es invisible: solo ve un paso que terminó bien.
Es decir, mi intuición no solo estaba equivocada sobre el tamaño del problema. Estaba mirando una capa del sistema donde el problema, sencillamente, no ocurría.
El número que reordenó el plan
En la misma consulta apareció el dato que cambió todo. El control de calidad —el paso que verifica cada tarea antes de cerrarla— corría unas 157 veces por semana, con un promedio de 5 a 8 minutos cada vez.
Ese era el costo dominante. No los reintentos, que casi no pasaban: la verificación, que pasaba siempre.
Y el dato aguantó el paso del tiempo. Hoy, mirando el acumulado, el control de calidad se llevó 3.463 dólares de los 11.968 que gastó el sistema en total. Un 29% de la factura concentrado en un solo paso.
El plan se reescribió esa misma tarde. Primero, paralelizar el control y cachear la suite de tests. El trabajo sobre los reintentos quedó relegado a mejora barata de robustez, para cuando el caso peor efectivamente ocurra.
Por qué la intuición apuntaba al lado equivocado
Estuve pensando bastante en por qué me había equivocado tan claramente, porque el error no fue de análisis: fue de percepción.
El reintento duele. Se ve en la pantalla, aparece como un ciclo que se repite, se siente como desperdicio mientras ocurre. Es visible, ruidoso y frustrante.
El control de calidad no dolía porque era rutina. Corría siempre, formaba parte del funcionamiento normal, y por eso mismo era invisible. Nadie mira dos veces un paso que hace lo que tiene que hacer.
Por eso la percepción se invierte respecto del gasto: la excepción ocupa toda la atención mientras ocurre y no aparece en la factura; la rutina no ocupa ninguna y es la factura entera.
Un detalle sobre cómo dejé escrito el error
Cuando reescribí el plan, no borré el diagnóstico original. Le agregué arriba una nota fechada con la recalibración: qué había creído, qué mostraron los datos y cómo cambiaba la prioridad.
Podría haber reescrito el documento y dejarlo prolijo, con el diagnóstico correcto desde el principio. No lo hice por una razón práctica: el diagnóstico equivocado sigue teniendo valor. Explica por qué el sistema está construido como está, y me recuerda que el razonamiento que lo produjo era razonable — leyendo el código, cualquiera habría llegado a la misma conclusión.
Un plan que oculta sus propios errores de diagnóstico se vuelve un documento de marketing interno. Uno que los deja a la vista, con la fecha, es un registro de cómo se aprendió algo.
Por dónde empezar en tu sistema
El orden no se adivina, se consulta. Antes de escribir un plan de optimización, armá la lista de los pasos de tu pipeline con dos columnas —lo que cuesta cada corrida y cuántas veces corre por semana— y ordenala por el producto de las dos. La frecuencia es la que sorprende, casi nunca el costo unitario: el paso carísimo que corre una vez por mes no es tu problema.
La primera tarea del plan reordenado sonaba trivial: dejar de correr la suite completa cuando el código no había cambiado. Tenía una trampa que casi me hace certificar como aprobado un código que nunca se probó, y de eso trata la próxima entrega.