Step Functions como herramientas de agentes: el modelo decide cuándo, el workflow decide cómo

El 29 de octubre de 2026 AWS anunció que los workflows de AWS Step Functions ya se pueden usar como herramientas de agentes de IA a través de Amazon Bedrock AgentCore Gateway. Dicho así parece un conector más, pero cambia una discusión que vengo teniendo con equipos que están llevando agentes a producción: ¿cuánto de un proceso de negocio le dejás decidir al modelo?

La respuesta que propone AWS es bastante sensata. El agente decide cuándo arrancar un proceso y con qué datos. Cómo se ejecuta ese proceso (el orden de los pasos, los reintentos, las aprobaciones, los timeouts) lo sigue definiendo un workflow de Step Functions que vos escribiste, versionaste y probaste. El modelo no puede saltearse la aprobación del gerente porque "le pareció razonable".

En este artículo vemos qué es exactamente el conector, qué operaciones expone, cómo armarlo paso a paso con la AWS CLI, cómo meter un humano en el medio con task tokens, qué trampas encontró la comunidad en las primeras pruebas, cuánto cuesta y si conviene usarlo.

TL;DR

• AgentCore Gateway suma un conector administrado (connectorId: "states") que convierte operaciones de Step Functions en herramientas MCP. No hay que escribir una Lambda intermedia ni un servidor MCP propio.
• Expone diez operaciones: StartExecution, StartSyncExecution, DescribeStateMachine, ListExecutions, DescribeExecution, GetExecutionHistory, StopExecution y los tres SendTask*.
• Con el pin fijás el stateMachineArn en la configuración del target. El agente no lo ve ni lo puede pisar: si lo intenta, el Gateway rechaza la llamada.
• Funciona con workflows Standard y Express, pero varias operaciones (historial, describe, callbacks con task token) solo andan con Standard.
• Todos los targets de un Gateway comparten el mismo rol de servicio. Si necesitás límites de IAM distintos, usá Gateways distintos.
• Está disponible en todas las regiones donde existe AgentCore Gateway, incluida São Paulo. No hay cargo extra: pagás Step Functions y Gateway a precio normal.
• Mi lectura: es la forma más prolija que vi hasta ahora de darle a un agente acceso a procesos que tocan plata, datos o infraestructura.

Por qué ahora

Cualquiera que haya armado un agente con herramientas reales se chocó con el mismo problema. Una herramienta suelta ("emitir crédito", "reiniciar servicio", "borrar usuario") es una invitación a que el modelo la llame en el momento equivocado, con datos incompletos o salteándose un paso previo. El patrón que fuimos adoptando fue meter la lógica de negocio dentro de la herramienta: una Lambda que valida, consulta, decide y recién después ejecuta. Funciona, pero termina siendo un mini orquestador escrito a mano, sin reintentos declarativos, sin historial de ejecución y sin una forma estándar de pausar para que alguien apruebe.

Step Functions ya resolvía todo eso para procesos que no involucran agentes. Lo que faltaba era una forma directa de exponer esos workflows a un agente, con un contrato de herramienta limpio y controles de acceso que no dependan de que el prompt esté bien escrito.

El contexto también ayuda. AgentCore Gateway viene sumando tipos de target (APIs OpenAPI, Lambda, servidores MCP remotos, Smithy) y se está convirtiendo en el punto único por donde los agentes de una organización llegan a sus herramientas. En la misma semana del anuncio, AWS publicó el caso de MoEngage, que expuso unas 400 APIs internas a sus agentes a través de Gateway. Sumar Step Functions como conector administrado es el paso lógico: muchas empresas ya tienen sus procesos críticos modelados como state machines.

Qué es y qué no es

Es un tipo de target administrado de AgentCore Gateway. Creás un target con connectorId: "states", elegís qué operaciones de la API de Step Functions querés exponer, y el Gateway las publica como herramientas MCP con un esquema de entrada acotado. Cuando el agente llama a una herramienta, el Gateway traduce la llamada a la API de Step Functions usando su rol de servicio.

No es:

• Un reemplazo de tus workflows. Vos seguís escribiendo la definición en Amazon States Language (ASL). El agente no diseña el flujo ni lo modifica.
• Un agente dentro de Step Functions. Para el camino inverso (un workflow que invoca a un agente en un paso) existe la integración de Step Functions con AgentCore, que es otra cosa. Las dos se pueden combinar.
• Un control de autorización de negocio. Que el agente tenga permiso para arrancar el workflow de reembolsos no dice nada sobre si ese reembolso tiene sentido. Eso lo resolvés dentro del workflow (validaciones, aprobaciones) y con políticas de AgentCore si las usás.
• Algo nuevo en el plano de datos de Step Functions. Las ejecuciones son ejecuciones normales, con el mismo historial, las mismas métricas y el mismo precio.

Cómo funciona

El recorrido de una llamada es así:

1. El agente (Strands, LangGraph o cualquier cliente MCP) pide tools/list al Gateway y recibe herramientas con nombres del estilo reembolsos___StartExecution. El prefijo es el nombre del target.
2. Decide usar una y manda tools/call con los argumentos. Para StartExecution, por defecto el único argumento visible es input.
3. El Gateway valida al llamador con el autorizador de entrada (IAM con SigV4 o JWT/OAuth), arma la llamada a la API de Step Functions agregando los parámetros fijados (el stateMachineArn) y la firma con su rol de servicio.
4. Step Functions ejecuta el workflow como siempre. La respuesta vuelve como contenido de texto MCP con el JSON de la API (por ejemplo, el executionArn y startDate).

Dos detalles de diseño importan. El primero: el Gateway llama al endpoint de Step Functions de su misma región. Una state machine en otra región no es alcanzable desde el conector. El segundo: todos los targets de un Gateway comparten el mismo rol de servicio. Si exponés en el mismo Gateway un workflow de soporte y otro de operaciones de infraestructura, el rol tiene que poder llamar a los dos, y cualquier agente con acceso a ese Gateway hereda esa superficie. Para separar límites de IAM, la documentación recomienda un Gateway por límite.

Las diez operaciones y el pin

El conector divide las operaciones en dos grupos. Las que aceptan pin trabajan sobre una state machine; las otras trabajan sobre una ejecución o un task token puntual, que el agente tiene que pasar.

Los argumentos que ve el agente también están acotados. Por defecto StartExecution solo muestra input; si querés que el agente pueda poner nombre a la ejecución o propagar un header de trazas, los habilitás con parameterOverrides (name, traceHeader). GetExecutionHistory puede exponer paginación y orden; ListExecutions filtra por estado (RUNNING, SUCCEEDED, FAILED, TIMED_OUT, ABORTED, PENDING_REDRIVE). Lo que no se puede exponer nunca es stateMachineArn: solo se define fijándolo.

Si el agente intenta mandar un stateMachineArn igual, la respuesta es un rechazo con el mensaje Invalid request parameters: cannot set parameter(s): [/stateMachineArn] y no se crea ninguna ejecución. En una prueba publicada en la comunidad AWS Builders, el error llegó como IllegalArgumentException, mientras que las denegaciones de IAM llegaron envueltas en DependencyFailedException. Conviene tenerlo en cuenta si tu agente decide qué hacer según el tipo de error.

Una advertencia que está en la documentación y es fácil de pasar por alto: si exponés una operación que acepta pin y no le fijás el ARN, el target se crea igual, pero la herramienta falla en cada llamada. Revisá la configuración con get-gateway-target antes de darlo por bueno.

Standard o Express: no es un detalle

La elección del tipo de workflow define qué puede hacer el agente después de arrancarlo:

• Standard: el agente puede listar ejecuciones, consultar el estado, leer el historial, detenerlas y completar pasos que esperan un task token. Es lo que querés para procesos largos o con aprobaciones. Una ejecución Standard puede durar hasta un año.
• Express: el agente puede usar StartSyncExecution y recibir el resultado en la misma llamada. Es ideal para procesos cortos tipo "calculá, validá y devolvé". Pero DescribeExecution, GetExecutionHistory y StopExecution fallan con InvalidArn sobre ejecuciones Express, ListExecutions devuelve StateMachineTypeNotSupported, y el patrón .waitForTaskToken directamente no está soportado en Express.

En la práctica, si tu agente necesita "arrancar y volver más tarde a ver cómo terminó", el workflow tiene que ser Standard. El patrón típico para procesos largos es StartExecution seguido de varios DescribeExecution hasta que el estado deja de ser RUNNING.

Humanos en el medio con task tokens

