Diecinueve días seguidos sin perder una sola síntesis de conocimiento. Los health checks en verde. Los backups ejecutándose. Los tweets saliendo puntuales. Todo impecable.
Y sin embargo, cuatro semanas arrastrando el mismo bug.
El bug es ridículo: cuando el pipeline de ingesta procesa un artículo nuevo, los tags salen con doble bracket. [['agentes-ia', 'hermes']] en lugar de ['agentes-ia', 'hermes']. No rompe nada. No tira errores. No afecta a la web ni a nadie que lea. El nightly agent lo detecta y lo arregla en segundos. Trece veces. Mismo patrón. Misma corrección automática. Misma causa raíz sin identificar.
Y aquí es donde todo se tuerce.
Un agente que crashea es un regalo
Suena raro, pero es verdad. Un agente que crashea es ruidoso. Te llega una alerta, revisas, arreglas. El problema se vuelve visible.
Un agente que falla silenciosamente y se repara solo es mucho peor. Te crea una ilusión de salud que te anestesia. Los health checks pasan. El sistema "funciona". Y mientras tanto, el mismo error se repite una y otra y otra vez, compensado por otro agente que existe precisamente para taparlo.
Esto es lo que Addy Osmani llama "verification debt": el agente A produce basura, el agente B verifica y limpia, y tú ves verde en el dashboard y sigues con tu vida. Nadie se pregunta si el agente A debería estar produciendo algo distinto. Con 61 crons activos en mi Raspberry Pi, estoy justo en el punto donde este riesgo deja de ser teórico.
Lo que hice cuando me di cuenta
Dejé de mirar los health checks. Empecé a mirar el log de correcciones. ¿Qué está arreglando el sistema automáticamente? ¿Cada cuánto? ¿Siempre el mismo patrón? Los health checks te dicen si el paciente está vivo. El log de correcciones te dice si está enfermo.
Seguí la pista hasta la causa. El nightly agent arreglaba los tags y punto. Pero el problema venía de antes: el formatter que convierte feeds RSS a Markdown produce [['x']] en ciertas condiciones de nesting con namespaces XML no estándar. No lo vi durante semanas porque ningún health check miraba el output intermedio del pipeline. Solo el final.
Añadí un contador de repeticiones. Ahora, cuando el mismo patrón se corrige más de 3 veces, el sistema no solo arregla: emite una alerta. La diferencia entre auto-healing real y auto-engaño está en esa alerta.
Tres cosas que me habría gustado saber hace un mes
Un arreglo automático sin traza no es un arreglo. Es un parche invisible. Si tu agente corrige algo y no deja registro de qué corrigió, no sabes si está funcionando bien o compensando a otro agente roto. Exige que cada fix quede documentado: qué se arregló, por qué, y cuántas veces esta semana.
Cuenta las repeticiones o no verás los patrones. Un bug que aparece 13 veces en 4 semanas no es un incidente. Es un feature no declarado de tu pipeline. Si no llevas un contador, cada ocurrencia parece la primera.
El outer loop no se delega. Tus agentes pueden hacer el inner loop (detectar, arreglar, repetir) todo el día. Pero preguntarse "¿está el sistema haciendo lo correcto, o solo lo que le pedí?" es cosa tuya. Si delegas eso también, entras en lo que Osmani llama "cognitive surrender" — el sistema decide, tú asientes, y nadie está realmente al mando.
¿Está arreglado?
El bug de los double brackets tiene un edge case con feeds que usan namespaces XML raros. Estoy en ello. Pero lo importante no es el bug. Es el workflow.
Antes, el sistema se reparaba solo y yo ni me enteraba. Ahora sé exactamente dónde ocurre, cuándo, y recibo una alerta si se repite más de 3 veces. El verdadero arreglo no fue una línea de código. Fue dejar de confundir "se repara solo" con "funciona bien". No es lo mismo.
Si estás construyendo agentes autónomos, mírate el log de correcciones automáticas esta noche. A lo mejor descubres que tu sistema lleva semanas enfermo mientras el dashboard te sonreía en verde.