Cómo reanudar una tarea larga de AI Agent tras una interrupción: checkpoints, contexto y flujo de recuperación

Cuando un AI Agent ejecuta una tarea larga, lo más doloroso no suele ser la interrupción en sí. Lo difícil llega después: la terminal desapareció, el contexto se reinició, el modelo recuerda solo media planificación y ya no sabes con certeza qué archivos se modificaron.

La solución práctica no es esperar que el Agent nunca falle. Es diseñar la tarea para que pueda reanudarse.

Este artículo responde una pregunta concreta: cuando una tarea larga de AI Agent se interrumpe, ¿cómo se recupera sin empezar desde cero?

Quick Answer

Para que una tarea larga de AI Agent sea recuperable, mantén visibles tres cosas durante todo el proceso: el objetivo, una lista de checkpoints y el estado actual del workspace. Tras una interrupción, primero revisa git status, los archivos modificados, los logs y los artefactos generados; luego reconstruye el contexto desde el último checkpoint; por último, pide al Agent que continúe solo con los puntos pendientes.

En una frase: no dejes que el Agent dependa solo de la memoria del chat. Haz que el repositorio y las notas de checkpoint sean la memoria.

Por qué las tareas largas se rompen fácilmente

Las tareas largas con Agent suelen fallar por razones bastante comunes:

el contexto del modelo crece demasiado;
un comando agota el tiempo de espera o desaparece la sesión de terminal;
el usuario abre una conversación nueva sin suficiente contexto;
el Agent olvida qué archivos ya tocó;
los archivos generados y los archivos fuente se mezclan;
las pruebas fallan a mitad de camino y el siguiente paso no queda claro.

El riesgo aumenta cuando la tarea incluye escribir contenido, editar código, ejecutar pruebas, generar traducciones o tocar varios directorios.

Por ejemplo, después de crear un flujo reutilizable con Codex Skills, puedes pedir al Agent que procese muchos posts en secuencia. Si se detiene a mitad, necesitas saber con claridad qué posts están terminados y cuáles siguen pendientes.

La estructura mínima para recuperar

Una tarea recuperable necesita una estructura pequeña pero explícita.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


Goal:
- What exactly should be finished?

Scope:
- Which directories or files may be changed?

Progress:
- Done
- In progress
- Pending

Verification:
- Which commands or checks prove the work is usable?

Recovery note:
- If interrupted, where should the next Agent continue?

No hace falta un documento de proyecto enorme. Basta con una checklist corta en el chat, un Markdown temporal o un SKILL.md específico para la tarea.

La clave es que el estado pueda reconstruirse fuera de la memoria del modelo.

Paso 1: revisa primero el workspace

Después de una interrupción, evita decir inmediatamente “continúa”. Primero revisa el repositorio.

Comandos útiles:

1
2
3


git status --short
git diff --stat
git diff -- path/to/file

Para contenido generado, revisa también los directorios de destino:

1

ls content/post/2026/07/38

En tareas de código, mira además la salida reciente de pruebas, los artefactos de build y los archivos que el Agent mencionó antes de interrumpirse.

El objetivo de este paso es simple: separar el trabajo terminado del trabajo a medias.

Paso 2: reconstruye un contexto compacto

Al iniciar una nueva sesión de Agent, usa un prompt de recuperación compacto en lugar de pegar toda la conversación anterior.

Ejemplo:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


Continue the interrupted task.

Goal:
- Translate posts 36, 37, and 38 into en, zh-tw, ja, and es.

Already completed:
- 36: all target files created.
- 37: all target files created.

Still pending:
- 38: create index.en.md, index.zh-tw.md, index.ja.md, index.es.md.

Rules:
- Preserve source date and slug.
- Skip existing target files.
- Do not commit.

Verification:
- Check target files exist.
- Check date/slug match source.
- Check front matter and code fences are valid.

Este tipo de prompt da al Agent suficiente estado para continuar sin volver a discutir toda la tarea.

Paso 3: continúa desde la siguiente unidad pequeña

No reinicies toda la tarea larga salvo que sea necesario. Reanuda desde la siguiente unidad pequeña.

Buenas unidades de trabajo:

un artículo;
un idioma de traducción;
un archivo de pruebas;
un módulo;
un lote de artefactos generados;
un comando más su verificación.

En tareas de programación con IA, esto es especialmente importante. Si también usas hooks para ejecutar pruebas automáticamente, como en Claude Code hooks para ejecutar tests automáticamente, conviene que la unidad de recuperación sea lo bastante pequeña como para que un fallo apunte a un archivo o comportamiento concreto.

