Flujos de agentes de IA con aprobación humana y reintentos seguros
Organiza un flujo agente como una máquina de estados observable para que las pausas, reintentos, aprobaciones y recuperaciones sean comportamientos previstos.
Representa el proceso como estados duraderos
Un flujo fiable no es un bucle que pregunta al modelo hasta que aparece una respuesta. Define estados como recibido, investigando, esperando_aprobacion, ejecutando, verificando y cerrado. Cada transición debe declarar su entrada, su condición de salida y quién puede iniciarla. Guarda el estado después de cada efecto confirmado para poder continuar tras un reinicio.
La documentación de Temporal sobre durabilidad muestra el principio general: el proceso debe sobrevivir a fallos de workers. No es obligatorio usar esa tecnología, pero sí conservar la intención y los resultados fuera de la memoria del proceso.
Distingue decisión, autorización y ejecución
El modelo puede recomendar una acción, pero la aplicación verifica políticas y un humano autoriza lo necesario. Después, un ejecutor determinista llama a la API. Separar estas capas evita que una respuesta persuasiva se convierta directamente en un cambio irreversible.
La pantalla de revisión debe enseñar el objeto afectado, el antes y el después, la evidencia, el coste y la fecha límite. Firma o identifica la propuesta aprobada. Si el agente modifica cualquier campo importante, crea una nueva propuesta en vez de reutilizar el permiso.
Reintenta únicamente lo que es seguro repetir
Clasifica los fallos: validación, permisos, límite de uso, dependencia temporal y resultado desconocido. Los dos primeros no se arreglan repitiendo. Para una caída temporal, utiliza espera progresiva, variación aleatoria y un máximo. Si la llamada terminó en timeout, consulta primero el sistema externo porque quizá completó la operación.
Incluye una clave de idempotencia estable por acción. Guarda el identificador devuelto por pagos, correos o trabajos asíncronos. Nunca generes una clave nueva simplemente porque cambió el worker: eso convierte una recuperación normal en duplicados.
Añade límites y rutas de escape
Fija un número máximo de pasos, tiempo, tokens, llamadas y gasto. Un bucle que sigue “investigando” puede consumir presupuesto sin acercarse al objetivo. Cuando se alcanza un límite, conserva el contexto útil, explica la causa y asigna el caso a una persona.
Diseña compensaciones cuando no exista una transacción global. Si se reservó inventario pero falló el cobro, libera la reserva mediante una acción explícita y observable. Una compensación no borra el historial; crea un nuevo evento que restaura una condición aceptable.
Observa el recorrido completo
Usa un identificador de correlación desde el evento inicial hasta cada llamada. Registra versiones de modelo y prompt, herramientas elegidas, latencias, decisiones de política y estados, sin copiar secretos ni datos personales innecesarios. Crea alertas por flujos bloqueados, reintentos repetidos, aprobaciones caducadas y costes fuera de rango.
Prueba el proceso desconectando una dependencia, reiniciando un worker y entregando dos veces el mismo evento. El flujo correcto termina una vez, puede explicarse y no pierde el punto en el que necesita intervención humana.
Preguntas frecuentes
¿Por qué guardar cada etapa del flujo?
Permite reanudar tras un fallo, evitar pasos duplicados y explicar con precisión qué decidió el sistema y con qué evidencia.
¿Cuándo se debe reintentar una herramienta?
Solo ante fallos transitorios conocidos, con límite, espera progresiva e idempotencia; los errores de validación deben corregirse primero.
¿La aprobación puede durar indefinidamente?
No. Debe expirar y quedar ligada a los datos exactos revisados para que un cambio posterior requiera una nueva decisión.