Recuperación ante fallos en agentes de IA: cuándo reanudar, deshacer o detenerse

El fallo de una llamada no equivale al fallo de la tarea

Un agente puede tener que consultar información, modificar un registro y después comunicar el resultado. Si falla la respuesta de una herramienta en mitad de ese flujo, no basta con decidir si se repite la última llamada. Puede que la acción no haya llegado al sistema externo; puede que sí se haya ejecutado y solo se haya perdido la confirmación; o puede que el cambio haya quedado aplicado parcialmente. Cada caso exige una decisión distinta.

En esta guía, recuperarse significa reconciliar el objetivo y el progreso registrado por el agente con el estado comprobable del entorno, y elegir una continuación segura o una parada explícita. La unidad de análisis es la tarea de varios pasos, no una solicitud aislada. Reintentar una llamada puede ser parte de la recuperación, pero no la define.

La recomendación central es sencilla: antes de repetir una acción cuyo resultado se desconoce, comprueba qué ocurrió fuera del agente. Si no hay forma fiable de verificarlo, no conviertas la incertidumbre en una segunda modificación. Limita las acciones posteriores y deriva el caso a una persona cuando el coste de equivocarse supere el de esperar.

Mapa de fallos: primero clasifica lo que sabes

Un error explícito no siempre prueba que el sistema externo haya permanecido intacto. Del mismo modo, un timeout solo indica que el agente no obtuvo una respuesta a tiempo; por sí solo no demuestra si la operación se completó. Por eso, clasifica el episodio según la evidencia disponible, no según la etiqueta de error que recibió el agente.

Distingue cinco situaciones. En un fallo confirmado, la respuesta permite concluir que la acción no se ejecutó. En un resultado ambiguo, la solicitud pudo llegar, pero no hay confirmación fiable. En una respuesta inválida, hay una contestación, pero su formato o contenido no permite usarla con seguridad. En un estado externo inesperado, el sistema informa de algo que no coincide con el supuesto del plan. En una interrupción entre pasos, la tarea se detuvo después de uno o más efectos confirmados, pero antes de completar el flujo.

Estas categorías orientan la comprobación siguiente, no una respuesta automática. Si el fallo está confirmado y la operación es segura de repetir, puede ser razonable intentarlo de nuevo. Si el resultado es ambiguo, primero busca evidencia en el sistema afectado. Si la respuesta es inválida o el estado observado contradice el plan, suspende las acciones dependientes hasta aclarar la discrepancia.

Antes de continuar: conserva lo necesario para reconstruir la tarea

Un checkpoint o punto de control resulta útil si permite reconstituir qué pretendía hacer el agente y qué sabe de cada paso. No hace falta guardar todo el razonamiento o cada dato disponible. Conviene conservar la información operativa mínima: identificador de la tarea, objetivo, restricciones relevantes, orden de los pasos, herramienta y operación solicitadas, parámetros necesarios para identificar la operación, resultado recibido, estado de confirmación y última observación del entorno.

Registra cada paso con una condición explícita, por ejemplo: pendiente, solicitado, confirmado, fallido con evidencia o resultado desconocido. Evita condensar esos estados en una sola nota como «acción completada», porque puede borrar la diferencia entre la intención y la confirmación. Si el sistema externo ofrece una forma de consultar el objeto modificado, conserva la clave necesaria para encontrarlo y anota cuándo se observó por última vez.

El checkpoint no demuestra que el mundo externo siga igual. Es una instantánea de lo que el proceso guardó; entre la interrupción y la reanudación, otra persona o sistema puede haber cambiado el registro. Al restaurarlo, vuelve a validar las condiciones que sean necesarias antes de realizar nuevos cambios. La documentación de Microsoft sobre checkpoints de workflows cubre el almacenamiento y la restauración de checkpoints; en una implementación concreta, el equipo debe comprobar qué estado se conserva y cómo se rehidrata.

El diseño debe preservar también los límites de la tarea: qué resultado cuenta como éxito, qué operaciones no deben repetirse y qué condiciones obligan a escalar. Sin esos límites, un agente puede reconstruir los pasos técnicos y aun así continuar en una dirección que ya no sea segura.

Árbol de decisión: reanudar, verificar, replantear, compensar o detenerse

La decisión puede expresarse como un proceso breve. Primero identifica el último paso confirmado y el primero que quedó incierto. Después pregunta si existe una consulta fiable que revele el estado externo. Si la respuesta es sí, consulta antes de actuar. Si no, valora el impacto potencial de una repetición y si hay una vía segura para resolver la ambigüedad. Si tampoco la hay, detente y solicita intervención humana.

Reanudar significa continuar desde un punto conocido, sin volver a ejecutar pasos ya confirmados. Es apropiado cuando el estado guardado es suficiente, las condiciones relevantes siguen vigentes y los pasos pendientes son seguros. Verificar significa consultar el entorno para resolver qué ocurrió, no volver a enviar la misma orden. Replantear significa cambiar el plan porque el estado actual ya no satisface sus supuestos. Compensar significa ejecutar una acción distinta para contrarrestar un efecto previo. Detenerse significa no hacer más cambios hasta obtener una decisión o evidencia suficiente.

La guía de AWS sobre checkpoints para sistemas de agentes advierte que reanudar sin garantías de idempotencia puede duplicar efectos o corromper datos. Esta advertencia refuerza una distinción práctica: guardar un estado de ejecución ayuda a reconstruir el flujo, pero no convierte automáticamente en segura la repetición de una operación.

