Cuando empecé con agentes IA en Hermes, mi foco estaba en el modelo. Probar DeepSeek V4, compararlo con GPT-5.6, ajustar prompts. El problema es que mis agentes seguían fallando igual, sin importar qué modelo usara.
El dato que me hizo click: el 88% de los agentes fallan en producción. No por mal prompting. No por modelos débiles. Porque no tienen harness.
Mitchell Hashimoto —el fundador de HashiCorp— lo explicó mejor que nadie: Agent = Model + Harness. El harness es todo lo que atrapa, corrige y recompensa al agente durante cada acción. Si no existe, tu agente es solo un LLM suelto haciendo lo que quiere.
Después de dos meses con 58 agentes corriendo 24/7 en una Raspberry Pi 5, esto es lo que funciona.
Lo que no funciona: tirarle modelos mejores al problema
Probé de todo. DeepSeek Flash, DeepSeek Pro, Claude Opus 5, GPT-5.6 Sol. Los agentes con mejor modelo fallaban igual, solo que más caro. Un loop infinito en DeepSeek Flash cuesta $0.02. En GPT-5.6 cuesta $0.80. El resultado es el mismo: basura.
El modelo no es el cuello de botella. La mayoría de fallos que vi no eran de "el modelo no entendió la tarea". Eran de "el modelo corrió 47 veces el mismo tool call, nadie lo paró, y cuando me di cuenta ya gasté $3".
Las tres capas del harness que sí funcionan
1. Validadores por iteración
Cada vez que tu agente ejecuta un tool call, algo debería revisar si tiene sentido. No es complejo: tres reglas simples atrapan el 90% de los fallos.
- Tres tool calls idénticos seguidos → loop detectado, matar y reintentar con enfoque distinto.
- Tokens de incertidumbre crecientes ("quizás", "no estoy seguro", "tal vez si...") → el modelo está confundido, resumir contexto.
- Métrica de progreso estancada por 5+ iteraciones → el agente está muerto en vida, forzar cambio de estrategia.
Implementé esto en 40 líneas de Python. Sin LangGraph, sin Temporal, sin infraestructura extra. Tres if statements que corren después de cada tool call.
2. Circuit breakers
Un circuit breaker es simple: si algo falla N veces en un período, dejás de intentarlo. En agentes IA esto es crítico porque los modelos no tienen noción de "ya intenté esto 15 veces, quizás debería parar".
Mi regla: 3 fallos del mismo tipo en 60 segundos → circuit breaker, notificar por Telegram, pasar al siguiente cron. El agente no decide si reintentar. El harness decide.
Esto solo me ahorró $12 este mes. Suena a poco, pero son 12 dólares que antes se quemaban en loops de reintentos contra APIs caídas.
3. Context compression adaptativo
Los agentes acumulan contexto. Cada iteración añade tool calls, resultados, razonamientos. Eventualmente el contexto es tan grande que el modelo se pierde, o peor, el costo por iteración se dispara.
La mayoría de frameworks resumen por token count: "cuando llegues a 100K tokens, comprimir". Esto es torpe. El problema no es el tamaño del contexto, es que el contexto se volvió ruido.
Lo que hago es comprimir solo cuando detecto degradación: tool calls repetidos, confusión creciente, progreso estancado. Si el agente está funcionando bien con 150K tokens, no toco nada. Si empieza a fallar con 60K, comprimo.
Tres errores que cometí para que vos no los cometas
Error 1: timeouts globales. Puse un timeout de 10 minutos para todos los agentes. Un agente de backup tardaba 12 minutos comprimiendo archivos. Lo mataba a los 10, perdía el trabajo, y volvía a empezar al día siguiente. Timeouts por tarea, no globales.
Error 2: límites de iteración arbitrarios. "Máximo 20 tool calls". Un agente de research legítimo necesita 40 búsquedas para un tema complejo. Lo mataba a las 20 y perdía investigación válida. Si ponés límites, que sean por progreso, no por conteo ciego.
Error 3: no tener un "modo degradado". Cuando un agente falla, no siempre necesitás reintentar todo. A veces alcanza con que entregue lo que tiene. Mis agentes ahora tienen tres modos: normal, degradado (entrega parcial), y muerto (notifica y sigue).
Lo que Addy Osmani llama "las tres deudas"
Addy Osmani —engineering lead de Chrome— acuñó el concepto de Loop Engineering y describe tres deudas que todo builder de agentes acumula sin darse cuenta:
- Deuda de verificación: el agente produce output, pero nadie verifica si es correcto. Se acumula silenciosamente. Un validador post-ejecución —aunque sea un simple diff contra el output esperado— la reduce drásticamente.
- Deuda de comprensión: el sistema crece, añadís agentes, crons, skills. En tres meses no entendés cómo funciona nada. Documentar no alcanza. Hacé que cada agente loguee su razonamiento en una línea. Cuando algo falla, sabés por dónde empezar.
- Rendición cognitiva: delegás tanto en los agentes que perdés criterio propio. Si no podés explicar por qué tu agente tomó una decisión, delegaste de más. El outer loop —verificar, decidir si publicar o bloquear— tiene que ser humano.
Lo más importante: el harness no tiene que ser complejo
Cuando empecé a leer sobre esto, todo sonaba a infraestructura pesada. Temporal, LangGraph, supervisores jerárquicos estilo Erlang, checkpoints distribuidos. Me abrumó.
Hoy mi harness son 200 líneas de Python. Tres validadores, un circuit breaker, compresión de contexto condicional y notificaciones por Telegram. Eso es todo.
No necesitás Kubernetes. No necesitás LangGraph. Empezá con tres if statements que corran después de cada tool call. Cuando eso funcione, agregá el circuit breaker. Después la compresión. Construilo de a poco mientras ves qué falla en producción.
Los agentes no fallan por el modelo. Fallan porque los soltás sin nada que los atrape.