Para recuperarte de fallos en un flujo con agentes, no conviene repetir todo a ciegas. Diseña reintentos limitados solo para errores transitorios, protege las acciones contra duplicados y guarda un punto claro desde el que continuar. Si falta un dato o no se sabe si una acción llegó a completarse, el flujo debe pausarse y pasar el caso a una persona con contexto suficiente para resolverlo.
Reintentar solo errores que pueden cambiar
Hecho: la documentación de AWS explica que los estados de Step Functions pueden configurar una cantidad máxima de reintentos, intervalos entre intentos y un multiplicador de espera; también permite capturar un error y dirigir el flujo a una ruta de manejo. AWS documenta esos controles en “Handling errors in Step Functions workflows” (sin fecha; consultada 2026-10-03): https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html. La documentación de Temporal distingue fallos transitorios o intermitentes de errores permanentes, como datos de entrada inválidos, que no se resuelven repitiendo la misma operación (“What is a Temporal Retry Policy?”, sin fecha; consultada 2026-10-03): https://docs.temporal.io/encyclopedia/retry-policies.
Interpretación práctica: clasifica antes de insistir. Un corte breve de red podría justificar unos pocos reintentos con espera creciente; un campo obligatorio ausente, un permiso denegado o una respuesta del agente que no cumple el formato esperado necesita otra solución. Para cada paso, fija un límite de intentos y un tiempo total máximo. Al agotarlos, detén la repetición y registra la causa. No hay un número universal: depende del costo de volver a ejecutar, de la duración del servicio externo y de cuánto tiempo puede esperar el negocio.
Evita una regla amplia como “reintentar ante cualquier error”. Hecho: el libro Site Reliability Engineering de Google advierte que los reintentos pueden amplificar una sobrecarga y recomienda espera exponencial aleatoria y un límite por solicitud (“Addressing Cascading Failures”, sin fecha; consultada 2026-10-03): https://sre.google/sre-book/addressing-cascading-failures/. Interpretación práctica: usa una espera progresiva y un límite; al agotarlos, la ruta de salida debe dejar el flujo en un estado visible, no ocultar el fallo como si hubiera tenido éxito.
Evitar que un intento repetido duplique una acción
Hecho: Temporal define la idempotencia como obtener el mismo resultado al repetir una solicitud y advierte que la ejecución de una actividad puede reintentarse después de un fallo o tiempo de espera, incluso si una operación externa tuvo éxito parcial. Su publicación original también explica el uso de claves de idempotencia constantes entre reintentos para reconocer una operación ya procesada: Keith Tenzer y Joshua Smith, Temporal, “What is idempotency? And why it matters for durable systems”, 27 de febrero de 2024: https://temporal.io/blog/idempotency-and-durable-execution.
Interpretación práctica: antes de repetir un paso que crea, envía, reserva o modifica algo, pregunta qué pasa si la primera llamada sí llegó al destino, pero se perdió la confirmación. Si el servicio receptor admite una clave de idempotencia, usa la misma clave para todos los reintentos de esa operación; no generes una nueva cada vez. Si existe un registro propio de operaciones, guarda la clave junto al estado y resultado. La clave debe identificar la acción concreta, no una tarea genérica que pueda abarcar varias ejecuciones.
Por ejemplo, en un escenario hipotético, un agente intenta abrir una orden interna de trabajo y recibe un tiempo de espera. Antes de crear otra, el flujo busca la misma clave o consulta si la orden ya existe. Si no puede comprobarlo y el sistema receptor no evita duplicados, deja el caso pendiente de confirmación humana. Una búsqueda posterior también puede tener condiciones de carrera: no reemplaza una clave admitida por el destino ni garantiza por sí sola que dos ejecuciones simultáneas no creen lo mismo.
Guardar estados desde los que se pueda retomar
Hecho: Temporal indica que conserva el estado e historial de eventos de un flujo y recomienda reintentar la actividad fallida en vez de repetir sin necesidad la ejecución completa. AWS describe una función de redrive para flujos Standard que reanuda desde el estado fallido, usando la misma definición e información de entrada de la ejecución original. Esas son capacidades documentadas de productos concretos, no una garantía universal de cualquier plataforma: AWS Compute Blog, Benjamin Smith, “Introducing AWS Step Functions redrive to recover from failures more easily”, 15 de noviembre de 2023: https://aws.amazon.com/blogs/compute/introducing-aws-step-functions-redrive-a-new-way-to-restart-workflows/; Temporal, “What is a Temporal Retry Policy?” (sin fecha; consultada 2026-10-03): https://docs.temporal.io/encyclopedia/retry-policies.
Interpretación práctica: modela el proceso como etapas con nombres comprensibles, por ejemplo “recibido”, “validando”, “acción enviada”, “confirmación pendiente”, “completado” y “requiere revisión”. Conserva el identificador de la ejecución, la etapa actual, los datos de entrada relevantes, el resultado conocido y el último error. No marques una acción como completada solo porque el agente preparó una solicitud: distingue entre preparada, enviada y confirmada. Al reanudar, vuelve a validar que los datos no hayan cambiado desde la pausa y retoma desde la primera tarea realmente pendiente.
Un estado recuperable no significa que todo se pueda continuar automáticamente. Si la versión de la instrucción, los permisos o los datos de entrada cambiaron, una reanudación puede producir un resultado distinto. Registra qué cambió y exige una nueva comprobación antes de ejecutar acciones dependientes de esos datos.
Pausar de forma segura ante incertidumbre
Interpretación práctica: trata la incertidumbre como un estado del proceso, no como una invitación a que el agente adivine. Si faltan datos esenciales, dos fuentes discrepan, la salida no pasa una validación o no se confirma el efecto externo, cambia el flujo a “en espera de verificación”. Bloquea solo las etapas que dependen de esa respuesta; conserva el trabajo anterior que sí quedó confirmado y no repitas acciones irreversibles.
Al derivar a una persona, presenta lo mínimo necesario para decidir: qué intentó el agente, qué resultado está confirmado, qué sigue incierto, qué se detuvo y qué opciones de reanudación existen. Asigna responsable y plazo de revisión, y mantén el flujo detenido hasta que esa persona corrija el dato, confirme el resultado o cierre la ejecución. Esta es una recomendación de diseño para recuperar el proceso, no una guía general sobre qué decisiones debe aprobar una persona.
Prueba la recuperación antes de depender de ella
Ensaya fallos controlados en un entorno de prueba: un error transitorio, datos incompletos, respuesta tardía después de que el destino aceptó la solicitud y un error que requiere corregir configuración. Comprueba que el límite se cumple, que la misma clave no genera duplicados, que la pausa conserva el contexto y que una persona puede reanudar sin repetir pasos completados. Registra también quién cambió el estado y cuándo.
Como primer paso concreto, escoge un flujo acotado y dibuja sus estados, los errores que sí pueden reintentarse y las acciones con efecto externo. Añade para cada una un límite, una protección contra duplicados y una salida de pausa. Si el flujo falla, el equipo debería poder contestar tres preguntas: qué ocurrió, qué es seguro repetir y quién puede resolver lo incierto. Para profundizar en el criterio de intervención humana, consulta la guía de Jarvis: https://www.jarvisrd.com.do/blog/aprobacion-humana-ia-no-decide-sola.