Esta es la parte que más me interesa. Step Functions tiene desde hace años el patrón de callback: un paso con .waitForTaskToken manda un token a algún lado (una cola SQS, un mail, un ticket) y el workflow se queda esperando hasta que alguien llama a SendTaskSuccess o SendTaskFailure con ese token.

Con el conector, ese "alguien" puede ser otro agente, el mismo agente después de consultar a un humano, o un humano a través de una interfaz que use el Gateway. Un caso que veo muy aplicable: un agente de soporte arranca un reembolso; el workflow valida elegibilidad, y si el monto supera un umbral, manda el token a una cola que lee un sistema de aprobaciones. El agente le dice al cliente "tu pedido está en revisión" y no tiene forma de forzar el paso.

El costado delicado es que IAM no permite restringir SendTaskSuccess, SendTaskFailure ni SendTaskHeartbeat a recursos específicos. Se otorgan sobre "*". Eso significa que cualquier agente con acceso a esas herramientas puede completar cualquier tarea de la que tenga el token, incluso de state machines que no están expuestas en el Gateway (la prueba de la comunidad lo confirmó). El token pasa a ser el único control, así que tratalo como un secreto: no lo pongas en el input que ve el agente, no lo loguees y no lo expongas a agentes que no deberían aprobar nada. Mi recomendación: las operaciones SendTask* van en un Gateway separado, que solo usa el agente (o la aplicación) que tiene que aprobar.

Manos a la obra

Vamos con el tutorial oficial, adaptado a un caso un poco más real. Todo se crea en la misma región. Necesitás AWS CLI v2 actualizada (en la prueba de la comunidad, la 2.34.24 rechazó la configuración connector y la 2.39.3 funcionó) y awscurl para firmar las llamadas con SigV4.

aws --version
pip install awscurl
export AWS_REGION=us-east-1
export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

1. La state machine

El tutorial de AWS usa un Pass de "hola mundo". Para ver algo más útil, este es un esqueleto de reembolso con validación en Lambda y aprobación por SQS. Las ARNs de Lambda y la URL de la cola son tuyas.

{
  "Comment": "Reembolso iniciado por un agente: validar, aprobar si supera el umbral, acreditar",
  "StartAt": "ValidarElegibilidad",
  "States": {
    "ValidarElegibilidad": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke",
      "Parameters": { "FunctionName": "validar-reembolso", "Payload.$": "$" },
      "OutputPath": "$.Payload",
      "Retry": [{ "ErrorEquals": ["States.TaskFailed"], "MaxAttempts": 2, "BackoffRate": 2 }],
      "Next": "RequiereAprobacion"
    },
    "RequiereAprobacion": {
      "Type": "Choice",
      "Choices": [{ "Variable": "$.monto", "NumericGreaterThan": 50000, "Next": "EsperarAprobacion" }],
      "Default": "Acreditar"
    },
    "EsperarAprobacion": {
      "Type": "Task",
      "Resource": "arn:aws:states:::sqs:sendMessage.waitForTaskToken",
      "Parameters": {
        "QueueUrl": "https://sqs.us-east-1.amazonaws.com/123456789012/aprobaciones",
        "MessageBody": { "pedido.$": "$", "taskToken.$": "$$.Task.Token" }
      },
      "TimeoutSeconds": 86400,
      "Next": "Acreditar"
    },
    "Acreditar": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke",
      "Parameters": { "FunctionName": "acreditar-reembolso", "Payload.$": "$" },
      "OutputPath": "$.Payload",
      "End": true
    }
  }
}

Fijate dónde quedó cada decisión: el umbral, los reintentos y el timeout de un día están en la definición, no en el prompt. El rol de ejecución de la state machine necesita lambda:InvokeFunction sobre las dos funciones y sqs:SendMessage sobre la cola. Para seguir el tutorial al pie de la letra, podés empezar con el Pass de AWS y después reemplazarlo.

aws stepfunctions create-state-machine \
  --name Reembolsos \
  --type STANDARD \
  --definition file://reembolsos.json \
  --role-arn "arn:aws:iam::${ACCOUNT_ID}:role/ReembolsosExecutionRole" \
  --region $AWS_REGION

2. El rol de servicio del Gateway

La confianza es para bedrock-agentcore.amazonaws.com, acotada a tu cuenta y a tus Gateways:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "bedrock-agentcore.amazonaws.com" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "aws:SourceAccount": "123456789012" },
        "ArnLike": { "aws:SourceArn": "arn:aws:bedrock-agentcore:us-east-1:123456789012:gateway/step-functions-gateway-*" }
      }
    }
  ]
}

