Agentes de IA de larga duración: qué necesitas antes de soltarlos

En julio de 2026 el titular es fácil de encontrar. Ingenieros de Rakuten pusieron a prueba a Claude Code con una tarea concreta: implementar un método de extracción de vectores de activación en vLLM, una librería open source de 12,5 millones de líneas en varios lenguajes. El modelo terminó el trabajo entero en siete horas de trabajo autónomo, de una sola tirada, con un 99,9% de precisión numérica frente al método de referencia, según el informe de Anthropic^[1]. Es la clase de dato que se comparte solo.

El mismo informe, unas páginas más adelante, dice que los desarrolladores usan IA en torno al 60% de su trabajo pero solo delegan por completo entre el 0 y el 20% de sus tareas^[1]. Esa distancia entre lo que el modelo puede hacer y lo que los equipos se atreven a soltarle no se cierra con un modelo mejor. Se cierra con un arnés.

La pregunta senior no es cuántas horas aguanta el modelo. Es qué tienes que tener montado en tu sistema para que dejar un agente de IA de larga duración trabajando solo durante horas sea una decisión de ingeniería y no ruleta rusa.

¿De verdad los agentes ya trabajan horas solos?

Sí, pero conviene separar quién lo dice y con qué rigor lo mide. Hay tres niveles, y mezclarlos es lo que produce el hype.

La medición independiente la hace METR. Definen el horizonte de tarea al 50% de confianza: la duración de tarea, medida por lo que tarda un humano experto, que el modelo completaría con un 50% de probabilidad^[2]. Su hallazgo es que esa duración se dobla más o menos cada siete meses^[3]. Los modelos de marzo de 2025 acertaban casi el 100% de las tareas de menos de cuatro minutos humanos, y caían por debajo del 10% en las de más de cuatro horas^[3].

La observación la aporta el informe de Anthropic. Los primeros agentes resolvían tareas de minutos (arregla este bug, escribe esta función); a finales de 2025 producían conjuntos de features completos a lo largo de varias horas. Para 2026 predice días, y lo dice con una coletilla que importa, “con checkpoints humanos periódicos”^[1]. La parte de días es predicción, no medida.

El tercer nivel son los claims del propio fabricante. Anthropic dice haber observado a Sonnet 4.5 mantener el foco más de 30 horas en tareas complejas de varios pasos^[4], y con Fable 5 (junio de 2026) describe la migración de una base de código Ruby de 50 millones de líneas hecha en un día, cuando a un equipo le habría llevado más de dos meses a mano^[5]. Son afirmaciones de quien vende el modelo. Útiles como techo, no como suelo.

Y aquí está el detalle que casi nadie cita: la propia METR advierte que sus mediciones por encima de las 16 horas no son fiables con la suite de tareas actual^[2]. Ni la organización de referencia en medir esto puede verificar todavía horizontes de días. Razón de más para que la verificación sea tuya y no la delegues a un benchmark ajeno.

¿Por qué la autonomía la concede el arnés y no el modelo?

La autonomía no se concede por confianza en el modelo sino por calidad del arnés. Esa es la tesis, y el propio informe que celebra las siete horas la respalda sin querer.

La brecha de delegación (60% de uso, entre 0 y 20% de delegación total^[1]) no es desconfianza irracional. Es la ausencia de las piezas que hacen que soltar el agente sea seguro. El mismo documento lo remata: el trabajo con agentes no está totalmente delegado, es altamente colaborativo^[1].

Un agente de larga duración y un agente colgado en bucle infinito son, por dentro, el mismo bucle: leer estado, decidir acción, ejecutar, repetir. La diferencia está en otra parte. Uno tiene una condición de parada diseñada y ground truth en cada paso; el otro gira sin señal externa de que avanza. El agente de larga duración es el caso extremo del bucle agéntico bien diseñado: mismo mecanismo, mucha más superficie donde equivocarse.

