Agent Checkpoints and Recovery
Agent Checkpoints and Recovery agrupa la captura de estado restorable de una ejecución agente y las acciones necesarias para reanudar, retroceder o reconstruir su progreso después de una interrupción o resultado indeseado. Un checkpoint conserva un punto de recuperación con el alcance que implemente el runtime. Recovery utiliza ese estado y otras evidencias para decidir cómo continuar; no se reduce a cargar un snapshot y repetir la próxima llamada.
En el Atlas se trata como una táctica de continuidad de ejecución, no como promesa de rollback transaccional de todo el entorno. Qué se captura, qué puede restaurarse y qué necesita revalidación son preguntas concretas. Restaurar estado del agente no deshace necesariamente comandos, escrituras, mensajes o despliegues realizados en sistemas externos.
Qué representa un checkpoint
Un checkpoint puede conservar posición de ejecución, observaciones, contexto seleccionado, resultados previos y referencias a tareas pendientes. Su contenido depende del runtime y de las garantías que necesita el caso de uso. Una marca de “último paso completado” puede ser suficiente para reconstruir una actividad sencilla y ser insuficiente para reponer un loop con varias operaciones en curso.
La propiedad importante es que permita una forma definida de restauración o reconstrucción. Guardar un log o una lista de pasos sin saber cómo interpretarlos al retomar no crea automáticamente un checkpoint operativo. Tampoco hace falta serializar cada detalle del proceso: ciertos recursos no son restaurables de esa manera y deben obtenerse o verificarse otra vez.
La identidad del punto importa. Una ejecución puede tener varios checkpoints con distintas revisiones, datos y supuestos. Elegir uno exige conocer a qué trabajo corresponde y qué efectos ocurrieron después. Un nombre como “estable” no sustituye esa evidencia ni demuestra que la tarea ya estaba correctamente resuelta allí.
Estado, sesión y continuidad
Agent Harness mantiene el hogar general de Agent State and Sessions: condición y continuidad operativa. Un checkpoint captura una representación restorable de parte de ese estado. No redefine qué es una sesión ni exige que todas las implementaciones tengan la misma identidad o frontera de conversación.
La restauración puede recuperar que se esperaba una herramienta sin recuperar el proceso remoto que la ejecutaba. También puede devolver una observación anterior cuyo recurso ya cambió. El runtime y el agente necesitan interpretar esas condiciones. Una representación consistente internamente puede ser obsoleta respecto del mundo donde se continuará.
Conviene distinguir recuperación de estado y autorización para actuar. La identidad o los permisos de una sesión anterior pueden no seguir vigentes. Agent Permissions and Approval Boundaries conserva esa frontera; un checkpoint no amplía por sí mismo el alcance permitido al reanudar.
Checkpoint y Git commit
Un commit es un artefacto de control de versiones que identifica un estado de archivos y su historia. Un checkpoint del agente captura estado de ejecución. Puede referenciar un commit como base del trabajo, pero no equivale a él. El commit no conserva automáticamente llamadas pendientes, observaciones recibidas o decisiones abiertas del runtime.
La relación inversa también tiene límites. Un checkpoint puede saber sobre qué revisión se trabajaba sin guardar todos los cambios locales. Restaurarlo no garantiza que el workspace contenga esa revisión ni que los archivos sin confirmar se hayan preservado. Para continuar correctamente hay que conocer qué recursos cubre la restauración y cómo se reconstruyen los que están fuera.
Esta distinción evita automatismos peligrosos: no corresponde resetear el repositorio para que coincida con una narración antigua ni asumir que crear un commit resuelve toda continuidad de la tarea. Los cambios ajenos y el trabajo local existente necesitan conservar su procedencia y propiedad.
Checkpoint y workspace
Workspace Isolation for Coding Agents separa copias y estado de trabajo entre tareas. Un worktree puede facilitar experimentar o conservar cambios propios, pero no es un checkpoint del runtime. Tener dos carpetas no conserva automáticamente estado de sesión ni solicitudes pendientes.
Ambos mecanismos pueden colaborar. Una recuperación puede utilizar un workspace cuya base y cambios son conocidos, mientras el checkpoint ubica el progreso de la ejecución. Si ese workspace cambió por otra actividad, corresponde verificarlo antes de continuar. La separación física tampoco revierte bases de datos o servicios compartidos.
La limpieza del workspace es otra acción con efectos. Que una ejecución se haya abandonado no demuestra que todo su contenido sea descartable. La recuperación debe delimitar recursos propios y preservar evidencia o trabajo ajeno que todavía pueda ser necesario.
Checkpoint, plan y memoria
Planning representa un curso previsto; un checkpoint captura estado restorable. Una lista que propone ejecutar tres pasos no determina cuál terminó ni qué observación debe alimentar la continuación. Marcar casillas tampoco reconstruye por sí solo la maquinaria que produjo el resultado.
Agent Memory conserva información para uso futuro. Puede formar parte del estado capturado o mantenerse como una fuente externa referenciada. Esas opciones tienen consecuencias distintas: restaurar referencias puede recuperar datos ya actualizados por otra ejecución; restaurar una copia puede reintroducir información obsoleta.
La documentación de persistencia de LangGraph, consultada el 2026-10-28, distingue checkpointers de estado por thread y stores de información entre threads. Es un ejemplo de implementación que relaciona continuidad y memoria; no establece la definición universal de checkpoint ni obliga a utilizar sus componentes.
Recovery y retry
Retry repite una operación o intento. Recovery busca restablecer condiciones para continuar después de un problema. Puede usar retry, pero también volver a la fuente, reconstruir contexto, elegir otra herramienta o detener una acción que ya no tiene sentido. Cargar un checkpoint y repetir sin considerar lo ocurrido puede reproducir el mismo fallo.
Coding-Agent Failure Modes and Recovery aplica esas diferencias al trabajo de software. Aquí el foco general está en estado y continuidad del agente. Una pérdida de contexto quizá se recupere leyendo evidencia actual; un efecto externo incierto puede requerir inspeccionar su destino antes de reanudar cualquier escritura.
El criterio es recuperar progreso justificable, no maximizar la cantidad de reintentos. Si las condiciones no cambiaron y no hay evidencia nueva, un loop de restauración y repetición puede consumir recursos sin acercarse al objetivo.
Efectos externos y límites del rewind
Una operación de shell puede haber escrito archivos; una API puede haber enviado un mensaje; un deploy puede haber actualizado un servicio. Restaurar el estado interno anterior no deshace esos efectos. La frontera depende de qué recursos controla realmente el mecanismo de recuperación.
También puede haber incertidumbre: la operación ocurrió, pero su confirmación no llegó al agente. Un checkpoint anterior al resultado puede llevar a emitirla otra vez. Idempotency ayuda a razonar sobre repetición de efectos, sin convertir cualquier herramienta en idempotente. La recuperación necesita identificar qué sabe sobre la operación y qué puede comprobar ahora.
Revertir o compensar un efecto externo es otra acción, con semántica y autoridad propias. No debería describirse como una consecuencia automática del rewind. Tampoco se presupone que sea posible: ciertos efectos solo admiten una corrección posterior o requieren una decisión humana fuera del control del runtime.
Elegir un punto de recuperación
Un punto reciente reduce trabajo repetido, pero puede incluir el supuesto que causó el problema. Uno anterior puede descartar progreso válido y requerir reconciliar más efectos. La elección depende de qué se intenta corregir y de la evidencia disponible sobre el estado, no solo de la fecha del checkpoint.
Un fallo de herramienta puede requerir retomar desde una observación conocida. Un objetivo mal entendido puede exigir revisar el encuadre antes de reutilizar el plan. Una política cambiada puede impedir continuar la misma trayectoria. El mecanismo de almacenamiento no decide por sí solo cuál de esas respuestas es correcta.
Conviene conservar por qué se eligió el punto y qué límites siguen abiertos. No hace falta capturar razonamiento privado; basta información operativa que permita revisar la continuación y no repetir una acción externa por una interpretación equivocada del historial.
Recuperar con evidencia
La recuperación puede comenzar comprobando revisión, recursos y resultados realmente existentes. Si el registro decía que una comprobación estaba pendiente, quizá otra ejecución ya la completó. Si decía que una publicación falló, puede haber ocurrido con respuesta perdida. El estado actual del destino puede modificar el siguiente paso.
Agent Tracing puede relacionar solicitudes, resultados e interrupciones, y los Development Context and Execution Records conservar evidencia útil de trabajo de desarrollo. Ninguno es un checkpoint por definición. Ayudan a interpretar qué ocurrió y a decidir qué estado conviene reconstruir.
Después de restaurar puede ser necesario repetir checks seleccionados sobre el nuevo estado. Un resultado anterior no describe automáticamente una combinación diferente de archivos o datos. Para cambios de software, Generated Code Verification conserva el juicio de si la tarea concreta está respaldada.
Ejemplo: publicación con respuesta perdida
Un agente prepara un artefacto y solicita publicarlo. Antes de recibir la confirmación, se interrumpe la sesión. Al restaurar un checkpoint previo, el plan todavía muestra la publicación pendiente. Repetirla inmediatamente puede crear otro artefacto o volver a ejecutar efectos asociados.
La recuperación primero comprueba qué se publicó y a qué revisión corresponde. Si el resultado ya existe, puede continuar con su verificación. Si no hay evidencia suficiente, debe conservar esa incertidumbre y elegir una acción compatible con la semántica de la operación. El checkpoint ayudó a reconstruir intención y progreso; no convirtió la acción externa en una transacción reversible.
Costo y uso proporcional
La compatibilidad incluye el significado del estado, no solo poder leer su formato. Una herramienta puede haber cambiado el contrato de sus argumentos desde la captura, o una referencia puede señalar ahora otro recurso. Restaurar los mismos bytes no demuestra que la próxima invocación conserve sus efectos originales. Cuando esa diferencia afecta la continuación, corresponde contrastar versiones y condiciones o reconstruir la parte pertinente desde fuentes actuales. No hace falta convertir cada checkpoint en una copia completa del entorno, pero sí reconocer qué dependencias externas limitan su capacidad de restauración.
Capturar y mantener estado tiene costo de almacenamiento, compatibilidad y operación. Un checkpoint de una representación antigua puede requerir interpretación o dejar de ser restaurable. No toda tarea breve necesita persistencia del runtime ni conviene capturar cada paso de una ejecución que puede reconstruirse fácilmente desde fuentes autoritativas.
La táctica es útil cuando reduce pérdida de trabajo o permite continuidad con límites comprensibles. Su éxito no se mide por cantidad de snapshots, sino por la capacidad de retomar con estado válido y evidencia suficiente. No reemplaza permisos, verificación, memoria o coordinación, y no promete deshacer el mundo externo al agente.
Fuentes
- LangGraph: Persistence: ejemplo específico de persistencia de estado y stores, consultado el 2026-10-28. Los criterios generales de recuperación y sus límites son síntesis editorial del Atlas.