Y la política de permisos tiene dos statements, porque las ARNs de ejecución son otro tipo de recurso:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "StateMachineOperations",
      "Effect": "Allow",
      "Action": ["states:StartExecution", "states:ListExecutions", "states:DescribeStateMachine"],
      "Resource": "arn:aws:states:us-east-1:123456789012:stateMachine:Reembolsos"
    },
    {
      "Sid": "ExecutionOperations",
      "Effect": "Allow",
      "Action": ["states:DescribeExecution", "states:GetExecutionHistory", "states:StopExecution"],
      "Resource": "arn:aws:states:us-east-1:123456789012:execution:Reembolsos:*"
    }
  ]
}

Este segundo statement es el que evita que el agente lea ejecuciones de otras state machines aunque tenga una ARN válida. En la prueba de la comunidad, con la política acotada así, las llamadas a ejecuciones de otro workflow fueron denegadas.

3. Gateway y target

aws bedrock-agentcore-control create-gateway \
  --name "step-functions-gateway" \
  --protocol-type MCP \
  --authorizer-type AWS_IAM \
  --role-arn "arn:aws:iam::${ACCOUNT_ID}:role/AgentCoreGatewayToStepFunctions" \
  --region $AWS_REGION

aws bedrock-agentcore-control get-gateway \
  --gateway-identifier "GATEWAY_ID" \
  --query status --output text --region $AWS_REGION

Cuando el Gateway está en READY, agregás el target. Acá elegimos exponer solo cuatro operaciones: arrancar, listar, consultar y leer historial. Nada de StopExecution ni SendTask* para este agente.

SM_ARN="arn:aws:states:${AWS_REGION}:${ACCOUNT_ID}:stateMachine:Reembolsos"

aws bedrock-agentcore-control create-gateway-target \
  --gateway-identifier "GATEWAY_ID" \
  --name "reembolsos" \
  --target-configuration '{
    "mcp": {
      "connector": {
        "source": { "connectorId": "states" },
        "configurations": [
          { "name": "StartExecution", "parameterValues": { "stateMachineArn": "'"$SM_ARN"'" } },
          { "name": "ListExecutions", "parameterValues": { "stateMachineArn": "'"$SM_ARN"'" } },
          { "name": "DescribeExecution" },
          { "name": "GetExecutionHistory" }
        ]
      }
    }
  }' \
  --credential-provider-configurations '[{"credentialProviderType": "GATEWAY_IAM_ROLE"}]' \
  --region $AWS_REGION

Ojo: en la consola no se ve el ARN fijado de cada operación. Para verificarlo, usá aws bedrock-agentcore-control get-gateway-target.

4. Probar desde la terminal

Como el Gateway usa AWS_IAM, cada request va firmado con SigV4. Primero listamos herramientas:

awscurl --service bedrock-agentcore --region $AWS_REGION \
  -X POST "$GATEWAY_URL" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

La respuesta trae reembolsos___StartExecution, reembolsos___ListExecutions, reembolsos___DescribeExecution y reembolsos___GetExecutionHistory (en orden alfabético, no en el orden en que los configuraste). StartExecution anuncia un único argumento, input. Ahora arrancamos una ejecución como lo haría el agente:

awscurl --service bedrock-agentcore --region $AWS_REGION \
  -X POST "$GATEWAY_URL" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0", "id": 2, "method": "tools/call",
    "params": {
      "name": "reembolsos___StartExecution",
      "arguments": { "input": "{\"pedido\": \"A-1029\", \"monto\": 72000}" }
    }
  }'

Fijate que input es un string con JSON adentro, no un objeto. Es la trampa más común cuando el modelo arma los argumentos: si tu agente manda un objeto, la llamada falla. Lo podés reforzar en la descripción de la herramienta o en el prompt del sistema.

Para ver cómo terminó, DescribeExecution con includedData: "ALL_DATA" devuelve también input y output (sin eso, solo metadata):

awscurl --service bedrock-agentcore --region $AWS_REGION \
  -X POST "$GATEWAY_URL" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0", "id": 3, "method": "tools/call",
    "params": {
      "name": "reembolsos___DescribeExecution",
      "arguments": { "executionArn": "EXECUTION_ARN", "includedData": "ALL_DATA" }
    }
  }'