Lo que sigue son seis piezas de ingeniería: patrones de diseño que se construyen en tu sistema. Si quieres practicarlos desde la base, en el curso Patrones de Diseño para Agentes de IA se trabajan uno a uno. Y buena parte de los proyectos de agentes que acaban cancelados caen por no tener este andamiaje montado, no por un modelo flojo.

¿Qué criterio de aceptación ejecutable define “terminado”?

Un agente sabe que ha terminado cuando algo que puede ejecutar le dice que sí. Sin ese primer prerrequisito, ninguno de los demás sirve.

La doc de Claude Code lo dice sin rodeos: dale a Claude una comprobación que pueda ejecutar (tests, un build, una captura que comparar); es la diferencia entre una sesión que vigilas y una de la que te puedes ir^[6]. Sin esa comprobación, “parece terminado” es la única señal disponible y tú te conviertes en el bucle de verificación: cada error espera a que tú lo notes^[6].

Esto no es nuevo. Desde “Building effective agents”, Anthropic insiste en que el agente obtenga ground truth del entorno en cada paso: resultados de tool calls, ejecución de código, algo real contra lo que contrastar^[7]. Y el arnés para agentes de larga duración lo eleva a norma de proceso: marca una feature como “passing” solo después de testearla con cuidado^[8]. El criterio de aceptación es un script que devuelve exit code, no una impresión.

# check.sh — la condición de parada que el agente ejecuta, no interpreta.
# Encadena verificación barata a cara y corta en el primer fallo.
set -euo pipefail

npm run lint            # estático: rápido, descarta lo obvio
npm test                # tests sobre el diff
npm run build           # que compile de verdad, no que "compile en su cabeza"
node evals/run.mjs      # tu eval de dominio: puntuación mínima o exit 1

echo "PASS"             # solo si todo lo anterior pasó

Cuando no hay test determinista (una salida en lenguaje natural, un diseño, una decisión de producto), el check secundario es un modelo como juez con una rúbrica explícita. Y si estás definiendo qué métricas cuentan como “terminado” en producción, ese trabajo es el mismo que describo en cómo evaluar agentes IA en producción. La regla de fondo: la condición de parada la fijan tus evals, no un benchmark público que mide otra cosa.

¿Cómo reanuda un agente que no recuerda nada?

Un agente de larga duración no recuerda nada entre sesiones: cada arranque parte de cero. El problema central, según Anthropic engineering, es que estos agentes trabajan en sesiones discretas y cada sesión nueva empieza sin memoria de lo anterior^[8]. El modelo no persiste. El estado tiene que vivir fuera de él.

Su arnés lo resuelve con un agente inicializador que monta el andamiaje la primera vez: un script init.sh, un fichero claude-progress.txt que registra qué han hecho los agentes, y un commit inicial de git^[8]. Cada sesión posterior hace progreso incremental y deja actualizaciones estructuradas. La clave, en sus palabras, es que un contexto fresco entienda el estado del trabajo rápido, y eso se consigue con el progress file junto al historial de git^[8]. Es el mismo principio que hace del spec-driven development la memoria del equipo: lo que tiene que sobrevivir a la sesión vive versionado en el repo, no en el context window.

# No es un script: es la estructura de ficheros que el arnés necesita en el repo.
# Estado reanudable: vive en el repo, no en el context window.
init.sh                 # levanta el entorno igual en cada sesión
claude-progress.txt     # log append-only: hecho / en curso / siguiente / decisiones
.git/                   # commits incrementales = puntos de reanudación reales

# convención de commit por sesión:
#   feat(step-7): extractor pasa; tests verdes; siguiente = normalizar salida

Claude Code añadió en septiembre de 2025 checkpoints con rollback instantáneo a un estado anterior, una de sus features más pedidas^[4]. Son útiles dentro de la sesión. Pero la propia doc avisa en un recuadro: los checkpoints solo registran cambios hechos por Claude, no procesos externos, y no sustituyen a git^[6]. El estado reanudable serio sigue siendo el repo.

Presupuestos con corte duro: tokens, tiempo, acciones

