Agentes long-horizon: por qué se pierden en tareas largas

Lanzas un agente para una refactorización de varias horas. Vuelves después de comer y encuentras un desastre: tres archivos a medias, tests que ya no compilan y un commit con el mensaje "fix". No es que el modelo sea malo. Es que nadie diseñó el flujo para que aguante esa distancia.

TL;DR: qué son los agentes long-horizon y por qué fallan

• Qué es: un agente long-horizon es el que ejecuta tareas autónomas de minutos a horas (no una respuesta de un solo turno). Pensá en un coding agent que planifica, escribe, prueba y corrige sin que le aprietes Enter en cada paso.
• Por qué importa: los agentes descarrilan en tareas largas por dos causas combinadas, context rot (el contexto se llena de ruido y la calidad cae) y compounding error (el error se multiplica paso a paso). Un error temprano contamina todo lo que viene después.
• Qué aprenderás: los cinco mecanismos que sostienen una tarea larga, trocear con spec, checkpoints verificables, aislamiento con git worktrees, verificación continua y un log de evidencia para retomar sin empezar de cero.

El problema: el agente no se rompe en el paso 20

METR publicó en marzo de 2025 una especie de "ley de Moore para agentes": la duración de las tareas que un modelo completa de forma autónoma se duplica cada siete meses aproximadamente. La capacidad sube, pero la fiabilidad por paso no acompaña al mismo ritmo. Y ahí está la trampa.

La matemática es brutal en su simpleza. Si cada paso acierta con probabilidad p y la tarea tiene n pasos, la probabilidad de éxito total es p elevado a n. Con un agente que acierta el 95% de las veces en cada paso (p = 0,95) y una tarea de 20 pasos, el éxito completo cae a 0,95²⁰ ≈ 0,36. Es decir, un 64% de fallo en algo que parecía casi perfecto por paso.

El agente no se descarrila "en el paso 20". Se descarrila en el 3, nadie lo verifica, y los 17 pasos siguientes construyen sobre arena. Por eso un horizonte largo sin guardarraíles es un multiplicador de errores, no de productividad.

¿Qué es un agente long-horizon?

Un agente long-horizon es un sistema basado en LLM que descompone un objetivo en muchos pasos y los ejecuta de forma autónoma durante un periodo largo, manteniendo estado, usando herramientas y verificando su propio progreso. La diferencia con un chatbot no es la inteligencia del modelo, es el harness: la infraestructura que lo mantiene honesto.

Esta distinción confunde a quien empieza: un context window grande no convierte a un agente en long-horizon. La ventana es memoria de trabajo de una sesión, no garantía de que el agente no se pierda. De hecho, llenarla del todo suele empeorar las cosas. Si querés profundizar en cómo guardar estado entre sesiones, lo cubrí en cómo dar memoria a tu agente sin inflar el contexto.

¿Qué es el context rot?

El context rot es la degradación gradual de la calidad de salida de un agente a medida que la ventana de contexto acumula historial: instrucciones viejas, intentos fallidos, payloads enormes de herramientas y requisitos mezclados. No hace falta llenar la ventana del todo. Unos cuantos turnos bastan para que el agente olvide que le dijiste "no hagas commit automático" o repita un fix que ya falló.

Los 5 mecanismos que sostienen una tarea larga

La conclusión primero: no se gana autonomía dándole más libertad al agente, se gana troceando, aislando y verificando. Estos son los cinco mecanismos, ordenados por impacto.

Mecanismo	Qué resuelve	Coste de implementarlo
Spec + plan troceado	Mantiene el objetivo largo sin saturar cada paso	Bajo (un archivo)
Checkpoints verificables	Detecta el error en el paso 3, no en el 20	Bajo
Aislamiento (git worktrees)	Un agente no pisa el trabajo de otro	Medio
Verificación continua	Tests/lint/build como juez objetivo por paso	Medio
Log de evidencia	Retomar desde un checkpoint, no desde cero	Bajo

1. Trocear con un spec, no con un prompt gigante

