{"slug": "turning-a-step-functions-workflow-into-ai-agent-tools-through-agentcore-gateway", "title": "Turning a Step Functions workflow into AI agent tools through AgentCore Gateway", "summary": "AWS made Step Functions workflows usable as AI agent tools through Amazon Bedrock AgentCore Gateway on October 29, 2026, letting agents decide when to run a workflow and what input to pass while Step Functions executes each step as defined. The update lets existing Standard and Express workflows be converted into tools without rewriting them, and a sample pattern in the FSx for ONTAP S3 Access Points serverless series turned a Standard discover → process → report workflow into tools via the connector, verified on a live ap-northeast-1 deploy in DemoMode with 3/3 files. The author reported no performance or cost numbers, describing the run as a smoke test rather than a measurement.", "body_md": "# Turning a Step Functions workflow into AI agent tools through AgentCore Gateway\n\nPart of the FSx for ONTAP S3 Access Points serverless patterns series On October 29, 2026, AWS Step Functions workflows became usable as AI agent tools through Amazon Bedrock AgentCore Gateway. The agent decides when to run a workflow and what input to pass; Step Functions runs each step as you defi\n\nned it. You can turn existing Standard / Express workflows into tools without rewriting them. Announcement: AWS Step Functions workflows now available as AI agent tools (AWS What's New, 2026-10-29) Documentation: AWS Step Functions as Connector Target This post applies that update to an FSx for ONTAP S3 Access Points file-processing workflow and adds it to the repository as a sample pattern. The key points: Standard workflow (discover → process → report) turned into tools via the connector The agent decides when to run; the state machine owns the order of the steps Gateway and connector target described in CloudFormation, so sam deploy alone completes it Verified on a live ap-northeast-1 deploy (DemoMode, 3/3 files) No performance or cost numbers (it was a smoke test, not a measurement) What the Step Functions connector makes possible (within the official docs) The shape of the pattern I added, and how it differs from the existing AgentCore integration The design points that are easy to trip over Performance and cost numbers (I ran it live, but that was a smoke test, not a measurement) Express workflows and synchronous responses (StartSyncExecution) — this pattern stays on Standard Cedar authorization on the input body — the official behavior is limited right now (see below) The agent implementation itself (Strands, etc.) — this post is about the tool-provider side This series has been building serverless patterns that process files over S3 Access Points.\n\nThe processing itself is usually a Step Functions workflow: discover, process each file, report. That shape already runs in several patterns. Then this update landed: you can turn a workflow into an agent tool. A workflow that used to be triggered by an EventBridge schedule or by hand now gets an entry point for an agent.\n\nYou keep the business logic as-is and move the launch and status-check to natural language. Reusing existing assets without rewriting them looked worthwhile, so I tried it in the context of the series. The post that got me started is below. It uses a purchase-order-and-approval scenario and goes as far as task tokens and Cedar, which made the behavior concrete.\n\n[Update] You can now use AWS Step Functions workflows as AI agent tools via AgentCore Gateway (Classmethod, JA) The subject of this series is a workflow that processes files on a file store (FSx for ONTAP) through S3 Access Points. The discover-process-report shape maps directly onto business document processing. AWS itself shows a concrete pairing of Step Functions with AgentCore in an architecture blog on automating medical coding, and intelligent document processing — classifying and extracting from contracts, invoices, applications — is a recurring subject in the AWS solution guidance as well. A few situations where this connector fits: When you want to add a natural-language entry point to a file-processing batch.\n\nA workflow you used to start on a schedule or by hand can now be started from a conversation (\"summarize the unprocessed files in that folder\") and followed to its result. The workflow internals stay as they are. When you want the steps fixed but the timing left to a person or an agent. The order of classify, extract, notify and the business rules stay pinned in the state machine; only \"when to run it and what input to pass\" is handed to the agent.\n\nWhen you want a human approval before a sensitive action. With task tokens you can pause the workflow partway, wait for a person's decision, and resume on approval (human-in-the-loop). AWS shows a reference flow that wires event-driven signals to human approval. The readers I have in mind are roughly these: Platform / operations people who run existing Step Functions workflows and want to add an agent entry point without rewriting the business logic — shifting start and result-checking toward a conversation.\n\nApplication / line-of-business developers automating document processing who want business users to start and check runs themselves, while the fixed steps stay in the workflow. Security-minded people who want to bound what the agent can reach. Which state machine and which operations become tools is declared, so the agent's reachable surface is something you can read as code. This overlaps with building the agent integration yourself (writing the agent with something like Strands and authoring your own tools) and with visual workflow builders.\n\nI read the connector approach as the one with the least extra implementation when \"there is already a Step Functions workflow\" matches your situation. It is less about which is best and more about picking the entry point that fits the assets you already have. AgentCore Gateway gained a built-in Step Functions connector (connectorId: \"states\"). When you create a target, you pick the operations to expose and the state machine, and the Gateway generates the tool definitions.\n\nYou write neither a Lambda nor an MCP server. Per the official docs, the connector exposes ten operations. Four of them (StartExecution / StartSyncExecution / ListExecutions / DescribeStateMachine) pin a state machine ARN on the target. The pinned ARN never appears in the tool arguments, so the agent cannot run a different state machine.\n\nThe other six take an execution ARN or a task token the agent supplies. The division of labor: the agent decides when to run and what input to pass, while the ordered steps and the business rules stay on the state machine side. It lives at solutions/genai/stepfunctions-agentcore-tools/. The subject is the S3 AP file-processing workflow that is familiar from this series.\n\nFigure: exposing the workflow as agent tools through the Step Functions connector (dark theme here) Discovery: scans the S3 AP and builds the list of files to process Processing: reads one file, summarizes/classifies with Bedrock, scores confidence, and attaches a human-review decision Report: aggregates, adds a data-classification label, and sends an SNS summary With a target named workflow, the agent sees tools like workflow___StartExecution. It starts the workflow, receives an executionArn, checks status and result with workflow___DescribeExecution, and reads how far it progressed with workflow___GetExecutionHistory. This repository already has a Lambda-target AgentCore integration. This one uses the connector, so the target is a different thing.\n\nLambda target: the Lambda becomes the tool; you write the tool definition yourself Connector: the state machine's operations become the tools; the Gateway generates the definitions; the Lambda is only invoked as a workflow Task and is not exposed to the Gateway The Gateway and the connector target are available as CloudFormation resources (AWS::BedrockAgentCore::Gateway and AWS::BedrockAgentCore::GatewayTarget). So they go into the same template as the Lambdas, the state machine, and the role, and sam deploy alone gets you all the way to the gateway's tools/list — no separate command to create the gateway. The deploy script is a thin wrapper that runs sam build and sam deploy and checks tools/list at the end. Points I noticed while building.\n\nLet me separate them by source. The connector configuration schema and the Gateway role IAM I confirmed myself, from the CLI and the CDK sample as above, and then on a live deploy (below). The same-region and pinning constraints are from the official docs. The Japanese mojibake and the Cedar item I did not exercise on this live run — I am citing another post's report.\n\nThe Gateway and the state machine are in the same region. The Gateway calls Step Functions in its own region. A state machine in another region cannot be wired up. One pin per operation.\n\nTo expose several workflows under the same operation, use one target per workflow. Tool descriptions are generic. The shape of the input JSON is not in the tool. Tell the agent in the system prompt or a skill.\n\nStandard and Express differ in which operations work. I chose Standard because it keeps an execution history, so ListExecutions and GetExecutionHistory work. If you need a synchronous answer, that is a separate look at Express and StartSyncExecution. Treat task tokens as secrets.\n\nSendTaskSuccess and friends cannot be scoped by IAM; anyone holding a valid token can complete the task. This pattern does not expose them. Input-body authorization is not expressible in Cedar right now. A policy conditioned on the input body (an amount, a reason) currently hits a type-evaluation error — the Classmethod post above reports the same observation.\n\nKeep body-level decisions on the state machine side. Per-tool allow/deny does work in Cedar. That said, each of these sits well with the point of the pattern: don't hand everything to the agent; pin the steps you want enforced into the workflow. If you want to branch on the input body, that was a Choice state in the workflow all along.\n\nThe Classmethod post reports that Japanese in the input passed through the Gateway can get mangled, with a workaround of escaping the Japanese in the JSON to \\uXXXX before sending. I have not confirmed this on my own deployment yet, so the docs record it as a reported known behavior together with the workaround. I deployed it to the Tokyo region in DemoMode and exercised the agent-facing path end to end. The gateway's tools/list showed all five tools; StartExecution returned an executionArn, DescribeExecution gave me status and result, GetExecutionHistory showed the step transitions, and ListExecutions listed the runs.\n\nThe workflow succeeded, all three files were processed, and the category and data-classification labels came through. The Gateway and connector target came up with the stack create and went away with the stack delete. This pattern is scoped to exposing a Standard workflow as tools. It does not include Express synchronous responses, task-token human-in-the-loop, or a Cedar build-out.\n\nI confirmed each is possible in the official docs, but cramming all of them into one sample blurs the point, so I drew the boundary. There are no performance or cost numbers either. I did run it live, but that was a smoke test, not a measurement — running once and running under load are different things. When I measure, I will write it up with the environment (region, model, file count, date) attached.\n\nBeing able to turn an existing Step Functions workflow into agent tools without rewriting it was a welcome update for me. The split — steps in the workflow, launch decision with the agent — holds with no extra implementation. I ran it live end to end and confirmed I could start a workflow from the agent and follow its result. What is left is seeing the Japanese mojibake and the Cedar behavior with my own eyes, and measuring performance and cost under load.\n\nOnce I do that, I will write the follow-up with numbers. The use cases are something I want to dig into from there too. The implementation is on GitHub. Repository: FSx-for-ONTAP-S3AccessPoints-Serverless-Patterns Previous (a published S3 AP post): the 28-patterns post I hope this helps anyone who wants to reach an existing Step Functions workflow from an agent.\n\nBye now!! Yoshiki Fujiwara\n\n## Key Takeaways\n\n- •You can turn existing Standard / Express workflows into tools without rewriting them.\n- •This story was reported by **Dev.to** , covering developments in the**dev** space.\n- •AI advancements continue to reshape industries — read the full article on Dev.to for complete coverage.\n\n📖 Continue reading the full article:\n\n[Read Full Article on Dev.to →](https://dev.to/aws-builders/turning-a-step-functions-workflow-into-ai-agent-tools-through-agentcore-gateway-4ld7)", "url": "https://wpnews.pro/news/turning-a-step-functions-workflow-into-ai-agent-tools-through-agentcore-gateway", "canonical_source": "https://ainexusdaily.vercel.app/article/2026-11-01-turning-a-step-functions-workflow-into-ai-agent-tools-through-agentcore-gateway", "published_at": "2026-11-01 12:35:21+00:00", "updated_at": "2026-11-01 12:51:11.949289+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-infrastructure", "agent-protocols"], "entities": ["AWS", "AWS Step Functions", "Amazon Bedrock AgentCore Gateway", "FSx for ONTAP", "S3 Access Points", "CloudFormation", "Strands", "ap-northeast-1"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/turning-a-step-functions-workflow-into-ai-agent-tools-through-agentcore-gateway", "markdown": "https://wpnews.pro/news/turning-a-step-functions-workflow-into-ai-agent-tools-through-agentcore-gateway.md", "text": "https://wpnews.pro/news/turning-a-step-functions-workflow-into-ai-agent-tools-through-agentcore-gateway.txt", "jsonld": "https://wpnews.pro/news/turning-a-step-functions-workflow-into-ai-agent-tools-through-agentcore-gateway.jsonld"}}