5. Conectarlo a un agente

Para un agente en Python con Strands, la documentación de AgentCore muestra el cliente MCP sobre HTTP con un token Bearer, que es lo que usás cuando el Gateway tiene autorizador JWT (por ejemplo, con Amazon Cognito o tu IdP). La versión limpia:

from strands import Agent
from strands.models import BedrockModel
from strands.tools.mcp.mcp_client import MCPClient
from mcp.client.streamable_http import streamablehttp_client

GATEWAY_URL = "https://<gateway-id>.gateway.bedrock-agentcore.us-east-1.amazonaws.com/mcp"
ACCESS_TOKEN = "<token-oauth>"

def transport():
    return streamablehttp_client(GATEWAY_URL, headers={"Authorization": f"Bearer {ACCESS_TOKEN}"})

mcp_client = MCPClient(transport)

with mcp_client:
    tools = mcp_client.list_tools_sync()
    agent = Agent(model=BedrockModel(model_id="<id-del-modelo>"), tools=tools)
    print(agent("El cliente del pedido A-1029 pide la devolución de 72.000 pesos. Inicialo y decime el estado."))

Si tu Gateway usa IAM como en el tutorial, el cliente tiene que firmar con SigV4; el transporte con token Bearer no sirve tal cual.

Para EKS

Si tus agentes corren en Amazon EKS, la identidad del pod es la que firma las llamadas al Gateway con autorizador IAM. Con EKS Pod Identity asociás un rol al service account del agente y le das solo bedrock-agentcore:InvokeGateway sobre ese Gateway:

aws eks create-pod-identity-association \
  --cluster-name plataforma \
  --namespace agentes \
  --service-account agente-soporte \
  --role-arn arn:aws:iam::123456789012:role/AgenteSoporteInvokeGateway

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "bedrock-agentcore:InvokeGateway",
      "Resource": "arn:aws:bedrock-agentcore:us-east-1:123456789012:gateway/GATEWAY_ID"
    }
  ]
}

Así quedan dos capas separadas: el pod solo puede hablar con ese Gateway, y el Gateway solo puede tocar esas state machines.

Trampas comunes

• CLI vieja. Si create-gateway-target rechaza el bloque connector, actualizá la AWS CLI antes de pensar que el JSON está mal.
• Operación con pin sin ARN. El target se crea pero la herramienta falla siempre. Revisá con get-gateway-target.
• input como objeto. Tiene que ser un string JSON.
• Express con callbacks. Una definición Express con .waitForTaskToken falla con InvalidDefinition.
• Auditoría. En CloudTrail, el llamador que aparece es el rol del Gateway con un nombre de sesión fijo, y el input figura oculto por seguridad. Para saber qué agente y qué conversación arrancaron una ejecución, propagá un identificador propio dentro del input o habilitá traceHeader y correlacioná con las trazas del agente.
• Un rol para todo. Todos los targets comparten el rol del Gateway. Mezclar workflows de distinta criticidad en el mismo Gateway es la forma más rápida de darle a un agente más permisos de los que pensabas.

Un caso de referencia de AWS

Unos días antes del anuncio, el Architecture Blog publicó un ejemplo que muestra el patrón inverso y complementario: un workflow de Step Functions que orquesta la codificación de términos médicos, donde el agente solo razona dentro de un paso acotado y es el workflow el que decide el ruteo según la confianza que reporta el agente.

Las dos piezas se combinan bien: un agente conversacional que dispara workflows por el Gateway, y workflows que adentro invocan agentes para los pasos donde hace falta razonar.

Gateway como punto único de herramientas

El caso de MoEngage, publicado la misma semana, muestra hacia dónde va esto a escala: un equipo de plataforma dueño de la capa MCP, unas 400 APIs internas en siete regiones expuestas como herramientas, políticas Cedar que limitan qué herramientas puede usar cada agente y conectividad privada con VPC Lattice.

Si tu organización va por ese camino, los workflows de Step Functions pasan a ser un tipo de herramienta más dentro del mismo catálogo, con las mismas políticas y la misma observabilidad. Esa es, para mí, la razón de fondo para preferir el conector sobre una Lambda propia que llame a StartExecution.

Precios

