Tengo 58 cron jobs corriendo en Hermes ahora mismo. Algunos publican artículos en esta web. Otros sincronizan mi segundo cerebro entre el móvil y el servidor. Unos cuantos existen solo para vigilar que los demás no fallen. Durante semanas creí que todo funcionaba perfecto.
No era verdad. Para nada.
El problema no fue un crash espectacular con logs en rojo y alarmas sonando. Fue algo mucho peor: degradación silenciosa. Agentes que técnicamente terminaban sin error pero producían basura. Costes que se disparaban centavo a centavo sin que nadie lo notara. Y yo, convencido de que mis health checks me estaban protegiendo.
El día que revisé los logs
El 24 de julio, más por aburrimiento que por sospecha, me puse a revisar los logs de las últimas 72 horas. Tres cosas me saltaron a la cara en los primeros cinco minutos:
1. El agente de sync del vault llevaba 4 ejecuciones consecutivas haciendo exactamente la misma consulta SQL. No fallaba técnicamente — el código de salida era 0. Tampoco producía nada útil. Simplemente se había quedado atascado en un bucle donde cada iteración era idéntica a la anterior. Cuatro horas de cómputo tiradas a la basura.
2. El pipeline de imágenes llevaba tres días generando placeholders en vez de imágenes reales. El script de Replicate SDXL había dejado de responder por un cambio en la API, y el fallback a Picsum funcionaba... pero con seeds repetidos. Tres artículos publicados con la misma imagen genérica de montañas. Nadie se quejó porque, bueno, soy yo el único que revisa esto a fondo.
3. El consumo de tokens del agente de análisis había subido un 340% en una semana. Cada iteración añadía el contexto de la anterior al prompt. El modelo, en vez de responder sobre la última consulta, lo hacía sobre TODA la historia acumulada. Los tokens crecían cuadráticamente. Mi factura de DeepSeek, también.
Lo que más me dolió: los health checks seguían dando verde en los tres casos. Porque mis health checks solo verificaban una cosa: ¿terminó el proceso sin error? Código de salida 0 = todo bien. Y eso, como acabo de descubrir, no significa absolutamente nada.
Las tres deudas del loop engineering
Addy Osmani publicó en junio un artículo sobre "Loop Engineering" — la disciplina de diseñar sistemas de agentes que no se autodestruyen con el tiempo. Identifica tres deudas que se acumulan en cualquier sistema con agentes autónomos:
Verification debt: el agente produce outputs, pero nadie verifica que sean correctos. El sistema "funciona" mientras no crashee, aunque esté generando basura.
Comprehension debt: el sistema crece tanto en complejidad que se vuelve inentendible. Sabes que hay 58 crons, pero no sabes qué hace exactamente cada uno ni cómo interactúan.
Cognitive surrender: delegás tanto en los agentes que perdés el criterio para juzgar si lo que producen tiene sentido.
Las tres me aplicaban. Las tres me estaban costando dinero y calidad sin que yo lo supiera.
Cómo lo arreglé en un fin de semana
1. Stuck detection (detección de bucle)
La regla es ridículamente simple: si un agente repite el mismo tool call tres veces seguidas, está atascado. No importa si cada llamada individual "sale bien". Si el sistema está haciendo exactamente lo mismo sin progreso real, necesito intervenir.
Implementé esto con un contador por agente. Si detecta tres o más llamadas idénticas consecutivas, el agente se para, registra el fallo, y manda una notificación. El costo de implementación fueron 20 líneas de Python. El beneficio: atrapó al agente del vault la primera noche que lo activé.
2. Token budget por agente
El problema con los costes en agentes no es el costo por llamada individual. Es el costo acumulado del contexto que crece. Cada iteración de un agente mete el historial completo en el prompt, y el modelo responde sobre TODO ese contexto. Los tokens crecen cuadráticamente si no hacés nada al respecto.
Puse un budget diario por agente y una regla clara: si el promedio de tokens por iteración crece más de un 50% respecto a la línea base, el agente se pausa y notifica. También implementé compresión de contexto: cada 5 iteraciones, resumo el historial en 200 tokens en vez de pasar los 2000 tokens completos.
El resultado: de $5.40 estimados al mes a $3.80 reales. Y lo importante no son los $1.60 de ahorro. Es que ahora sé exactamente cuánto cuesta cada cron individual. Antes tenía una cifra global. Ahora tengo un desglose.
3. Semantic output validation
Los health checks binarios (¿código de salida 0? sí/no) no sirven para agentes. Lo que necesito es validar que la salida tenga sentido semántico.
Para los artículos: ¿el texto tiene al menos 500 palabras? ¿Los placeholders de imágenes se reemplazaron por URLs reales? ¿El título no es idéntico a un artículo ya publicado?
Para los syncs de vault: ¿el número de notas procesadas es razonable (más de 0, menos de 1000)? ¿Los links internos extraídos no son solo autoreferencias circulares?
Son checks absurdamente simples. Ninguno requiere un LLM. Ninguno usa machine learning. Pero atraparon el 100% de las fallas silenciosas que habían pasado mis health checks anteriores. El 100%.
El outer loop: lo que ningún agente puede hacer por sí mismo
Osmani lo explica con una distinción que me quedó grabada: el agente corre el "inner loop" (investigar → implementar → verificar → repetir). El humano es dueño del "outer loop": verificar calidad, decidir si shippear o bloquear, mantener el accountability.
Mis 58 crons ahora tienen tres capas:
- Ejecución: el cron hace su trabajo
- Validación: los checks semánticos verifican que la salida tenga sentido
- Supervisión: yo reviso el dashboard una vez al día, tomo decisiones sobre lo que los agentes no pueden decidir solos
No es perfecto. Sigo encontrando edge cases. Pero ya no estoy volando a ciegas.
Si estás construyendo agentes, empezá por acá
No te obsesiones con el modelo más nuevo o el framework más elegante. Las tres cosas que marcaron la diferencia en mi sistema no requirieron nada de eso:
- Detección de bucles: 20 líneas de Python
- Token budget: 30 líneas de Python
- Validación semántica: 50 líneas de Python
100 líneas en total. Cero dependencias nuevas. Cero APIs adicionales. Y el impacto fue inmediato.
La lección más importante que saqué de todo esto: si tu health check solo pregunta "¿terminó sin error?", no estás monitoreando nada. Estás rezando.