Idempotencia, degradación y vigilancia: sobrevivir cuando el agente de IA se cae
Un ensayo de ingeniería sostiene que la capa que nadie mira, la que decide qué queda en pie cuando el modelo falla, es la que separa un sistema operativo de una caída silenciosa.
El sexto ensayo de la serie AI Harness Engineering, firmado por Derek Wang, mira a la capa que nadie presume: qué hace el sistema en el segundo en que la IA falla. Su tesis cabe en una línea: un sistema que se apaga en silencio es peor que uno que se apaga a gritos.
Los cinco niveles superiores de esa pirámide gobiernan lo que la IA produce. Este gobierna lo que sobrevive cuando no produce nada, y se reduce a cuatro verbos: repetir sin duplicar, degradar, hacerse visible y recuperarse rápido. El símil que usa es el de la aviación: un avión comercial vuela con dos motores no porque necesite ambos para mantenerse en el aire, sino porque la normativa le exige seguir subiendo, crucero y aterrizando con uno solo.
Para un agente, reintentar es el comportamiento por defecto: la red falla, no sabe si su última escritura llegó y dispara otra vez la misma petición. En un sistema con humanos un duplicado es una línea de log de más; con agentes es un segundo pedido, una segunda notificación, un segundo cargo. La prueba es una pregunta: manda la misma petición dos veces, ¿el sistema hizo el trabajo dos veces? El arreglo que el autor dice aplicar una y otra vez es sembrar los datos de prueba con upsert en lugar de IDs fijos, de modo que el reintento deje siempre la misma fila. Cuando quien llama no puede saber si su escritura cuajó, se le entrega una idempotencyKey y se devuelve el primer resultado para cada clave repetida.
La degradación cubre lo otro, los fallos parciales. En su sistema de trading, un FMEA avisó de que si el feed externo de tipos de cambio se caía, la función de cotización moría con él y el usuario veía errores crudos. La salida fue cachear la tasa y etiquetarla: con el feed vivo se sirve el dato en directo y se guarda copia; sin él, se sirve la copia avisando de que puede estar desactualizada. Los usuarios siguen cotizando a cambio de unos segundos de antigüedad. Una degradación que el usuario no ve es una degradación que no existe, porque aguas abajo se decide sobre datos malos sin que nadie se entere.
El silencio no dispara alertas
La visibilidad se paga con un incidente. En su enjambre multiagente murieron todos los workers a la vez: los scripts de arranque usaban set -e y, combinado con la contención de flock, la salida de uno envenenó el lock y los sucesores fallaron al bootear. Nadie gritó. La lección técnica es que un daemon existe para seguir vivo, no para ser estricto; la de fondo, que el silencio no activa ninguna alerta. Un watchdog que consulta la salud de los procesos cada cinco minutos y los relanza bajó la recuperación de treinta minutos a menos de cinco.
El último verbo es el intervalo entre la caída y la vuelta. Cuando el contenedor Docker de MySQL murió, el backend se vino abajo y aparecieron catorce archivos con errores de compilación en cadena: imports obsoletos, campos de DTO renombrados, beans @ConditionalOnProperty que dependían entre sí. Ninguno era difícil, pero recorrerlos a mano costó más de 45 minutos. Un pre-compile-check.sh que cubre las tres familias conocidas dejó la misma recuperación por debajo de 5. El cuello de botella casi nunca está en arreglar, sino en encontrar.
Las cifras son cicatrices del propio autor, no un benchmark de terceros: conviene leerlas como experiencia y no como medición. Lo generalizable es la pregunta. Si se monta algo encima de un modelo, importa menos qué hace cuando acierta que qué queda en pie, y quién se entera, cuando falla.
