AWS now lets agents call Step Functions workflows as tools. Sort every step of the process into one of two columns first

What AWS shipped

In its November 2, 2026 weekly roundup, AWS announced that Step Functions workflows are now available as AI agent tools through Amazon Bedrock AgentCore Gateway, the service that connects agents to tools over the Model Context Protocol (MCP). Existing Standard and Express workflows qualify as targets, agents can also look up workflow runs, and it's available in every Region where AgentCore Gateway runs, at standard rates.

Daniel Abib, who wrote the roundup, describes the idea as a division of labor: "the agent decides when to run a workflow and what input to pass; Step Functions runs each step exactly as you defined it." His example is a support agent that can trigger a refund, where "the eligibility check, the manager approval, and the credit still happen in that order every time, because the ordering was never the model's to improvise."

That's a clear way to put it, and it gives teams a useful exercise. Before you connect a workflow to an agent, take the process it runs and sort every decision into one of two columns: what the agent decides, and what the workflow decides. The model gets to choose the moment. It never gets to choose the order.

Column one: what the agent decides

The agent's column should hold the things that genuinely need judgment about a conversation or a situation:

• Whether this is a refund request at all. A customer writing "this arrived broken" might want a refund, a replacement or just an apology. Reading that is the agent's job.
• Which order, and which items. The agent can find the order and pick out the item in question from what the customer said.
• When to start. The agent decides that now is the moment to call the refund workflow, rather than asking another question first.
• What to tell the customer. Once the workflow responds, the agent explains the result in plain words.

Notice what isn't here: whether the refund is allowed, how much it is, or who approves it.

Keep this column short on purpose. Every item in it is something the model can get wrong in a new way tomorrow, because the next customer will phrase things differently. That's acceptable for reading a message and choosing words. It isn't acceptable for anything that moves money, changes a record or commits the business to something. When you're unsure where a decision belongs, ask what it would cost if the agent got it wrong once in a hundred conversations. If the answer is an awkward reply, it can stay here. If the answer is a wrong credit, it moves to the workflow.

Column two: what the workflow decides

The workflow's column holds everything that should happen the same way every time, no matter how the conversation went:

• Eligibility. Is the order inside the return window? Has it already been refunded? The workflow checks; the agent doesn't get to argue.
• Limits and approval. Above a set amount, a person approves. Abib's example includes manager approval as a fixed step.
• The credit itself, issued once, with a record.
• What gets written down, so someone can check later what happened and why.

We've written about building a refund authority ladder, where each amount band has a named approver. That ladder belongs in the workflow column, written into the steps, not described to the agent in a prompt.

The handoff between columns

The most important line in the process is the one between the columns: the input the agent passes to the workflow. Treat it like a form a person fills in, not a sentence.

Keep the input narrow. Order ID, item, reason code. If the agent can pass a free-text "amount" field, it's in a position to decide the amount. Let the workflow look up the price instead.

Make repeats harmless. An agent might call the same workflow twice: a retry after a timeout, or a customer who asks again. If running the refund workflow twice could issue two credits, fix that in the workflow, not the prompt. Our idempotency key policy note covers how to make sure the same request only happens once.

Use run lookup. AWS says agents can look up workflow runs. That's useful: when a customer asks "did my refund go through?", the agent can check the run instead of guessing or starting another one.

Plan for "no." When the workflow says the order isn't eligible, the agent needs an honest way to explain that, and a way to hand the customer to a person if they push back.

Before you connect a workflow

The roundup notes that Step Functions already orchestrates more than 220 AWS services, and mentions that AWS's AI blog described one engagement platform exposing roughly 400 internal API operations to agents in a similar way. The ease is the point, and it's also the risk: it becomes easy to give an agent many tools before anyone has done the sorting.

For each workflow you're about to expose, do four things:

1. Write the two columns. On one page, list every decision in the process and which column it's in. If a step could go either way, it goes in the workflow column until you have a reason to move it.
2. Check the input. Make sure nothing the agent passes in lets it make a column-two decision.
3. Test the edges. Ineligible orders, duplicate requests, amounts just above the approval line. Run them through the agent and confirm the workflow, not the agent, is the one that stops them.
4. Name an owner. Someone decides when a step moves from one column to the other, and that change gets reviewed like any other change to the workflow.

Workflows your team already trusts are a good thing to hand an agent. The trust comes from the fact that they run the same way every time, and the sorting exercise is how you keep it that way.

If you'd like help connecting agents to the systems you already run, with clear lines about what they can decide, our AI applications and agents team does that work. Get in touch and tell us which process you're thinking of handing over first.

Related work: Sutton Place.