Efectos parciales: deshacer no siempre significa volver al estado anterior

En una tarea compuesta, algunos pasos pueden haberse completado antes de que falle el siguiente. Si el agente actualiza un registro y luego no puede enviar una notificación, repetir el flujo entero podría aplicar de nuevo el cambio, crear registros duplicados o enviar mensajes repetidos. La recuperación debe partir de los efectos confirmados y decidir qué hacer con cada uno por separado.

Cuando una operación es reversible, identifica de antemano qué significa revertirla y cómo comprobar que la reversión tuvo efecto. No presupongas que «deshacer» elimina todos los rastros ni que el sistema ofrece una vuelta exacta al estado anterior. En algunos procesos, la respuesta apropiada es una acción compensatoria: por ejemplo, corregir un registro mediante una operación nueva en lugar de borrar la operación histórica. Esa compensación puede fallar también y, por tanto, requiere confirmación y límites propios.

El patrón de saga, descrito por AWS para flujos de varios pasos, distingue la recuperación hacia delante —continuar o reintentar— de la recuperación hacia atrás mediante transacciones compensatorias. Es una referencia útil para estructurar procesos distribuidos, pero no implica que todo efecto de un agente tenga una compensación disponible o segura. La elección depende de las reglas del sistema y del impacto de la acción.

Si una acción no se puede revertir de forma fiable, el agente debe tratarla como un límite de riesgo. Puede registrar el efecto, impedir pasos adicionales que lo agraven y pedir revisión. No debe improvisar una compensación que no esté definida para ese caso.

Límites y escalado: señales para detener al agente

Una política de recuperación necesita condiciones de parada explícitas. Entre las señales prácticas están: no poder consultar el estado que decide si una acción ocurrió; observar cambios incompatibles con el plan; recibir respuestas inválidas repetidas; acumular intentos sin progreso confirmado; superar el impacto o el alcance autorizado; o no contar con una compensación fiable para un efecto no deseado. Estas señales son criterios de diseño propuestos, no garantías automáticas de seguridad.

Define también quién recibe el caso, qué información necesita y qué acciones puede autorizar. Un escalado útil debería incluir el objetivo de la tarea, los pasos confirmados, el punto incierto, las comprobaciones realizadas, los efectos externos observados y la opción que el agente habría tomado. Evita presentar como hecho una causa que no se ha podido determinar.

Detenerse no tiene por qué significar abandonar silenciosamente. El agente puede preservar el checkpoint, marcar la tarea como bloqueada y comunicar de forma clara qué falta verificar. Si la interfaz ofrece una acción de reanudación, esta debe volver a comprobar las condiciones pertinentes, no asumir que el entorno sigue en el mismo estado.

Prueba la recuperación con interrupciones controladas

No basta con probar el camino feliz ni con comprobar que el proceso puede restaurar un checkpoint. Simula interrupciones en puntos distintos: antes de enviar una operación, después de enviarla pero antes de recibir respuesta, después de confirmar un efecto y antes del siguiente paso, y después de observar un cambio inesperado. Añade respuestas tardías, inválidas o repetidas si pueden producirse en el entorno que se está evaluando.

Para cada escenario, define de antemano la conducta esperada: qué debe conservarse, qué consulta debe hacerse, cuándo es seguro reanudar y qué condición obliga a escalar. Después compara el resultado real con ese criterio. La evaluación debe incluir errores de exceso de iniciativa —por ejemplo, un duplicado— y de cautela —por ejemplo, una tarea detenida que podía reanudarse con seguridad—.

Como medidas de seguimiento, considera la proporción de tareas que terminan correctamente, los efectos duplicados, los estados inconsistentes, las tareas bloqueadas, el tiempo hasta resolver una ambigüedad y la proporción de escalados que fueron adecuados. Interpreta las métricas junto con la gravedad de cada caso: una tasa baja de duplicados no demuestra que una operación irreversible sea segura.

Usa los resultados para ajustar checkpoints, consultas de verificación, límites de reintento y condiciones de parada. Mantén separados los fallos del agente, de la herramienta y del sistema externo cuando la evidencia permita hacerlo; cuando no, registra la causa como indeterminada en vez de forzar una atribución.

Qué no resuelve esta guía

Esta guía trata la recuperación de una tarea de agente que atraviesa varios pasos y puede modificar sistemas externos. No sustituye el diseño de reintentos de una API, las garantías de idempotencia de una solicitud concreta ni la recuperación de infraestructura. Esos temas siguen siendo importantes: un protocolo de tarea puede apoyarse en ellos, pero no deducir sus garantías si no están documentadas.

La idempotencia se refiere aquí a una propiedad que debe verificarse para la operación específica antes de asumir que repetirla es seguro; no basta con etiquetar toda la tarea como idempotente. Del mismo modo, un checkpoint permite conservar y restaurar información del workflow, pero no confirma por sí solo que el sistema externo aplicó un cambio. La tesis sobre arquitectura multiagente tolerante a fallos es un antecedente de otro alcance: estudia el control de un robot móvil, no constituye una receta directa para agentes conectados a servicios empresariales.

Como criterio práctico final, pregunta en este orden: ¿qué está confirmado?, ¿qué puede verificarse fuera del agente?, ¿qué efectos ya ocurrieron?, ¿qué pasos siguen siendo válidos?, ¿hay una compensación segura?, ¿qué condición obliga a parar? Si alguna respuesta esencial es desconocida y actuar puede agravar el resultado, conserva el estado, detente y escala.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.