Your Step Functions Workflows Are Now AI Agent Tools

AI agents on AWS can now run your existing Step Functions workflows as tools. Since Oct 29, 2026, Amazon Bedrock AgentCore Gateway has a built-in Step Functions connector that turns a state machine into Model Context Protocol (MCP) tools, with no Lambda function or custom MCP server to write. The agent decides when to start a workflow and what input to pass; the state machine decides which steps run, in what order.

That split is the point. If a refund, onboarding or deployment has to follow an approved sequence every time, you can let an agent trigger it without letting the agent improvise it. Here is how the connector works, where it bites, and how to lock it down.

What AWS shipped on Oct 29

• A new Gateway target type. You add a target with connector ID states and list the Step Functions operations you want exposed as tools. The gateway generates the tool schemas and calls Step Functions with its own service role.
• Existing workflows, unchanged. Both Standard and Express state machines work without edits, according to AWS.
• Ten operations. Start, monitor, stop and inspect executions, plus the task-token calls that let a paused workflow wait for an agent.
• Standard pricing. No new fee: you pay normal Step Functions and AgentCore Gateway rates. It is available in every Region where AgentCore Gateway is.

It also completes a loop AWS started in June, when Step Functions gained a step that runs an AgentCore agent (the managed harness, then in preview) from inside a workflow. Now the direction also runs the other way: workflows can call agents, and agents can call workflows.

How the connector works

The ten operations fall into two groups, and the difference matters for security.

• Pinned to one state machine: StartExecution, StartSyncExecution, ListExecutions and DescribeStateMachine. You set the state machine ARN when you create the target. The agent never sees it, and the gateway rejects any call that tries to pass a different one. Each operation takes one pin per target, so exposing three workflows means three targets.
• Driven by the agent: DescribeExecution, StopExecution and GetExecutionHistory take an execution ARN, and SendTaskSuccess, SendTaskFailure and SendTaskHeartbeat take a task token. These are not limited by the pin. Only the gateway's IAM role limits what they can reach.

A typical agent run is three calls: StartExecution with a JSON input, then DescribeExecution with the returned ARN until the status is no longer RUNNING, then GetExecutionHistory to explain what happened. Tool names are prefixed with the target name, such as orders___StartExecution. By default the agent can set only a minimal set of fields, for example just input on StartExecution; you can expose extras such as an execution name or page size with parameterOverrides.

The second pattern is human-in-the-loop in reverse. A Standard workflow pauses on a .waitForTaskToken task, your app hands the token to the agent (for example through an SQS queue), and the agent resumes the workflow with SendTaskSuccess or SendTaskFailure.

Standard or Express: pick before you wire it up

Several operations only work with one workflow type. These errors come from Step Functions itself, not the connector, so an agent will hit them at run time rather than at setup.

• StartSyncExecution: Express only. It returns the result in the same tool call, which suits quick request-response tasks.
• ListExecutions, DescribeExecution, GetExecutionHistory, StopExecution: Standard only. Express executions can't be addressed by ARN after they start.
• Task-token callbacks: Standard only, because Express workflows don't support the callback pattern.
• Works on both: StartExecution, DescribeStateMachine and the three task-token calls.

If you want both behind one target, AWS's advice is to pin StartSyncExecution to an Express state machine and the other pinnable operations to a Standard one. For anything an operations agent needs to inspect later, use Standard: it keeps a full execution history and can run for up to a year, so work continues after the agent's session ends.

The security model: pins plus IAM

Pinning stops an agent from starting the wrong workflow. It does not stop an agent from describing, stopping or reading the history of other executions in your account. That is the IAM role's job, and AWS's docs are explicit that the two controls are complementary.

• Scope the service role to your executions. The AWS tutorial grants the start and list actions on one state machine ARN, and the describe, history and stop actions on that state machine's execution ARNs only, not states:*.
• Treat task tokens as secrets. IAM has no resource-level permissions for SendTaskSuccess, SendTaskFailure or SendTaskHeartbeat, so they must be granted on "*". Any agent holding a valid token can complete that task.
• One gateway per trust boundary. All targets on a gateway share its service role. If two workflows need different IAM limits, give them separate gateways.
• Audit trail comes free. Executions started through the gateway appear in the Step Functions console like any other, with the gateway's service role as the caller in CloudTrail.

The same rule applies here as with coding agents: give the agent the narrowest credentials that still let it do the job. We covered that pattern in how to stop AI coding agents leaking secrets.

What it costs

There is no connector fee. AgentCore Gateway lists API invocations such as ListTools and InvokeTool at $0.005 per 1,000 on its pricing page (checked Oct 30, 2026). Step Functions bills as usual: Standard workflows per state transition, including retries, with 4,000 free transitions a month; Express workflows per request and duration. See the Step Functions pricing page for your Region. In practice the workflow and the model will dominate the bill, not the gateway calls.

Why this beats a hand-built tool, and when it doesn't

Before this, exposing a workflow to an agent usually meant a Lambda function or a small MCP server that wrapped the Step Functions API, with its own schema, auth and error handling to maintain. The connector removes that layer and makes the safe pattern the default: the agent picks the moment and the input, and the state machine enforces the order, retries and approvals.

• Good fit: policy-bound processes (refunds, account changes, data jobs), operations assistants that answer which runs failed overnight and why, and any flow that needs a human approval step.
• Weaker fit: workflows in another Region (the gateway only calls Step Functions in its own Region), agents that need many workflows (one target per pinned operation adds up), and fast lookups where a direct API tool is simpler.
• Lock-in to weigh: this is an AgentCore Gateway feature. Any MCP client that can sign AWS requests can call the gateway, but the agent's tools now live on AWS. If you are still choosing a platform, see our Claude API vs Bedrock vs Vertex AI comparison.

How to try it

AWS's tutorial takes you from nothing to a working agent call with the AWS CLI. In short:

1. Create a Standard state machine (the tutorial uses a one-step Pass state called AgentHelloWorld), all in one Region.
2. Create a gateway service role trusted by bedrock-agentcore.amazonaws.com, with an inline policy scoped to that state machine and its executions.
3. Create the gateway with aws bedrock-agentcore-control create-gateway using MCP and AWS_IAM auth, then wait for READY.
4. Add a target with create-gateway-target, connector ID states, and a stateMachineArn pin on every pinnable operation. Leave a pin out and that tool fails on every call.
5. Call tools/list and tools/call with a SigV4-signed client such as awscurl, or point your agent's MCP client at the gateway URL.
6. Delete the target, gateway, state machine and roles when you're done.

If your agent already uses other AgentCore Gateway tools, such as the managed web search we covered in Bedrock web search domain filtering, the workflows sit next to them as more tools.

Verdict

This is the right way to let an agent touch a process that matters. If you already run Step Functions on AWS, exposing a workflow now takes a CLI call instead of a custom integration, and the state machine keeps the agent on rails. Start with one Standard workflow, pin every operation, scope the IAM role to its executions, and keep task tokens away from any agent that shouldn't act on them. Teams that aren't on AWS, or whose agents live elsewhere, gain little from it yet.

Sources

• AWS What's New: Step Functions workflows now available as AI agent tools (Oct 29, 2026)
• Amazon Bedrock AgentCore Developer Guide: AWS Step Functions as Connector Target
• AWS Step Functions Developer Guide: Use your Step Functions workflows as tools for AI agents
• Amazon Bedrock AgentCore release notes
• AWS What's New: Step Functions adds AgentCore-powered agentic reasoning step (June 2026)
• Amazon Bedrock AgentCore pricing
• AWS Step Functions pricing