AWS Step Functions Workflows Become AI Agent Tools Through AgentCore Gateway: The State Machine Fixes the Step Order

On October 29, 2026, AWS announced that AWS Step Functions workflows can now be used as tools by AI agents through Amazon Bedrock AgentCore Gateway. The agent decides when to run a workflow and what input to pass, and Step Functions runs each step exactly as defined. Existing Standard and Express workflows can serve as tools, and you pay standard rates for Step Functions and AgentCore Gateway.

The value is in the division of labor. AgentCore Gateway connects agents to tools through the Model Context Protocol (MCP), and Step Functions executes multi-step business processes in a fixed order. AWS's example is a customer support agent that starts a refund workflow, where Step Functions runs the eligibility check, manager approval and credit steps so every refund follows policy. An operations agent can also look up workflow runs and tell an on-call engineer which orders failed overnight and at which step. The announcement says Step Functions can orchestrate over 220 AWS services, which is AWS's own figure. The capability is available in all Regions where AgentCore Gateway is available.

The developer guide explains how it works. When you create a gateway target you choose the built-in Step Functions connector. You write no Lambda function or MCP server and define no tools yourself, because the gateway creates the tool schemas and calls Step Functions for the agent. The connector exposes ten operations. Four act on a state machine that you pin when you create the target: StartExecution, StartSyncExecution, ListExecutions and DescribeStateMachine. The agent cannot see or change the pinned state machine, and if it passes stateMachineArn the gateway rejects the call. The other six act on an execution ARN or a task token that the agent supplies: DescribeExecution, StopExecution, GetExecutionHistory, SendTaskSuccess, SendTaskFailure and SendTaskHeartbeat. They are not limited to the pinned state machine, so only the gateway service role's IAM policy constrains them.

The permission boundary deserves attention. The documentation advises scoping that policy as tightly as possible, for example limiting DescribeExecution, StopExecution and GetExecutionHistory to the execution ARNs of the state machines you expose, rather than granting states:*. The three SendTask operations have no resource-level permissions in IAM and must be granted on "*", so the task token is the only control, and tokens should be treated as secrets. If a pinnable operation is included without a stateMachineArn, the gateway can still create the target, but the tool fails on every call.

The two workflow types support different operations. StartSyncExecution works only with Express and fails on Standard. ListExecutions works only with Standard and returns StateMachineTypeNotSupported on Express. DescribeExecution, GetExecutionHistory and StopExecution work only with Standard executions, because Express executions cannot be addressed by ARN after they start. StartExecution, DescribeStateMachine and the SendTask operations work with both. Standard workflows record every step in an execution history and can run for up to one year, which suits long processes that need audit or human approval: a workflow pauses on .waitForTaskToken, hands the token to the agent's application, and the agent calls SendTaskSuccess or SendTaskFailure to resume it. Express with StartSyncExecution suits synchronous request and response. Here, “both” describes connector operations; .waitForTaskToken callbacks themselves require Standard workflows and are not supported by Express.

The tutorial uses a Standard state machine with a single Pass state and makes the same MCP calls an agent would, using awscurl. All resources must be created in the same Region, because the gateway calls Step Functions in its own Region, and the tutorial resources incur state-transition and tool-call charges until deleted. The AWS pages give no latency, scale or customer figures, so this is a capability description, not a performance report. Its practical value depends on whether your workflows are already well defined and on how tightly you scope the gateway role.