Blog · Guía · 28 de octubre de 2026
Cómo dar a un orquestador un paso de aprobación: un patrón, con AEGIS como ejemplo práctico
Aviso: en 100monkeys.ai construimos AEGIS, el ejemplo práctico de esta guía, así que lee las partes sobre AEGIS como el relato de quien lo fabrica. El patrón en sí es general y sirve para cualquier orquestador. La redactó uno de nuestros agentes de IA a partir de la documentación pública de AEGIS y la revisó la empresa; esta versión en español es una traducción de la guía original en inglés.
Un paso de aprobación es un punto de una ejecución automatizada en el que el trabajo se detiene, una persona lee exactamente lo que está a punto de ocurrir y la ejecución solo continúa con su respuesta. Casi todos los orquestadores pueden hacer una pausa. Menos consiguen que la pausa se sostenga. Este es el patrón que usamos, paso a paso, con AEGIS by 100monkeys.ai, in beta, como ejemplo práctico.
El patrón en un párrafo
Pon la compuerta después de que el agente haya preparado el acto y antes de que el acto ocurra. Muestra a quien revisa la cosa preparada, no un resumen. Decide de antemano qué significa el silencio. Enruta las dos respuestas de forma explícita. Deja que quien revisa responda desde donde ya está y guarda la respuesta en el historial de la ejecución. Acota los reintentos para que un borrador rechazado no pueda dar vueltas para siempre.
Paso 1. Enumera los actos que necesitan a una persona
No todos los pasos necesitan una compuerta; una compuerta en todo enseña a la gente a aprobar sin leer. Pon compuerta a los actos que salen del sandbox y no se pueden deshacer: enviar un mensaje a alguien de fuera, fusionar en una rama protegida, gastar dinero, borrar datos, publicar. Todo lo demás puede ejecutarse bajo una política escrita de antemano. Nuestro artículo Red levers (en inglés) llama a esto los dos tipos de parada: límites fijados antes de la ejecución, que aplica el runtime, y una aprobación en el acto, ligada a un solo acto.
Paso 2. Divide el trabajo del agente en el acto
Un agente que redacta y envía en un solo paso no se puede detener a mitad. Divídelo en un estado que prepara y un estado que actúa, para que la compuerta tenga dónde estar. En AEGIS un workflow es una máquina de estados declarativa, y la compuerta es un estado propio, kind: Human:
spec:
initial_state: DRAFT
states:
DRAFT:
kind: Agent
agent: draft-agent
transitions:
- condition: on_success
target: APPROVE
APPROVE:
kind: Human
prompt: |
About to send:
{{DRAFT.output}}
Approve? (yes/no)
timeout: 86400s
transitions:
- condition: input_equals_yes
target: SEND
- condition: input_equals_no
target: DISCARDLa forma sigue la página Building Workflows de la documentación de AEGIS; draft-agent, SEND y DISCARD representan tu propio agente y tus propios estados.
Paso 3. Pon delante de quien revisa la cosa exacta
El mensaje de la compuerta es todo lo que ve quien revisa, así que incrusta en él la salida preparada. Los mensajes de AEGIS admiten plantillas de Blackboard: {{DRAFT.output}} arriba es la salida del estado anterior, y la documentación también muestra puntuaciones de estados anteriores, como {{QUALITY_CHECK.output.score}}. Quien ve "el agente quiere enviar un correo" está aprobando una descripción; quien ve el correo está aprobando el correo.
Paso 4. Decide qué significa el silencio
Toda compuerta necesita un timeout y una regla para cuando vence. En la página Human Approvals, timeout_seconds vale 3600 por defecto. Con reject_on_timeout: false, el valor por defecto, una compuerta sin respuesta hace fallar la ejecución con human_input_timeout. Con reject_on_timeout: true, el silencio cuenta como un no y la ejecución toma la ruta de rechazo. Elige la segunda opción cuando una respuesta ausente deba ser un no limpio y no un error. Nunca hagas del silencio un sí.
Una nota sobre los campos: la página Human Approvals usa timeout_seconds y las condiciones approved y rejected; la página Building Workflows usa timeout e input_equals_yes e input_equals_no. Usa una sola forma de manera coherente y consulta la Workflow Manifest Reference de la versión que ejecutas.
Paso 5. Enruta las dos respuestas y acota el bucle
Un no es una respuesta, no un fallo que gestionar más tarde. Dale un estado de destino: descartar, o devolver el borrador al agente con los comentarios de quien revisó. Si devuelves un rechazo al estado de redacción, la ejecución tiene ahora un bucle. AEGIS lo acota: max_state_visits por estado (5 por defecto, máximo 20) y max_total_transitions por ejecución (50 por defecto, máximo 100). Ajústalos al número de intentos que quien revisa esté dispuesto a tolerar.
Paso 6. Deja que quien revisa responda desde donde está
Una compuerta que nadie ve es un timeout. En AEGIS la misma compuerta se puede responder de tres formas:
- Desde la línea de comandos:
aegis workflow signal <execution-id> --response yes. - Desde tu propio cliente: lista las compuertas en espera con
GET /v1/workflow-gates?status=pendingy responde a una conPOST /v1/workflows/executions/{id}/signal, con un cuerpo como{ "response": "yes", "feedback": "Keep the flag name short." }. - En Zaru Web: una compuerta de una ejecución que tú iniciaste aparece entre tus aprobaciones pendientes, con un botón por cada palabra permitida. La documentación añade que al acompañante de Zaru no se le ofrece ninguna herramienta que responda a una compuerta, en ningún modo, así que el modelo que preparó el acto no puede aprobarlo.
Esa última propiedad es la que hay que buscar en cualquier orquestador: el agente no debe tener la llave de su propia compuerta.
Paso 7. Guarda la respuesta
Una aprobación es una prueba. Después de que una compuerta se responde o vence, AEGIS la sigue listando: ?status=answered devuelve cada compuerta con la palabra elegida, los comentarios, cuándo se cerró y qué hizo la ejecución entonces. Registra también quién respondió; el endpoint de aprobación de la página Human Approvals acepta un campo approved_by, y un rechazo exige un reason.
Paso 8. Prueba la compuerta antes de confiar en ella
Ejecuta el workflow tres veces: responde sí, responde no y déjala vencer. Confirma que cada ruta llega donde querías y que nada posterior a la compuerta se ejecutó antes de la respuesta. Después cambia el borrador cuando la compuerta ya esté publicada y confirma que quien revisa ve lo que de verdad se va a ejecutar. Si tu orquestador liga la aprobación a una descripción en lugar de al contenido, aquí es donde lo descubres.
Hacia dónde seguir
Para probar el patrón de principio a fin en un servidor propio, sigue Instala AEGIS en un VPS Ubuntu nuevo y ejecuta tu primera tarea aprobada. Para saber qué registrar y firmar alrededor de cada compuerta, lee Lista de trazabilidad para agentes de IA en producción. Para la misma idea de aprobación en un asistente personal, consulta Configura un asistente Zaru que gestione tu correo y tu calendario con aprobaciones.