El patrón que funciona en runs largos es separar el "qué" del "cómo paso a paso". Un archivo de spec lleva la intención de largo alcance (criterios de éxito, restricciones) y un plan trocea el trabajo en unidades que se implementan y prueban de forma aislada. OpenAI describió esto en su run de Codex de 25 horas: un spec.md con el objetivo, un plans.md con milestones y criterios de aceptación, y un runbook de cómo debe operar el agente.

El spec sobrevive a cada paso; el contexto de cada tarea individual se mantiene pequeño. Ese es el truco para no inflar la ventana.

2. Checkpoints verificables después de cada milestone

Un checkpoint no es "guardar progreso". Es un punto donde una verificación objetiva decide si el agente sigue o retrocede. Aquí un harness mínimo y funcional en Python que ejecuta pasos, verifica cada uno y guarda estado para poder retomar:

# Harness minimo: ejecuta pasos, verifica cada uno y guarda estado para retomar
import json
import subprocess
from pathlib import Path

ESTADO = Path("run_state.json")

def cargar_estado():
    # Si existe un checkpoint previo, retomamos desde ahi (no desde cero)
    return json.loads(ESTADO.read_text()) if ESTADO.exists() else {"paso": 0}

def verificar():
    # Verificacion objetiva: el agente no decide si acerto, lo decide el test suite
    r = subprocess.run(["pytest", "-q"], capture_output=True)
    return r.returncode == 0

def ejecutar(pasos):
    estado = cargar_estado()
    for i in range(estado["paso"], len(pasos)):
        pasos[i]()  # aqui el agente hace su trabajo del paso i
        if not verificar():
            raise RuntimeError(f"Checkpoint fallido en paso {i}, deteniendo run")
        estado["paso"] = i + 1
        ESTADO.write_text(json.dumps(estado))  # checkpoint persistido
        print(f"Checkpoint OK: paso {i} verificado")

if __name__ == "__main__":
    tareas = [lambda: print("escribir modulo"), lambda: print("escribir tests")]
    ejecutar(tareas)

La idea clave: el agente no decide si acertó, lo decide la verificación. Y si el paso falla, el run se detiene en lugar de seguir contaminando. Al relanzarlo, cargar_estado() retoma desde el último checkpoint válido.

3. Aislar cada run con git worktrees

Si corres dos agentes en el mismo directorio, ambos editan package.json a la vez y uno sobrescribe al otro en silencio. Te enteras una hora después, cuando los tests fallan. Los git worktrees resuelven esto creando directorios de trabajo separados que comparten el mismo historial:

# Cada agente trabaja en su propio worktree aislado, sin pisarse entre si
git worktree add .worktrees/task-auth -b agent/auth
git worktree add .worktrees/task-api -b agent/api

# Lanzas el agente en cada worktree (terminales separadas)
cd .worktrees/task-auth && claude

# Al terminar: revisas el diff, mergeas y limpias
git merge agent/auth
git worktree remove .worktrees/task-auth

Una advertencia honesta: los worktrees aíslan código, no bases de datos. Si dos agentes corren migraciones contra la misma base, vas a tener conflictos. Usa schemas separados o secuencia esas tareas. Este patrón de aislamiento es primo del que defiende la separación de responsabilidades en arquitectura de software: límites claros para que un cambio no se propague donde no debe.

4 y 5. Verificación continua y log de evidencia

La verificación continua (tests, lint, typecheck, build después de cada milestone) es el juez que rompe la cadena de compounding error. Y el log de evidencia (un documentation.md con qué hizo el agente y qué probó en cada paso) mantiene el run inspectable y permite retomarlo. Sin evidencia, depurar un run de tres horas es arqueología.

Caso real: refactor nocturno sin niñera

En escenarios de producción, el setup típico para una tarea larga (migrar un módulo, actualizar dependencias en varios servicios) combina los cinco mecanismos: spec con criterios de aceptación, plan troceado en milestones de 15-20 minutos cada uno, cada milestone en su worktree, verificación con la suite de tests del repo y un log que se actualiza solo. Herramientas como deer-flow 2.0 de ByteDance empaquetan justo esto (subagentes con contexto acotado, sandboxes y memoria), aunque montar tu propio harness mínimo suele bastar para empezar.

