Un agente de IA en producción, ráfagas de network_error en cadena y un mecanismo invisible: el cache de prefijo del proveedor moría en 2 minutos.
Este es un post-mortem real de producción, con la calibración medida en A/B y el resultado en el settings.yaml. El tipo de diagnóstico que solo existe cuando el harness es tuyo.
El síntoma: la cadena de retries
El cuadro inicial: ráfagas de network_error justo después de llamadas de lectura de imagen que devolvían archivos grandes. La herramienta demoraba, la llamada siguiente fallaba, el retry fallaba de nuevo, en cadena.
El instinto es culpar al gateway inestable. El instinto erra el blanco: la falla siguiente era consecuencia del intervalo anterior, no de la inestabilidad en sí.
El mecanismo: TTL de 2 minutos reventado
La investigación aisló el mecanismo: el cache de prefijo del proveedor expira con cerca de 2 minutos sin request. La herramienta larga (lectura de imagen grande) revientaba el TTL, el cache moría, y cada retry reenviaba el contexto entero: 40 mil tokens de texto más 1 MB de imágenes acumuladas.
Upload frío de ese tamaño sobre un gateway inestable es la ráfaga entera explicada. El nombre del mecanismo, invalidación de prefijo, es lo que convierte el resto en ingeniería común: con la causa nombrada, la corrección se vuelve clasificación de error más calibración medida.
La corrección, en dos frentes
En el código: los gateways sintetizan finish_reason, y esos errores entraban como falla fatal. Los remapeé como transporte recuperable, con suite de tests, y el trabajo se volvió branch de contribución para el mainstream del harness.
En la configuración: calibración medida en A/B, cada valor con racional registrado en el settings.yaml:
- Techo de 6 MiB por request de imagen: ráfagas 76% menores, pico 82% menor.
- Timeout de stream en 60 segundos, porque 30 inflaba repeticiones.
- 100 retries con backoff de 750 milisegundos, limitando el peor caso a menos de 2 horas.
Y la regla operacional que cierra el diseño: reventó el techo de retries, aborta y compacta el contexto. Resultado: 62 retries por día absorbidos automáticamente, cero turnos perdidos, con el modelo corriendo la ventana entera.
Por qué eso exige harness abierto
El mismo harness atiende la nube y mi propio data center (DGX H200 sirviendo GLM vía NIM), y el debug fue posible porque el harness es mío: bajar hasta el mecanismo de invalidación de prefijo y corregirlo con tests no cabería en un ticket de soporte.
Un harness cerrado convertiría ese diagnóstico en ticket sin plazo, y probablemente sin solución: el proveedor del cache no es el dueño del agente, y el dueño del agente no ve el TTL. Un harness abierto convierte diagnóstico en corrección con tests, y por eso la capa de orquestación propia vale su precio.
Conclusión
El mismo post-mortem enseña tres lecciones: el cache de prefijo es un recurso vivo que muere en el silencio entre llamadas; las fallas de transporte y las fallas fatales necesitan clasificación diferente; y la calibración sin A/B medido es adivinanza con archivo.
Quien corre agentes en producción va a encontrar este patrón (o su primo) tarde o temprano. La diferencia entre 2 horas de peor caso y un turno perdido es el harness que tú controlas. El modelo es commodity; la operación que lo sirve es el producto.