No hay un cargo específico por el conector. Pagás Step Functions y AgentCore Gateway a sus tarifas normales. Referencia: US East (N. Virginia).

Ejemplo de costo (cálculo propio, no publicado por AWS): 100.000 reembolsos por mes con un workflow Standard de seis transiciones son 600.000 transiciones; descontando las 4.000 gratuitas, unos USD 14,90. Si por cada reembolso el agente hace un tools/list, un StartExecution y tres DescribeExecution, son 500.000 invocaciones de Gateway: USD 2,50. Total, menos de USD 18 por mes, sin contar las Lambdas, la cola ni los tokens del modelo, que en un agente suelen ser el costo dominante.

Cómo bajarlo en la práctica:

• Express para lo corto. Si el proceso dura segundos y no necesita historial ni aprobaciones, StartSyncExecution sobre Express evita el polling y cobra por request y duración.
• Menos polling. Cada DescribeExecution es una invocación del Gateway y, sobre todo, un turno más del modelo. Si el proceso tarda, mejor que el workflow notifique al final (SNS, EventBridge o un callback a tu aplicación) que tener al agente preguntando cada pocos segundos.
• Menos herramientas. Exponé solo las operaciones que el agente necesita. Cada herramienta extra agrega tokens a cada tools/list que el modelo procesa.

Disponibilidad y lo que conviene mirar con lupa

• Regiones. Está en todas las regiones donde existe AgentCore Gateway. La lista de la documentación incluye South America (São Paulo), así que para quienes estamos en la región hay opción local.
• Misma región. El Gateway solo llama a Step Functions de su propia región. Si tus workflows viven en sa-east-1 pero tu agente usa un modelo que solo está en us-east-1, el Gateway y los workflows pueden quedar en São Paulo y la inferencia ir a otra región. Eso implica transferencia entre regiones y, sobre todo, que el contenido de la conversación sale de Brasil.
• Residencia de datos. El input que arma el agente viaja por el Gateway hacia Step Functions y queda en el historial de ejecución. Si contiene datos personales, tu política de retención y cifrado de Step Functions aplica. Con includedData: "ALL_DATA", además, esos datos vuelven al contexto del modelo.
• Task tokens. Repito porque es lo que más fácil se rompe: SendTask* no admite permisos por recurso.
• Gobernanza. Como bien señala un análisis de Qovery, que la ejecución sea confiable no resuelve si el agente debía arrancarla. Para procesos que cambian producción, el workflow tiene que tener su propio paso de aprobación.

¿Vale la pena?

Para procesos de negocio con pasos fijos, sí, y bastante. El conector resuelve tres cosas que hoy cada equipo resuelve a mano: el contrato de herramienta (qué ve el agente y qué no), el control de acceso por recurso y la trazabilidad de cada ejecución en el historial de Step Functions. Y lo hace sin código propio que mantener.

Donde no lo usaría: para herramientas de una sola llamada (consultar un saldo, buscar un documento), donde un target Lambda u OpenAPI es más simple; y para cualquier cosa que necesite latencia baja en Standard, porque el agente termina haciendo polling.

Mi lectura: lo valioso no es el conector en sí sino el reparto de responsabilidades que impone. El modelo elige cuándo y con qué datos; el workflow define el cómo; IAM y el pin definen el alcance. Es el mismo principio que aplicamos con humanos en operaciones (podés pedir un deploy, pero el pipeline decide los pasos y los gates), llevado a agentes. Lo que me falta es una forma nativa de atar cada ejecución a la sesión del agente que la originó: hoy CloudTrail muestra el rol del Gateway y hay que armar la correlación a mano. Si arrancás, empezá con workflows de solo lectura o de bajo impacto, un Gateway por límite de permisos, y dejá los SendTask* fuera del alcance del agente hasta tener claro quién aprueba qué.

Recursos

• Anuncio en What's New
• AWS Weekly Roundup del 2 de noviembre de 2026
• Tutorial oficial: workflows como herramientas de agentes
• Step Functions como connector target de AgentCore Gateway
• Regiones de AgentCore
• Precios de AgentCore y precios de Step Functions
• Architecture Blog: codificación médica con Step Functions y AgentCore
• Caso MoEngage con AgentCore Gateway
• Prueba de pins, IAM y tokens (AWS Builders en dev.to)
• Análisis de gobernanza de Qovery
• Desplegando.cloud: Tus agentes IA ahora usan Step Functions