Ingeniería de IA
AgentCore y Step Functions: el agente elige cuándo, tú defines el proceso
El nuevo conector de AWS convierte workflows en herramientas MCP. Cómo separar decisiones del agente, pasos obligatorios, permisos y aprobaciones al elegir Standard o Express.
Una herramienta que ejecuta un proceso completo
AWS anunció el 29 de octubre que los workflows de Step Functions pueden exponerse como herramientas de agentes mediante AgentCore Gateway. El agente decide cuándo iniciar el trabajo y aporta los datos. La máquina de estados conserva los pasos y las condiciones que has definido.
El conector genera los esquemas MCP y llama a Step Functions con el rol del Gateway. No hace falta escribir un servidor MCP o una Lambda intermediaria para esa conexión. Puedes aprovechar workflows Standard y Express existentes, seleccionando qué operaciones quieres exponer.
El destino se configura antes de que el modelo actúe
Para iniciar un workflow, fijas su stateMachineArn en la configuración del conector. Ese identificador no aparece como parámetro que el agente pueda cambiar. Si intenta enviarlo, el Gateway rechaza la llamada. La entrada del proceso sigue necesitando su propia validación: fijar el destino no convierte cualquier JSON en una solicitud válida.
La consulta y el control tienen otro límite. DescribeExecution, GetExecutionHistory y StopExecution reciben un ARN de ejecución aportado por el agente. Su alcance depende de la política IAM del rol del Gateway. Limitar el workflow de inicio no basta para restringir todas las ejecuciones que podría leer o detener.
Un ejemplo con notas de una versión
Un equipo quiere que su agente prepare la publicación de unas notas de versión. El proceso propuesto valida los campos y el destino, espera una revisión autorizada y publica después. El agente puede iniciar la solicitud y consultar su estado. No necesita decidir de nuevo si la revisión es obligatoria cada vez que el usuario pide ir más rápido.
Una simulación local comprueba esa lógica: publicar antes de la revisión falla, añadir approved=true a la entrada tampoco autoriza y repetir una publicación con el mismo identificador no crea otra. Es una demostración con datos sintéticos, sin ejecutar Step Functions ni probar permisos de AWS.
La repetición requiere especial atención si se pierde la respuesta de una herramienta. Conviene conservar el identificador del trabajo y hacer que la operación final reconozca solicitudes ya procesadas. Un recorrido bien definido puede recibir dos solicitudes de inicio; eso no convierte automáticamente sus efectos externos en una única publicación.
Standard y Express no ofrecen el mismo seguimiento
Standard encaja cuando el trabajo debe durar, conservar historial y esperar un callback. Puede ejecutarse hasta un año. Express admite trabajos de hasta cinco minutos y permite devolver el resultado en la misma llamada con StartSyncExecution.
En este conector, las herramientas para describir ejecuciones, leer su historial y detenerlas son de Standard. Tampoco puedes trasladar a Express una espera con task token: no soporta ese patrón. Elegir Express por su duración prevista sin revisar estas diferencias puede dejar al agente sin el seguimiento que necesita.
| Necesidad | Standard | Express |
|---|---|---|
| Consultar ejecución e historial por estas herramientas | Sí | No |
| Esperar callback con task token | Sí | No |
| Resultado con StartSyncExecution | No | Sí |
La aprobación tiene que conservar su autoridad
El patrón de callback permite pausar el workflow hasta que un componente devuelva un task token con el resultado. Puede servir para una revisión humana o para un trabajo realizado por otro servicio. El token debe llegar al componente que tiene autoridad para completar ese paso.
SendTaskSuccess, SendTaskFailure y SendTaskHeartbeat no admiten restricciones IAM por recurso: sus permisos se conceden sobre *. AWS pide tratar esos tokens como secretos. Si una aprobación pertenece a una persona, no entregaría al agente su token ni la capacidad de resolver ese mismo paso. Las herramientas expuestas deberían corresponder a su papel real en el proceso.
Dónde aporta y qué probaría antes de usarlo
Este enfoque aporta cuando el agente interpreta una petición variable, pero el trabajo debe respetar una secuencia conocida. Antes de integrarlo probaría entradas incompletas, una revisión rechazada, un ARN fuera de alcance y la repetición de una solicitud. El agente debería consultar el estado real y explicar el fallo, en lugar de inventar que el proceso terminó.
El conector está disponible donde lo está AgentCore Gateway y llama a Step Functions en su misma región. Hay costes de Gateway y Step Functions, además de los servicios que ejecute tu flujo. Para una operación breve con una API clara, añadir una máquina de estados puede ser más trabajo del que resuelve. Para una secuencia con revisión y recuperación, la separación tiene bastante más sentido.