AI agents can now start Step Functions workflows. The agent picks the moment; the workflow keeps the steps
Existing Step Functions workflows can now be exposed to AI agents through AgentCore Gateway and MCP. It gives teams a clean line between what the model decides and what tested code executes.
Listen to this article · 4 min
AI-generated narration of the full article.
The riskiest thing an enterprise agent can do is improvise a process that already exists. A refund has an eligibility check, a manager’s approval and a credit posted in a specific order. When an agent is handed the individual APIs and asked to figure out the order, it usually gets it right. Usually is the problem.
AWS’s announcement on October 29 offers a different arrangement. Existing AWS Step Functions workflows, Standard and Express, can now be exposed as tools to AI agents through Amazon Bedrock AgentCore Gateway, which speaks MCP. The agent decides when to run a workflow and what input to pass. Step Functions executes each step exactly as it was defined.
The line it draws
Who decides what when an agent calls a workflow
The agent
- Understands the request
- Chooses the workflow
- Supplies the input
- Reads run status
Probabilistic
The workflow
- Eligibility check
- Human approval step
- Retries and error paths
- Calls to 220+ AWS services
Defined and tested in advance
The systems of record
- The credit posted
- The execution history
What auditors read
AWS’s example is a support agent triggering a refund workflow that runs eligibility, manager approval and credit steps. The agent never touches the credit API directly. It also cannot skip the approval, because the approval is a state in the workflow, not an instruction in the prompt.
The second capability is quieter and useful in operations: agents can look up workflow runs. An agent can answer “which order runs failed overnight, and at which step” from the execution history instead of reconstructing it from logs.
Availability follows AgentCore Gateway’s regions, and pricing is the standard rate for both services.
Why this is the right shape
We have argued that a well-run agent makes parts of itself unnecessary: once a reasoning path repeats, it should become ordinary software and leave the model. Step Functions as a tool is the other half of that idea. The organization does not have to convert anything; it already has workflows that encode its procedures, tested and versioned, often with approval steps that compliance signed off years ago. The agent becomes a new way to start them, not a replacement for them.
It is also the boundary we described in the contest for the transaction authorization layer. Reasoning is becoming portable across vendors; authority to commit a transaction should stay with the system that owns it. A state machine with its own IAM role and execution history is a reasonable place for that authority to live.
What it does not fix
Who may start the workflow. Exposing a workflow as a tool makes it callable by any agent that the gateway allows. The question shifts from “can the agent do the steps” to “should this agent, acting for this user, be able to start this workflow at all”. That needs a policy at the gateway, tied to the identity behind each tool call, not just the workflow’s own role.
Input validation. The agent supplies the input. A workflow that trusted its old callers, because they were internal systems with fixed schemas, now receives values chosen by a model. Validate at the first state as if the caller were untrusted, because it partly is.
Duplicate runs. Agents retry. A defined execution order does not guarantee exactly-once effects in external systems. Refunds, payments and notifications need idempotency keys so that the second call returns the first result instead of paying twice.
Workflows written for people. Some workflows assume a human operator will notice a strange result between steps. An agent will not. Review which workflows are safe to expose before exposing them, starting with read-only and reversible ones.
None of this argues against the feature. It argues for treating the workflow catalog as an authorization surface: an explicit list of which procedures agents may start, for whom, with which inputs. Teams that already run their critical processes on state machines have a head start. Teams that do not now have another reason to.