Un agente sin presupuesto con corte duro no trabaja más: quema más. “Building effective agents” recomienda condiciones de parada explícitas, como un máximo de iteraciones, para mantener el control^[7], y nombra el riesgo que las justifica: la naturaleza autónoma implica costes más altos y errores que se componen^[7]. Un agente que lleva tres horas equivocándose no está avanzando. Está amplificando el error, y pagando tokens por hacerlo.

El corte duro va en tres ejes que puedes medir: tokens consumidos, tiempo de reloj y número de acciones ejecutadas. El primero que se agote mata el run. No hay cifras públicas del consumo en tokens de una sesión de siete horas, así que el presupuesto no lo sacas de un titular: lo calibras con tus propios runs cortos y su telemetría, la misma disciplina de medir cada ciclo para ajustar el siguiente.

	Agente de larga duración	Agente colgado
Condición de parada	diseñada y ejecutable (check.sh en verde)	“hasta que parezca terminado”
Señal de progreso	tests passing + commit + progress file por sesión	actividad sin ground truth
Coste	presupuesto con corte duro en tokens, tiempo y acciones	crece mientras crece el error
Errores	detectados en el paso N por el check	compuestos en silencio durante horas
Cuando vuelves	auditas un log estructurado	arqueología en el scrollback

El esqueleto de un run desatendido con corte duro cabe en unas líneas de bash:

# Run desatendido: permisos acotados + reloj + tope de iteraciones + tope de tokens.
MAX_ITERS=40; iter=0
MAX_TOKENS=2000000; tokens=0     # tercer eje: corta por consumo acumulado

while [ "$iter" -lt "$MAX_ITERS" ] && [ "$tokens" -lt "$MAX_TOKENS" ]; do
  out=$(timeout 20m claude -p "Avanza el objetivo. Al terminar ejecuta ./check.sh." \
    --allowedTools "Edit,Bash(npm run lint),Bash(npm test),Bash(npm run build),Bash(./check.sh),Bash(git commit *)" \
    --output-format json)                                  # nada de acceso libre
  tokens=$((tokens + $(echo "$out" | jq '.usage.input_tokens + .usage.output_tokens')))
  ./check.sh && break            # condición de parada real: el check pasa
  iter=$((iter + 1))
done

[ "$iter" -eq "$MAX_ITERS" ]    && echo "CORTADO: presupuesto de iteraciones agotado"
[ "$tokens" -ge "$MAX_TOKENS" ] && echo "CORTADO: presupuesto de tokens agotado"

Permisos mínimos y sandboxing: la fatiga de aprobación

Un run desatendido necesita permisos mínimos, aislamiento a nivel de sistema operativo y un registro de lo que hizo. Empieza por lo que parece seguridad y en realidad es diseño: la fatiga de aprobación. Cuantas más veces aprueba un humano, menos lee; la supervisión se vuelve teatro y, según Anthropic, hace el desarrollo menos seguro^[9]. La respuesta no es aprobar a ciegas. Es que el agente no tenga que preguntar por lo que ya está acotado.

El sandboxing a nivel de sistema operativo de Anthropic redujo los permission prompts un 84% en su uso interno^[9]. Exige doble aislamiento: sin aislamiento de red, un agente comprometido puede exfiltrar ficheros sensibles como claves SSH; sin aislamiento de filesystem, puede escapar del sandbox y ganar acceso a la red^[9]. Uno sin el otro no sirve. El runtime es open source (sandbox-runtime, Apache 2): Seatbelt en macOS, bubblewrap en Linux, con denegación por defecto tanto de escritura como de red^[10].

En ejecución por lotes, el flag --allowedTools restringe lo que el agente puede hacer, y eso importa justo cuando corres desatendido^[6]. Permisos mínimos y sandbox son guardarrailes aplicados al caso de mayor riesgo: horas sin nadie mirando. Y ese perímetro incluye lo que el agente lleva instalado: cada skill y cada servidor MCP conectado corren esas horas con tus llaves, otra cadena de suministro que hay que auditar.

