Cómo diseñar un workflow agentic de dos fases para que una propuesta nunca se convierta en acción sin validación

Empieza definiendo qué significa una propuesta. Antes de elegir tecnología, crea un esquema que describa la acción candidata sin ejecutarla. Debe incluir tipo de operación, destino, parámetros relevantes, evidencia, fecha, identidad del caso y un identificador estable. Si es una campaña, la propuesta puede contener presupuesto, audiencia y piezas; si es un archivo, origen, destino y hash esperado. La clave es que el objeto pueda guardarse y revisarse. Mientras siga siendo propuesta, ningún campo debe otorgar por sí mismo permiso para producir un efecto externo.

Separa validaciones por fuente de verdad. Lista las condiciones que pueden comprobarse sin pedir opinión al modelo: existencia del recurso, rol del usuario, límite monetario, formato, versión, disponibilidad, lista de destinatarios o estado actual. Implementa cada una como función o servicio con resultados claros. Devuelve pass, fail o needsreview junto con evidencia mínima. Evita un único booleano opaco. Si el proceso se detiene, necesitas saber qué regla falló y si puede resolverse actualizando datos, obteniendo una aprobación o descartando la propuesta.

Haz que el agente no posea la credencial final. El componente que redacta la propuesta debería trabajar con herramientas de lectura o entornos seguros siempre que sea posible. El secreto capaz de publicar, cobrar o modificar producción queda en el ejecutor. Así una inyección de prompt o un error de planificación no puede saltarse validación simplemente llamando otra ruta. El ejecutor acepta únicamente propuestas con firma o estado validado y vuelve a comprobar condiciones críticas que pueden haber cambiado desde la evaluación inicial.

Añade una rama humana solo para excepciones reales. Define qué resultados needsreview requieren juicio: conflicto entre fuentes, impacto alto, primera vez con un destinatario o política sin respuesta determinista. Presenta al revisor la propuesta, las validaciones superadas y la condición pendiente. La decisión humana debe devolver un token o estado específico que se asocia al mismo caso. No permitas que la aprobación cambie silenciosamente otros parámetros. Si el revisor modifica el presupuesto o el destino, crea una nueva versión de la propuesta y vuelve a validar.

Diseña idempotencia antes de pensar en retries. Toda acción externa debe tener una clave que permita reconocer si ya ocurrió. Puede derivarse del identificador de caso y la versión de la propuesta. Antes de ejecutar, consulta el estado externo o una tabla de operaciones. Después de ejecutar, registra el identificador retornado por el proveedor. Si aparece timeout, el recovery verifica primero esa evidencia. Nunca asumas que un error de red significa que la acción no sucedió. Esta disciplina evita publicaciones duplicadas, cobros dobles y mensajes repetidos.

Guarda un decision packet compacto. Para cada ejecución conserva propuesta, versión, resultados de validación, aprobación cuando exista, acción final, identificador externo y timestamps. No necesitas almacenar razonamiento privado. El paquete debe permitir que otra persona reconstruya por qué el sistema actuó y qué controles pasaron. Añade hash del artefacto cuando sea relevante. Este registro sirve para soporte, auditoría y mejora de reglas, y puede convertirse en una poderosa evidencia comercial de cómo la plataforma gobierna autonomía.

Prueba el workflow con fallos deliberados. Crea casos donde el recurso desaparece, cambia el presupuesto, expira una aprobación, se repite un callback o el proveedor responde tarde. Confirma que la propuesta se conserva, que la validación detecta el cambio y que el ejecutor no duplica efectos. Solo después prueba el camino feliz a escala. Un sistema agentic confiable no se demuestra porque completó una demo una vez; se demuestra cuando falla en puntos previsibles y conserva la capacidad de reanudar sin improvisar una nueva decisión.