¿Cuándo usar esto en producción? Cuando la tarea supera los 15-20 minutos de trabajo autónomo o toca más de tres o cuatro archivos. Por debajo de eso, el overhead de los worktrees y el spec no compensa: un branch normal y supervisión directa es más rápido.

En Producción

Lo que cambia entre el tutorial y la realidad:

• Coste: un run largo quema tokens rápido. Cada checkpoint que falla y reintenta es dinero. Para un desarrollador, una tarea autónoma de varias horas puede costar varios euros por run; con varios al día, hablamos de sumar al presupuesto mensual de APIs (en mi caso, entre 10 y 50 € al mes según la carga). Mide el coste por tarea antes de dejarlo suelto.
• Routing por tarea: no uses el modelo más caro para todo. Boilerplate y reescrituras mecánicas van con un modelo barato; la arquitectura y las decisiones difíciles, con el potente. Esta lógica de asignar el modelo correcto a cada fase la detallé en planificar con un modelo y ejecutar con otro en Claude Code.
• Recuperación ante fallo: el run va a fallar a mitad. La pregunta no es si, es cuándo. El checkpoint persistido es lo que diferencia "retomo desde el paso 8" de "vuelvo a empezar y pago otra vez tres horas".
• Observabilidad: instrumenta el gasto y los fallos por sesión. Volar a ciegas en un run autónomo es la forma más cara de descubrir que tu agente entró en un bucle de reintentos.
• Límite de autonomía: más libertad no es mejor. Acota ventanas de autonomía y resetea estado con frecuencia para cortar la propagación de errores.

Errores comunes y depuración

• Error: el agente reporta "hecho" pero nada funciona. Causa: no hay verificación objetiva, el agente se autoevalúa. Solución: que un test suite externo decida el éxito de cada checkpoint, nunca el propio agente.
• Error: la calidad cae a mitad del run. Causa: context rot, la ventana se llenó de intentos fallidos y ruido. Solución: trocea en subtareas con contexto fresco; usa subagentes con contexto acotado por tarea.
• Error: dos agentes corrompen archivos compartidos. Causa: comparten directorio de trabajo. Solución: git worktrees, un worktree por agente.
• Error: un fallo a las 2 horas obliga a empezar de cero. Causa: no hay estado persistido. Solución: checkpoints en disco después de cada milestone verificado.

Preguntas frecuentes

¿Un context window más grande resuelve el problema de las tareas largas?

No. Una ventana grande es memoria de trabajo de una sesión, pero llenarla acelera el context rot y degrada la calidad. La solución es trocear y verificar, no acumular más texto en un solo turno.

¿Cuándo merece la pena montar un harness con checkpoints?

Cuando la tarea supera los 15-20 minutos de trabajo autónomo o toca varios archivos o servicios. Para cambios cortos y supervisados, el overhead no compensa y un flujo manual con tests es más ágil.

¿Los git worktrees aíslan todo?

Aíslan código y dependencias por directorio, pero no bases de datos. Si tus agentes corren migraciones contra la misma base, necesitas schemas separados o contenedores por worktree, o secuenciar esas tareas.

Cierre

Hemos visto que un agente no se descarrila por falta de inteligencia, sino por falta de estructura: el context rot ensucia su memoria y el compounding error multiplica un fallo temprano hasta arruinar el run. La autonomía real no viene de soltarle la correa, viene de trocear el trabajo, verificar cada checkpoint, aislar cada run y dejar evidencia para retomar sin pagar dos veces. Si solo te llevas una idea, que sea esta: que el éxito de cada paso lo decida un test, no el propio agente.

Para validar que esos checkpoints miden lo correcto, vale la pena revisar cómo evaluar tu IA en producción y no solo offline, y si tu run lanza tareas paralelas, el patrón de subagentes que lanzan subagentes encaja directamente aquí.

¿Has dejado un agente trabajando solo varias horas? ¿Qué se rompió y cómo lo recuperaste? Cuéntamelo en los comentarios o en Twitter @sergiomarquezp_. En el próximo artículo entro en cómo coordinar varios de estos agentes sin que el coste se dispare.