← Todos los insights

Análisis de noticiaEnfoque: España y Latinoamérica3 min de lectura

Los agentes de IA ya pueden iniciar workflows de Step Functions: el agente decide, el workflow ejecuta

Los workflows de Step Functions ya pueden exponerse a agentes de IA mediante AgentCore Gateway y MCP, con una línea clara entre lo que decide el modelo y lo que ejecuta código probado.

Escuche este artículo · 4 min

Narración completa del artículo, generada con IA.

Una escalera de caracol vista desde abajo hacia un tragaluz de vidrio, en duotono La Madre, junto a las palabras Pasos que ya son tuyos
Foto: Wilfredor (Wikimedia Commons, CC0)

Lo más arriesgado que puede hacer un agente empresarial es improvisar un proceso que ya existe. Un reembolso tiene una verificación de elegibilidad, la aprobación de un responsable y un abono asentado en un orden concreto. Cuando se le entregan al agente las API sueltas y se le pide que deduzca el orden, normalmente acierta. «Normalmente» es el problema.

El anuncio de AWS del 29 de octubre propone otra disposición. Los workflows existentes de AWS Step Functions, Standard y Express, ya pueden exponerse como herramientas a agentes de IA a través de Amazon Bedrock AgentCore Gateway, que habla MCP. El agente decide cuándo ejecutar un workflow y qué entrada pasar. Step Functions ejecuta cada paso exactamente como se definió.

La línea que marca

Quién decide qué cuando un agente llama a un workflow

El agente

  • Entiende la petición
  • Elige el workflow
  • Aporta la entrada
  • Lee el estado de la ejecución

Probabilístico

El workflow

  • Verificación de elegibilidad
  • Paso de aprobación humana
  • Reintentos y rutas de error
  • Llamadas a más de 220 servicios de AWS

Definido y probado de antemano

Los sistemas de registro

  • El abono asentado
  • El historial de ejecución

Lo que leen los auditores

Basado en el anuncio de AWS del 29 de octubre de 2026. El ejemplo del reembolso es el que usa AWS.

El ejemplo de AWS es un agente de soporte que activa un workflow de reembolso que recorre los pasos de elegibilidad, aprobación del responsable y abono. El agente nunca toca la API de abono directamente. Tampoco puede saltarse la aprobación, porque la aprobación es un estado del workflow, no una instrucción del prompt.

La segunda capacidad es más silenciosa y útil en operaciones: los agentes pueden consultar ejecuciones de workflows. Un agente puede responder «qué ejecuciones fallaron durante la noche y en qué paso» a partir del historial de ejecución en lugar de reconstruirlo desde los logs.

La disponibilidad sigue las regiones de AgentCore Gateway y el precio es la tarifa estándar de ambos servicios.

Por qué esta es la forma correcta

Sostenemos que un agente bien llevado hace innecesarias partes de sí mismo: cuando un camino de razonamiento se repite, debería convertirse en software corriente y salir del modelo. Step Functions como herramienta es la otra mitad de esa idea. La organización no tiene que convertir nada; ya tiene workflows que codifican sus procedimientos, probados y versionados, a menudo con pasos de aprobación que compliance firmó hace años. El agente se convierte en una nueva forma de iniciarlos, no en un sustituto de ellos.

Es también la frontera que describimos en la disputa por la capa que autoriza la transacción. El razonamiento se está volviendo portátil entre proveedores; la autoridad para comprometer una transacción debería quedarse con el sistema que la posee. Una máquina de estados con su propio rol de IAM e historial de ejecución es un lugar razonable para que viva esa autoridad.

Lo que no arregla

Quién puede iniciar el workflow. Exponer un workflow como herramienta lo vuelve invocable por cualquier agente que el gateway permita. La pregunta pasa de «¿puede el agente hacer los pasos?» a «¿debería este agente, actuando para este usuario, poder iniciar este workflow?». Eso necesita una política en el gateway, ligada a la identidad que hay detrás de cada llamada a herramienta, no solo al rol del propio workflow.

Validación de la entrada. El agente aporta la entrada. Un workflow que confiaba en sus llamadores de siempre, porque eran sistemas internos con esquemas fijos, ahora recibe valores elegidos por un modelo. Valide en el primer estado como si el llamador no fuera de confianza, porque en parte no lo es.

Ejecuciones duplicadas. Los agentes reintentan. Un orden de ejecución definido no garantiza efectos de una sola vez en sistemas externos. Reembolsos, pagos y notificaciones necesitan claves de idempotencia para que la segunda llamada devuelva el primer resultado en lugar de pagar dos veces.

Workflows escritos para personas. Algunos workflows dan por hecho que un operador humano notará un resultado extraño entre paso y paso. Un agente no lo hará. Revise qué workflows son seguros de exponer antes de exponerlos, empezando por los de solo lectura y los reversibles.

Nada de esto argumenta contra la funcionalidad. Argumenta a favor de tratar el catálogo de workflows como una superficie de autorización: una lista explícita de qué procedimientos pueden iniciar los agentes, para quién y con qué entradas. Los equipos que ya ejecutan sus procesos críticos en máquinas de estado tienen ventaja. Los que no, ahora tienen una razón más para empezar.

¿Tiene un caso de uso de IA detenido entre el prototipo y la producción?

Cuéntenos qué quiere poner en marcha. Le respondemos con próximos pasos honestos.

Conversemos sobre un caso de uso