Paso 4: pide verificación antes de seguir

El patrón más seguro para reanudar es:

1

Inspect current state, finish only the pending part, then verify before doing anything else.

En tareas de contenido, la verificación puede incluir:

existencia de archivos;
campos de front matter;
consistencia de slug y fecha;
sintaxis de enlaces internos;
bloques de código Markdown;
ausencia de daños evidentes de codificación.

En tareas de código, puede incluir:

pruebas unitarias enfocadas;
type check;
lint;
build limitado;
revisión de git diff.

El Agent no debería tratar “el archivo existe” como equivalente a “la tarea está terminada”.

Qué guardar antes de empezar una tarea larga

Antes de iniciar una tarea larga con Agent, conviene guardar:

el objetivo exacto;
las rutas permitidas;
las rutas prohibidas;
el orden de procesamiento;
el comando de verificación;
la regla de rollback o recuperación.

Por ejemplo:

1
2
3
4
5


Process posts 36, 37, 38 in that order.
Only create missing target language files.
Do not edit existing translated files.
After each post, verify date and slug.
If interrupted, continue from the first post with missing targets.

Este pequeño párrafo puede ahorrar bastante limpieza después.

Qué hacer cuando el contexto crece demasiado

Las tareas largas también fallan porque el prompt se vuelve demasiado grande. La solución es comprimir contexto de forma agresiva.

Conserva:

el objetivo actual;
la lista de archivos modificados;
las decisiones ya tomadas;
los pendientes;
los resultados de verificación.

Descarta:

discusiones repetidas;
intentos fallidos antiguos después de conocer la solución;
salidas de comandos demasiado largas;
contenido de archivos no relacionado;
planes especulativos que no se usaron.

Si el problema es el consumo de tokens, se aplica la misma idea al debugging: conserva solo los hechos necesarios para la siguiente acción. Traté un síntoma relacionado en cómo investigar picos de tokens en Claude Code.

Cuándo convertirlo en un Skill o workflow

Si el mismo patrón de recuperación se repite, conviértelo en un flujo reutilizable.

Un workflow puede definir:

cómo descubrir archivos fuente;
cómo decidir qué ya está terminado;
qué debe saltarse;
cómo conservar metadatos;
cómo verificar el resultado;
qué debe incluir el informe final.

Aquí es donde un skill local resulta útil. En lugar de depender de un prompt largo cada vez, codificas las reglas de recuperación una vez y las reutilizas.

Para el traspaso entre herramientas, la idea es similar. Si Codex empieza una tarea y Claude Code la termina, o al revés, usa un checkpoint explícito. Desarrollé esa dirección en handoff de tareas entre Codex y Claude Code.

Plantilla práctica de prompt de recuperación

Puedes reutilizar esta plantilla:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


This is a resumed AI Agent task.

Objective:
- ...

Source of truth:
- Repository files and git status are more reliable than prior chat memory.

Allowed changes:
- ...

Already done:
- ...

Pending:
- ...

Rules:
- ...

Verification:
- ...

Please inspect the current workspace first, continue only the pending items, and report exactly what changed.

La línea más importante es la regla de source of truth. Evita que el Agent siga una memoria antigua cuando el workspace dice otra cosa.

Errores comunes

Los errores más frecuentes al recuperar tareas largas son:

decir solo “continúa” sin aportar estado;
pedir al Agent que rehaga todo;
ignorar git status;
mezclar archivos generados con cambios de código fuente;
saltar la verificación porque “parece terminado”;
permitir que el Agent edite archivos no relacionados durante la recuperación.

Recuperar no consiste solo en continuar. Consiste en reducir la tarea hasta que continuar sea seguro.

Conclusión

Una tarea larga de AI Agent interrumpida no es automáticamente una tarea fallida. Solo se convierte en fracaso cuando no existe un estado externo desde el que recuperarla.

Para tareas largas, conserva un objetivo, una lista de checkpoints y una regla de verificación. Tras la interrupción, revisa primero el workspace, reconstruye un contexto compacto, reanuda desde la siguiente unidad pequeña y verifica antes de ampliar de nuevo el alcance.

Cuando esto se vuelve hábito, el trabajo largo con Agent se siente mucho menos frágil. El Agent puede olvidar, la terminal puede cerrarse y la conversación puede reiniciarse, pero la tarea sigue teniendo un rastro que seguir.