Step Functions workflows can now be exposed to AI agents as MCP tools through Bedrock AgentCore Gateway. The determinism this buys is real and it is narrower than the announcement's closing sentence suggests: the steps run in the order you defined, and the decision to run them at all now belongs to a model.
“Your agent decides when to run a workflow and what input to pass, and Step Functions runs each step exactly as you defined it.”
Executive summary
“You can now use your AWS Step Functions workflows as tools for AI agents through Amazon Bedrock AgentCore Gateway.” The connection is standard: “AgentCore Gateway connects AI agents to tools through the Model Context Protocol (MCP).”
Nothing needs rewriting to participate: “Agents can use your existing Standard and Express workflows as tools.” That sentence is the whole value of the launch, and it is also the reason to spend ten minutes on this before enabling it — a workflow written when only your own code could start it now has a caller that decides for itself when to start it.
It is available “in all AWS Regions where Amazon Bedrock AgentCore Gateway is available”, and “You pay standard rates for Step Functions and AgentCore Gateway” — no new line item, which also means no new budget signal if an agent starts calling a workflow more often than a human would have.
What changed
Before this, something you wrote decided when a workflow ran: an EventBridge rule, an API Gateway route, an SDK call in your own code. The trigger was deterministic even when the input was not. Now the trigger is a model's judgement, and the input is a model's construction.
The announcement closes with the claim worth reading precisely: “With this launch, your agents can run multi-step business processes in the same order every time.”
That is true, and it is a statement about the inside of the workflow. The steps are ordered, the retries are as configured, the branching is as written. What it does not claim — and what the Step Functions documentation is explicit about — is how many times the process runs, which is a property of the workflow type you happened to choose long before an agent was involved.
Architecture
The guarantee is a property of the workflow, not of the launch
All three execution models are now reachable by an agent, and they do not behave the same way when a call is repeated:
| Workflow type | Execution semantics | Idempotency |
|---|---|---|
| Standard | “Exactly-once workflow execution” | “Automatically returns an idempotent response on starting an execution with the same name as a currently-running workflow” |
| Express, asynchronous | “At-least-once workflow execution” | “Idempotency is not automatically managed. Starting multiple workflows with the same name results in concurrent executions” |
| Express, synchronous | “At-most-once workflow execution” | “Idempotency is not automatically managed” |
AWS states the intended split plainly: “The exactly-once model makes Standard Workflows suited to orchestrating non-idempotent actions, such as starting an Amazon EMR cluster or processing payments”, while “The at-least-once model makes Express Workflows better suited for orchestrating idempotent actions”.
That guidance was written for callers who know whether they are retrying. An agent that gets an ambiguous result and tries again is a caller with no such discipline, and on an asynchronous Express workflow the documented outcome of the second call is a second concurrent execution.
What the agent gets back is not the same in each case
Asynchronous Express workflows “return confirmation that the workflow was started, but don't wait for the workflow to complete”. As a tool result, that is an acknowledgement rather than an answer — which an agent may reasonably interpret as a reason to call again, or to proceed as though the work is done.
The duration mismatch points the same way. Standard workflows are “ideal for long-running (up to one year), durable, and auditable workflows”, and Express workflows “can run for up to five minutes”. A tool call is a conversational turn; a year is not.
Business value
The real gain is that an agent no longer has to improvise a multi-step process. Where a model would otherwise chain several tool calls and decide at each hop what comes next, it now makes one call into a process whose order, retries and error handling were settled in review, by people, in a state machine that can be read.
That moves a large amount of behaviour out of the prompt and into infrastructure, and Step Functions is described as “a visual workflow service capable of orchestrating over 220 AWS services”, so the reach of a single tool is considerable.
It also removes a class of integration work. The workflows already exist; exposing them does not require a wrapper Lambda, a bespoke MCP server, or a second copy of the business logic that will drift from the first.
Security considerations
The caller changed, so the threat model changed. A workflow that was only ever started by your own code may have treated its input as trusted. Its new caller constructs that input from a conversation, which may include text a user wrote. Input validation at the first state is no longer defensive programming; it is the boundary.
A tool's blast radius is the workflow's execution role, not the agent's. Step Functions runs with the state machine's role. Whatever that role can do, the agent can now cause — indirectly, once, per invocation it decides to make. A workflow that was given broad permissions because only a trusted scheduler could start it is worth re-reading on that basis alone.
On Express workflows, the record is not kept unless you asked for it. “Execution history is not captured by Step Functions. Logging must be enabled through Amazon CloudWatch Logs.” For Standard workflows you can “retrieve the full execution history using the Step Functions API for up to 90 days after your execution completes”. The workflows most likely to be invoked at conversational speed are exactly the ones that keep no history by default.
Cost considerations
“You pay standard rates for Step Functions and AgentCore Gateway”, so the pricing model is unchanged and the demand curve is not. Standard workflows are “billed according to the number of state transitions processed” and Express workflows “by number of executions, total duration of execution, and memory consumed”.
Both of those scale with invocation count, and invocation count is now set by something that can decide to retry. A workflow called a few hundred times a day by a scheduler and a workflow called by an agent mid-conversation have the same unit price and very different bills.
Operational considerations
Workflow type cannot be changed later. “The workflow type can not be updated after you create a state machine.” If an existing Express workflow turns out to be the wrong execution model for agent invocation, the remedy is a new state machine, not a setting.
Two integration patterns are missing from Express. “Express Workflows do not support Job-run (.sync) or Callback (.waitForTaskToken) service integration patterns.” Callback is the pattern most likely to matter here, because human-in-the-loop approval is a natural thing to want in a process an agent can start.
Tradeoffs
| What you gain | What it costs |
|---|---|
| Process order, retries and error handling defined in reviewable infrastructure rather than in a prompt | The decision to run the process is no longer reviewable in the same way |
| Existing workflows become tools with no rewrite | Their assumptions about who calls them were written for a different caller |
| One tool call replaces a chain of improvised ones | An ambiguous tool result is a plausible reason for an agent to call again |
| No new pricing model | No new cost signal either, on a workload whose call rate is now model-driven |
Implementation guidance
Start by listing which workflows you intend to expose, and their type. The type decides the execution guarantee, and you cannot change it afterwards. Standard is the default and the one AWS points at for non-idempotent work.
For anything with a side effect that matters, prefer Standard and use the name. The exactly-once model is what gives you “an idempotent response on starting an execution with the same name as a currently-running workflow” — which only helps if the execution name is derived from the business operation rather than generated fresh per call. That is a choice in how the tool is wired, and it is the single most useful thing to get right.
Validate input in the first state. Treat the agent's constructed input the way you would treat an unauthenticated HTTP body — check types and ranges before anything with an effect runs.
Turn on CloudWatch Logs for any Express workflow you expose. Otherwise there is no record of what the agent did, and the first time you need one will be the first time you look.
Re-read the execution role. Scope it to what the workflow needs now that its caller is non-deterministic, rather than to what was convenient when the caller was your own scheduler.
Best practices
Expose a small number of workflows deliberately rather than everything that exists. Each one is a capability you are handing to a model, and the inventory is the control.
Make the tool description precise about when the workflow should be used, because that description is what the agent reasons over when it decides whether to call it. A vague description is an availability problem and a correctness problem at once.
Keep human-in-the-loop approval inside the workflow where the process warrants it, and remember that the callback pattern that implements it is Standard-only.
Alarm on execution count per workflow, not only on failures. The failure mode that costs money here is a workflow succeeding more often than anyone intended.
Who should adopt this and when
Adopt now if you already run Standard workflows for business processes and you are building agents that currently reimplement those processes as sequences of tool calls. This is strictly better than that, and it is the case the launch is built for.
Adopt carefully if the candidate workflows are Express and asynchronous. They are at-least-once by design, idempotency is not managed for you, and they keep no execution history unless logging was enabled. None of that is a defect; it is a mismatch with a caller that may retry.
Wait if the workflow performs non-idempotent actions and you cannot yet derive a stable execution name from the business operation. The idempotency guarantee is keyed on that name, and without it the exactly-once model protects less than it appears to.
Key takeaways
The determinism is inside the workflow. “Step Functions runs each step exactly as you defined it” is a promise about order, not about frequency.
Three workflow types, three execution guarantees — exactly-once, at-least-once and at-most-once — and the launch exposes all of them to a caller that can decide to try again.
The execution name is the idempotency key. Standard's protection applies to an execution started “with the same name as a currently-running workflow”, which makes naming an architectural decision rather than a detail.
Express keeps no history by default. If an agent can start it, enable logging before it does.
Official AWS references
- AWS Step Functions workflows now available as AI agent tools — the AgentCore Gateway and MCP connection, the statement that the agent decides when to run a workflow and what input to pass, the support for existing Standard and Express workflows, the same-order-every-time claim, and the Region and pricing statements
- Choosing workflow type in Step Functions — the exactly-once, at-least-once and at-most-once execution semantics, the idempotency behaviour of each, the one-year and five-minute durations, the 90-day execution history for Standard and its absence for Express, the unsupported .sync and .waitForTaskToken patterns, and the immutability of workflow type
- Amazon Bedrock AgentCore Gateway — further reading on how the gateway presents tools to agents; no claims in this post are drawn from it
Comments