AWS Step Functions as AI Agent Tools via AgentCore Gateway: How It Works, Costs and Gotchas

AgentCore Gateway is the part of Amazon Bedrock AgentCore that connects agents to tools over MCP. With the new connector, you create a gateway target with connectorId states, pick which Step Functions operations become tools, and the gateway generates the tool schemas and calls Step Functions using the gateway's IAM service role. AWS's docs stress that you don't write a Lambda function or an MCP server and don't define the tools yourself, and that existing Standard and Express state machines work without changes.

The design idea is a clean split of responsibility:

AWS's own example is a support agent issuing a refund: the agent can decide a refund is warranted, but the eligibility check, manager approval and credit always run in the defined order, because the agent doesn't control the sequence. Standard workflows also record every step in an execution history, which helps when you need an audit trail, and they can run for up to one year, so work can continue after the agent's session ends.

If you're building agents on Bedrock models, this pairs naturally with our coverage of GPT-6.1 Terra on Amazon Bedrock and Bedrock in-country inference by Region.

Which tools does the connector expose?

The connector supports ten Step Functions operations. Four are pinned to a state machine you choose when you create the target; the agent never sees the state machine ARN and can't change it. The other six take an execution ARN or task token supplied by the agent.

A few extra fields (such as name and traceHeader on StartExecution, or maxResults and nextToken on GetExecutionHistory) can be exposed with parameterOverrides. You can't expose stateMachineArn that way; it can only be pinned. If an agent tries to pass it anyway, AWS documents that the gateway rejects the call with Invalid request parameters: cannot set parameter(s): [/stateMachineArn].

Each pinnable operation takes one pin per target, so to expose several state machines for the same operation, you create one target per state machine. Tool names are prefixed with the target name.

Standard vs Express: which workflow type should agents use?

This is where most people will trip up. The connector passes through Step Functions' own rules:

• Express workflows can't be addressed by execution ARN after they start, so DescribeExecution, GetExecutionHistory and StopExecution fail with InvalidArn on Express executions, and ListExecutions fails with StateMachineTypeNotSupported.
• StartSyncExecution only works on Express, and returns the result in the same tool call. That's ideal for quick request-response tools.
• The callback pattern (.waitForTaskToken), where a workflow pauses until the agent finishes a task and calls SendTaskSuccess, only works with Standard workflows.

AWS's suggested trick if you need both: in one target, pin StartSyncExecution to an Express state machine and the other pinnable operations to a Standard one.

Quick decision guide:

How do you set it up? (step by step)

AWS's Step Functions tutorial walks through a minimal version. In outline:

1. Create a Standard state machine (the tutorial uses a one-state Pass workflow called AgentHelloWorld).
2. Create a gateway service role trusted by bedrock-agentcore.amazonaws.com, with an inline policy scoped to that state machine and to its executions (two statements, because execution ARNs are a different resource type from state machine ARNs).
3. Create the gateway with aws bedrock-agentcore-control create-gateway, protocol MCP and AWS_IAM authorization, and wait for READY.
4. Add the connector target with create-gateway-target, using connectorId: "states" and a configurations list that pins stateMachineArn on each pinnable operation.
5. Call the tools from any MCP client that can sign requests with SigV4 (the tutorial uses awscurl): tools/list, then tools/call.
6. Clean up the target, gateway, state machine and roles to stop charges.

Here's the tool call AWS documents for starting a workflow on a pinned state machine. Note that the agent passes only the input:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "orders___StartExecution",
    "arguments": {
      "input": "{\"orderId\": \"12345\"}"
    }
  }
}

The response includes the new executionArn, which the agent then passes to DescribeExecution (with includedData: "ALL_DATA" if it needs input and output) to check status. Every resource must be in the same Region: the gateway calls Step Functions in its own Region only.

How much does it cost?

AWS says there's no extra charge for the connector itself; you pay standard rates for both services. Published US East (N. Virginia) list prices at the time of writing:

Illustrative estimate (ours, not AWS's): an agent that starts 100,000 Standard executions a month of a 10-step workflow and polls each once would make roughly 200,000 gateway invocations (about $1.00) and about 1 million state transitions (about $25 after the free tier). That excludes model inference, Lambda, and whatever services the workflow calls, which usually dominate.

What are the security catches?

Read these before going to production:

• Unpinned tools are bounded only by IAM. DescribeExecution, StopExecution and GetExecutionHistory can reach any execution the gateway role allows. Scope the role to the execution ARNs of the state machines you expose rather than granting states:*.
• Task-token tools can't be scoped by IAM. SendTaskSuccess, SendTaskFailure and SendTaskHeartbeat have no resource-level permissions, so they must be granted on "*". AWS says the task token is then the only control, so treat tokens as secrets and send each only to the agent that should act on it.
• All targets on a gateway share one service role. If workflows need different IAM boundaries, use separate gateways.
• Forgetting a pin breaks the tool. If you omit stateMachineArn on a pinnable operation, the target still creates, but the tool fails on every call.
• CloudTrail attribution. Executions started via the gateway show the gateway's service role as the caller, so plan how you'll tie runs back to end users.

What are developers saying?

It's early. We didn't find Reddit or forum threads discussing the connector at the time of writing. The most detailed independent write-up we found is a Japanese hands-on post by Yudai Jinno on Classmethod's DevelopersIO blog (30 October 2026). The author built a purchasing demo with a Standard approval workflow and an Express stock lookup, and reported:

• Passing a different state machine ARN was rejected in testing, matching AWS's pinning docs.
• Cedar policies on the gateway worked for restricting tools by role (only a manager role could call StopExecution, and the denied tool was hidden from the agent's tool list), but Cedar conditions on tool input content failed with evaluation errors, so the author kept input-based business rules inside the workflow.
• As of 30 October, Japanese text in inputs passed through the gateway came out as "?"; the author worked around it by escaping JSON to \uXXXX form. If you handle non-ASCII input, test this yourself.
• Tool descriptions are generic, so the agent needs the expected input format in its system prompt or a skill.

Questions we expect builders to ask: how this compares with calling AgentCore from a Step Functions Task state (the reverse direction, which AWS also documents), and whether to wrap existing Lambda functions directly instead. Our rule of thumb: if the order of steps matters or you need an audit trail, put it behind Step Functions; if it's a single stateless call, a direct tool target is simpler.

Editor's take

This is a small launch with a big idea: let the model choose, but let a deterministic workflow do. For regulated or money-moving processes (refunds, account changes, provisioning), it's a much safer pattern than letting an agent call five APIs in whatever order it reasons its way into. The weak spots are the ones AWS openly documents: IAM can't fence task-token calls, and Express workflows lose most of the observability tools. Start with Standard workflows, pin everything you can, and scope the role tightly. If you're heading to AWS re:Invent 2026 (30 November to 4 December), expect agent tooling like this to be a major theme.

FAQ

Can AI agents call AWS Step Functions?

Yes. Since 29 October 2026, AgentCore Gateway's built-in Step Functions connector exposes state machine operations as MCP tools that agents can discover and call.

What is AgentCore Gateway?

It's the Amazon Bedrock AgentCore service that connects AI agents to tools using the Model Context Protocol, handling tool schemas, authentication and routing.

Do I need to change my existing Step Functions workflows?

No. AWS says existing Standard and Express state machines can be exposed without changes.

Does the Step Functions AgentCore connector cost extra?

No separate fee. You pay standard Step Functions and AgentCore Gateway rates, for example $0.005 per 1,000 gateway API invocations.

Can I use Express workflows with AgentCore Gateway?

Yes, but ListExecutions, DescribeExecution, GetExecutionHistory and StopExecution don't work on Express executions. Use StartSyncExecution for Express.

How does an agent resume a waiting Step Functions workflow?

Use a Standard workflow with a .waitForTaskToken task. Your workflow delivers the token to the agent's application, and the agent calls SendTaskSuccess or SendTaskFailure.

Which AWS Regions support the Step Functions connector?

All Regions where AgentCore Gateway is available. The gateway calls Step Functions in its own Region only.

Can the agent run a different state machine than the one I pinned?

No. Pinned parameters are hidden from the tool schema and enforced on every call; attempts to override them are rejected.

Sources

• AWS What's New: Step Functions workflows as AI agent tools
• AgentCore Developer Guide: AWS Step Functions as connector target
• Step Functions Developer Guide: Use your Step Functions workflows as tools for AI agents
• AWS Weekly Roundup, 2 November 2026
• Classmethod DevelopersIO (Japanese): Step Functions as AgentCore Gateway tools
• Amazon Bedrock AgentCore pricing
• AWS Step Functions pricing

Also published today: Amazon Youth Promise UK jobs explained and Amazon's Sustainability Deep Tech Accelerator.

Featured image: Amazon employees in safety gear working in an AWS data center (official Amazon press photo; illustrative of AWS infrastructure, not specific to Step Functions or AgentCore). Image: Amazon. Source