Queda la observabilidad. Cuando vuelvas, tienes que poder reconstruir qué hizo el agente y por qué. El progress file, el historial de git y los logs de tool calls son la caja negra del vuelo: sin ellos, el post-mortem de un run de siete horas es imposible.

¿Cuál es tu plan de rollback cuando vuelvas y esté mal?

Asume que un porcentaje de tus runs largos va a terminar mal, y diseña para ese caso desde el principio. El aislamiento del trabajo es lo primero: worktrees, sesiones de CLI en checkouts de git aislados para que las ediciones no colisionen^[6]. Una rama desechable por run. Si el resultado no pasa el check, borras la rama y no ha tocado nada tuyo.

Antes de dar el trabajo por bueno, una revisión adversarial. La doc lo formula bien: cuanto más tiempo trabaja el agente sin supervisión, más importa una comprobación independiente antes de contar el trabajo como hecho^[6]. Un revisor en contexto fresco ve el diff y los criterios, no el razonamiento que produjo el cambio, así que lo juzga por lo que es. Los checkpoints del producto son la primera capa; el plan de rollback de verdad es git.

Y así se cierra el círculo. La pregunta no era cuánto aguanta el modelo. Era cuánto aguanta tu arnés. El caso de Rakuten funcionó por una razón que se lee entre líneas: un 99,9% de precisión frente a un método de referencia^[1] significa que existía una referencia contra la que verificar. Había check ejecutable. Sin él, esas siete horas solo habrían producido código sin verificar que alguien tendría que revisar a mano, línea a línea, para saber si servía.

Errores comunes

Soltar el agente sin check ejecutable

El error raíz del que salen casi todos los demás. Si no puedes escribir el check.sh, la tarea todavía no es delegable: “parece terminado” será la única señal y volverás a ser tú el bucle de verificación^[6].

Tratar los checkpoints del producto como plan de rollback

Solo registran cambios del propio agente, no procesos externos, y la doc dice que no sustituyen a git^[6]. Sirven para deshacer dentro de la sesión, no para volver a un estado bueno.

Ampliar permisos “para que no pregunte tanto”

Aprobar a ciegas y dar barra libre son el mismo error con distinto disfraz: en los dos casos nadie mira de verdad. La alternativa a la fatiga de aprobación es sandbox más permisos mínimos.

Presupuesto sin corte duro

Un agente colgado no se queda quieto: gasta. Sin un tope de tokens, tiempo o acciones, la naturaleza autónoma se traduce en coste alto y errores compuestos^[7].

Extrapolar el titular del vendor a tu sistema

Que Anthropic diga 30 horas no dice nada sobre tu tarea. La medición independiente ni siquiera verifica horizontes por encima de 16 horas con su suite actual^[2]. Calibra con tus runs.

Checklist antes de soltar el agente

• Existe un check.sh que devuelve pass/fail y define “terminado” sin tu criterio
• El agente obtiene ground truth en cada paso (tests, ejecución), no solo autoevaluación
• El estado sobrevive a la sesión: init.sh, progress file y commits incrementales
• Hay corte duro por tokens, tiempo de reloj y número de acciones
• El run corre con permisos mínimos y sandbox, con filesystem y red aislados
• Puedes auditar después qué hizo: progress file, git y logs de tool calls
• El trabajo vive en un worktree o rama desechable, con revisión adversarial antes del merge

Fuentes

