AWS Step Functions turns your existing workflows into tools for AI agents
On October 29, 2026, AWS let AI agents call Step Functions workflows as tools through Bedrock’s AgentCore gateway, over MCP. The agent decides when to trigger, the workflow runs each step in order — a way to make agentic AI governable and auditable without rewriting business logic.
October 29, 2026. AWS announces that Step Functions workflows can now be called as tools by AI agents, through Amazon Bedrock’s AgentCore gateway. October 29, 2026. The mechanics are explicit: the agent decides when to run a workflow and what input to pass; Step Functions runs each step exactly as you defined it. October 29, 2026. Your existing Standard and Express workflows become connector targets, with no rewrite. Why it matters: the deterministic workflow becomes the guardrail under the model, and agentic AI gains a governance layer it did not have before.
For a team that already holds years of business logic encoded in Step Functions workflows, this is not a gimmick. It is the answer to a precise question: how do you let an agent act without handing it the order of operations.
The division of labour: the model proposes, the workflow disposes
The principle fits in one sentence, repeated in the announcement: “the agent decides when to run a workflow and what input to pass; Step Functions runs each step exactly as you defined it.” It is a clean division of labour between two opposite natures.
The agent — an LLM — is good at understanding a request and choosing the right action. It is bad at guaranteeing that a ten-step sequence always runs in the same order, with the same checks. A Step Functions workflow is the reverse: it is deterministic, idempotent when designed that way, and it already orchestrates more than 220 AWS services. The announcement joins the two: the model keeps the judgement, the workflow keeps the execution.
In practice, a customer-support agent can trigger your refund workflow: Step Functions runs the eligibility check, the manager approval and the credit write — in that order, every time — because that order was never left to the model’s improvisation.
What changes technically: MCP, connectors and run lookups
Under the hood, the integration goes through Bedrock’s AgentCore gateway, which connects agents to tools over the Model Context Protocol (MCP). Your existing Standard and Express workflows qualify as connector targets: nothing to rewrite, just describe them.
The most interesting detail is not the call itself but the run lookups. An agent can query the run history: an operations agent can tell the on-call engineer which order run failed overnight and at which step, sending them straight to the step that broke. The agent does not just trigger — it reports, leaning on an execution trace the workflow produced anyway.
Availability follows the AgentCore gateway; billing stays at the standard Step Functions and AgentCore rates, with no dedicated surcharge.
Why this is an architecture decision, not a feature
The value of the announcement is not in the novelty of the gesture — calling an API from an agent has been possible for months. It is in what you hand to the model, and what you do not. An agent that invokes a raw API runs a single operation. An agent that invokes a workflow triggers a sequence that is already approved, already tested, already audited by your teams.
Two examples published the same week illustrate the scale. MoEngage turned roughly 400 internal REST operations into tools via AgentCore Gateway, saving an estimated six months of engineering — with one precise lesson: a full tool listing crossed 20,000 tokens per connection, so agents search for a tool by describing the task instead of receiving the catalogue. Nubank, meanwhile, reports cutting a test cycle from about 4 hours 30 minutes to roughly 40 minutes by handing evidence collection to the AWS DevOps Agent.
The common thread: in both cases the agent does not replace the process — it drives it, while the verified logic stays where it always lived.
What to do about it
The right way to read the announcement is to start from your workflow inventory. You do not need an agent to benefit from it: first identify the Standard and Express workflows that encode sensitive business logic — approvals, refunds, provisioning, incident recovery — then document them as tools.
# List existing state machines (the raw material of the integration)
aws stepfunctions list-state-machines --query 'stateMachines[].name'Only then wire up the agent. The value of the Step Functions connector is that it inherits everything the workflow already provides: X-Ray tracing, retries, timeouts, error handling. The agent does not have to reinvent those safety nets — it walks through them.
Verdict
The integration of Step Functions into Bedrock’s AgentCore gateway is not one more autonomous-agent demo. It is a governance lever: it lets agentic AI stand on deterministic, tested and auditable logic, with no rewrite.
If you already have Step Functions workflows encoding regulated or financial processes, wire them up as tools before you let an agent improvise — the workflow guarantees the order, the agent brings the judgement, and the audit stays where it has always been. If you are starting from scratch, do not code an agent first: encode your processes as workflows first, because those are what will separate an agent that suggests from an agent you can rely on. The trap is not the model’s capability — it is believing that governance gets sorted out after the fact.
References
- AWS — Step Functions workflows now available as AI agent tools (October 29, 2026)
- AWS — Weekly Roundup: GPT-6.1 Terra on Bedrock, Step Functions as agent tools (November 2, 2026)
- AWS — Step Functions connector targets, AgentCore Gateway documentation
- AWS — How MoEngage turned over 400 APIs into agent tools with AgentCore Gateway
- AWS — How Nubank automated disaster recovery with the AWS DevOps Agent