Agentes que se reparan solos: 24 errores que mi sistema de IA aprendió a arreglar sin mí

Tengo 58 cron jobs corriendo en una Raspberry Pi 5. Agentes de IA que publican artículos, vigilan la salud del sistema, sincronizan mi segundo cerebro en Obsidian y monitorean el SEO del sitio. Todo automático. Todo sin intervención humana.

El problema es que los agentes fallan. Y cuando tienes 58 procesos autónomos, los errores se acumulan rápido.

En las últimas dos semanas documenté 24 patrones de error distintos y construí un sistema de auto-reparación que los detecta y los arregla solo. Esto es lo que aprendí.

El problema no es el error, es el error silencioso

El peor fallo que tuve fue un cron que seguía ejecutándose cada 2 horas durante 152 ciclos. Lo había pausado internamente en el state.json del loop. Pero el cron job externo seguía lanzándolo. Tres semanas después me di cuenta.

Ese patrón ahora está documentado como loop_thrashing_permanent_fix y la regla es simple: pausar un loop internamente no basta. Tienes que eliminar el cron job externo Y comentarlo en loops.yaml Y quitarlo de chains.yaml. Los tres pasos o nada.

La parte más frustrante no fue el bug. Fue no haberme dado cuenta durante 152 ejecuciones. Los errores silenciosos son los que realmente destruyen un sistema autónomo.

La jerarquía de fallos que encontré

Después de dos semanas registrando cada fallo, los errores cayeron en tres categorías. No las inventé — salieron solas de mirar logs a las 2 de la mañana.

Nivel 1 — Infraestructura (los más frecuentes)

Errores 500 del upstream del proveedor LLM, rate limits 429, módulos Python que faltan, scripts que no existen. Son fáciles de detectar pero si no los atrapas rápido tienes 58 crons fallando en cadena.

Mi solución: cuando un cron devuelve 500 tres veces seguidas, lo convierto automáticamente a no_agent — sin LLM, solo script. No es elegante pero evita que el sistema entero se degrade por un proveedor caído.

El otro día DeepSeek sacó V4 Flash 0731. El modelo mejoró un 45% en benchmarks de terminal. Pero durante el rollout sus APIs devolvieron 500s intermitentes. Los crons que estaban en modo no_agent ni se enteraron.

Nivel 2 — Lógica (los más interesantes)

Bucles infinitos, tool calls repetidos, contexto saturado, estancamiento. Estos son los que queman tokens sin producir nada.

Documenté tres señales para detectar un agente atascado:

• 3 o más tool calls idénticos consecutivos → está en un loop
• Frases de incertidumbre crecientes ("no estoy seguro", "podría", "quizás") → confusión progresiva
• Métricas de progreso estancadas más de 3 ciclos → necesita intervención

Cuando se detecta, el sistema aborta el ciclo actual, inyecta "estás en un loop, probá otro approach" y reintenta. Si falla dos veces, pausa el cron y me notifica por Telegram.

Nivel 3 — Contratos y verificación (los más traicioneros)

Aquí están los bugs que no rompen nada pero producen datos incorrectos durante semanas. El más reciente: un script de verificación de memoria reportaba FAIL porque el límite estaba calibrado a 2,200 caracteres y la memoria del sistema había crecido a 2,356. El contenido era correcto — solo 13 líneas con config esencial. El límite era el problema, no la memoria.

El fix fue trasparente: MEM_LIMIT = 2200 → 4000. Pero sin el sistema de auto-reparación ese falso positivo habría estado ahí semanas, contaminando métricas y disparando alertas falsas.

Otro caso: un script verificador buscaba crons con la palabra "gsc" en el nombre. Pero el monitoreo real de Google Search Console lo hacía un cron llamado "seo-monitor-loop". El verificador reportaba FAIL durante días porque su búsqueda era demasiado estrecha.

Lo que NO hago: tirarle un LLM a todo

De mis 58 crons, 27 van sin LLM. Cero tokens. Cero alucinaciones. Bash puro.

Un curl para verificar que la web responde no necesita un modelo de lenguaje. Un df -h para monitorear disco no necesita razonamiento. Cada vez que alguien le pone un LLM a un cron de infraestructura básica está quemando tokens para absolutamente nada.

Los otros 31 crons usan DeepSeek Flash para tareas ligeras y Pro para análisis complejo. El routing es automático: si la tarea históricamente usa menos de 3 tool calls, va por Flash. Si es investigación o decisión, va por Pro.

El costo real de todo esto

58 crons, 24 patrones de error documentados, auto-reparación, loops de verificación, notificaciones por Telegram. Todo corre en una Raspberry Pi 5 de 8GB que consume 12-15 vatios.

Costo mensual en APIs: unos $5 en DeepSeek.

Costo anual de electricidad: unos 16-20 euros.

El costo real no está en la infraestructura. Está en los errores que no ves. Un loop infinito que no detectas te puede quemar $3 en una noche. Con 58 crons, si no tienes auto-reparación, el riesgo de burning silencioso es real.

Tres cosas que haría distinto si empezara de cero

1. Checkpointing desde el día uno. Los crons de más de 10 pasos deberían guardar progreso incremental. Si fallan en el paso 8, retoman desde el paso 7, no desde cero. Implementé esto después de ver crons de 15 minutos repetir los primeros 12 pasos tres veces porque el paso 13 fallaba.

2. Un solo archivo de patrones de error. Mi auto_healing_patterns.json empezó como notas sueltas en Markdown. Cuando vi el patrón 15, migré todo a JSON estructurado con error_type, detection y fix para cada entrada. Ahora cuando aparece un error nuevo, el sistema busca en el JSON antes de intentar cualquier cosa. Si el patrón existe, aplica el fix documentado. Si no, escala.

3. Modo degradado en vez de fallo total. Muchos de mis crons son pipelines: trend detection → research → draft → humanize → validate → publish. Si falla el paso de humanize, no necesito abortar todo. El artículo se publica sin humanizar y una nota queda en el log. Al día siguiente se reprocesa. Degradación graceful, no fallo binario.

El JSON que crece solo

Mi auto_healing_patterns.json tiene 24 entradas hasta hoy. Cada vez que un cron falla de una forma nueva, el sistema registra el error, yo documento el patrón, y la próxima vez se arregla solo.

Algunos ejemplos de lo que hay adentro:

• stale_error_on_paused_job — un cron pausado seguía reportando error porque su last_status nunca se limpió
• consolidated_loop_still_referenced — un script unificado seguía llamando loops que ya estaban comentados en loops.yaml
• missing_cron_for_loop — un loop existía en loops.yaml pero nadie creó el cron job para ejecutarlo. Estuvo 22 días sin correr
• verify_script_naming_match_too_narrow — el verificador buscaba "gsc" en nombres de cron pero el cron real se llamaba "seo-monitor"

Cada entrada incluye el patrón de detección, el fix exacto y un ejemplo real de cuando ocurrió. No es documentación teórica — es un historial de cicatrices.

Después de 24 patrones, los errores nuevos son cada vez más raros. Y los viejos ya se arreglan solos.