1. 2026 Agentic Coding Trends Report — Anthropic — caso Rakuten sobre vLLM (12,5M líneas, 7 h autónomas, 99,9% de precisión), trayectoria minutos→horas→días “con checkpoints humanos periódicos” y brecha de delegación (60% de uso, 0–20% de delegación total).
2. Task-Completion Time Horizons — METR — definición del horizonte de tarea al 50% de confianza y el aviso de que las mediciones por encima de 16 horas no son fiables con la suite actual.
3. Measuring AI Ability to Complete Long Tasks — METR — doblado del horizonte de tarea cada ~7 meses y tasas de éxito de los modelos de marzo de 2025 (menos de 4 min humanos frente a más de 4 h).
4. Claude Sonnet 4.5 — Anthropic — claim de más de 30 horas de foco y los checkpoints con rollback instantáneo como primitiva de producto en Claude Code.
5. Claude Fable 5 and Claude Mythos 5 — Anthropic — migración de una base Ruby de 50 millones de líneas en un día (claim de vendor).
6. Best practices for Claude Code — Anthropic — “give Claude a check it can run”, el humano como bucle de verificación, --allowedTools en runs desatendidos, worktrees, revisión adversarial y el aviso de que los checkpoints no reemplazan a git.
7. Building effective agents — Anthropic — condiciones de parada (máximo de iteraciones), ground truth por paso y el riesgo de coste alto y errores compuestos.
8. Effective harnesses for long-running agents — Anthropic — sesiones sin memoria, agente inicializador (init.sh, claude-progress.txt, commit inicial) y verificación antes de marcar una feature como “passing”.
9. Claude Code sandboxing — Anthropic — reducción del 84% de permission prompts, doble aislamiento filesystem+red y fatiga de aprobación.
10. anthropic-experimental/sandbox-runtime — GitHub — runtime open source (Apache 2) con Seatbelt en macOS y bubblewrap en Linux, y denegación por defecto de escritura y red.

Preguntas Frecuentes

¿Cuánto tiempo puede trabajar un agente de IA de larga duración sin supervisión en 2026?

Depende de quién lo mida. METR, que mide horizontes de tarea de forma independiente, sitúa el crecimiento en un doblado cada siete meses aproximadamente, pero advierte que sus mediciones por encima de las 16 horas no son fiables con la suite actual. Anthropic observó el paso de minutos a varias horas a finales de 2025 y afirma más de 30 horas de foco con Sonnet 4.5, aunque eso último es un claim de vendor. En la práctica, cuánto puede trabajar solo un agente de IA de larga duración lo decide tu arnés, no el titular.

¿Qué diferencia hay entre un agente de larga duración y un agente colgado en bucle infinito?

Por dentro son el mismo bucle: leer estado, decidir, actuar, repetir. La diferencia está en dos cosas, una condición de parada diseñada y ejecutable, y ground truth en cada paso. El agente de larga duración para cuando un check devuelve verde; el colgado gira sin ninguna señal externa de que avanza, quemando tokens mientras amplifica su propio error.

¿Los checkpoints de Claude Code sustituyen a git?

No. Solo registran los cambios hechos por Claude, no los de procesos externos, y la propia documentación dice que no son un reemplazo de git. Sirven para deshacer dentro de una sesión; el plan de rollback real son las ramas y los worktrees de git.

¿Necesito sandbox si ya reviso cada permiso a mano?

Sí. La revisión manual se degrada sola: después de aprobar decenas de prompts dejas de leerlos y la supervisión se vuelve teatro. El sandboxing a nivel de sistema operativo redujo los permission prompts un 84% en el uso interno de Anthropic sin perder seguridad, precisamente porque acota lo que el agente puede hacer en vez de depender de que tú mires cada vez.

¿Cómo decido si una tarea es delegable a un agente durante horas?

Hazte dos preguntas. ¿Existe un check ejecutable que defina “terminado” sin tu criterio, como tests, un build o una eval? ¿Hay una referencia contra la que verificar el resultado? Una migración con suite de tests y un método de referencia contra el que contrastar la salida cumple las dos: el agente sabe cuándo ha terminado y tú puedes comprobar si acertó, así que es delegable. Un refactor de UX guiado por “que quede mejor” no cumple ninguna —el único juez sigues siendo tú—, y se queda del lado humano. Si la respuesta a alguna es no, la tarea todavía es colaborativa, no delegable a un agente de IA de larga duración durante horas. Es coherente con que los equipos solo deleguen del todo entre el 0 y el 20% de sus tareas.