What AWS announced
On October 29, AWS announced that Amazon Bedrock AgentCore Gateway can expose existing AWS Step Functions Standard and Express workflows to AI agents as Model Context Protocol tools. The agent decides when to start a workflow and supplies its input; Step Functions executes the state machine defined by the operator. AWS says agents can also inspect workflow runs, and the capability is available in every AWS Region where AgentCore Gateway is available.
The built-in connector creates the MCP tool schemas and authenticates to Step Functions with the gateway service role, so teams do not need to write a Lambda adapter or their own MCP server. Four operations can be pinned to a state machine: StartExecution, StartSyncExecution, ListExecutions, and DescribeStateMachine. Six other operations accept an execution ARN or task token from the agent, including execution inspection, stopping, and callback completion.
These are AWS’s reported capabilities and availability status; the production conclusions below are Ineeza analysis. The launch does not make an agent’s selected input trustworthy, give Standard and Express workflows identical execution guarantees, or turn successful workflow completion into business authorization or financial finality.
Fixed step order does not validate the decision to start
Moving a multi-step process into a state machine prevents an agent from skipping or reordering the defined states. That is a useful separation between probabilistic planning and deterministic orchestration. The agent still chooses when to invoke the workflow and controls the input fields visible in the tool schema.
Ineeza analysis: validate invocation at the workflow boundary before any irreversible state. Bind the caller, tenant, workflow version, business object, allowed operation, input schema, data classification, freshness, approval record, and request identifier. A refund workflow that always performs eligibility, approval, and credit in order is still unsafe if the agent can substitute the customer, invoice, amount, destination, or approval context.
Pinning and IAM must describe the same authority
AWS removes a pinned stateMachineArn from the agent-visible tool schema and rejects attempts to override it. Execution-level operations are different: DescribeExecution, StopExecution, and GetExecutionHistory accept an ARN supplied by the agent and rely on the gateway service role to limit which executions are reachable. AWS also documents that every target on one gateway shares that service role.
Ineeza analysis: pinning is routing integrity, while IAM is the authorization perimeter. Scope execution ARNs to the exposed state machines, publish only the operations each agent needs, and use separate gateways when workflows require different trust zones. Test cross-tenant ARNs, guessed execution names, stale executions, and unauthorized stop requests. A correct state-machine pin does not compensate for a broad role on the unpinned tools.
Workflow type changes retry and evidence semantics
AWS documents Standard workflows as long-running and auditable, with execution history and exactly-once workflow execution. Express workflows target high event rates, can execute steps at least once, and do not support the same addressable execution-history operations. StartSyncExecution applies to Express; execution-ARN inspection and stopping apply to Standard executions.
Ineeza analysis: choose the workflow type as a correctness decision, not only a throughput or price decision. Every external effect still needs an idempotency key because service retries, timeouts, and downstream systems can create uncertain outcomes even when orchestration is durable. Record explicit states such as requested, accepted, running, awaiting approval, succeeded, failed, timed out, stopped, and reconciliation pending. Never infer payment, ledger, or fulfillment finality from the MCP tool returning without an error.
Task tokens are delegated completion capabilities
The connector can expose SendTaskSuccess, SendTaskFailure, and SendTaskHeartbeat so an agent can resume a Standard workflow waiting on a callback. AWS notes that IAM does not support resource-level permissions for these actions; they must be granted on all resources, leaving the task token as the control over which waiting task can be completed.
Ineeza analysis: treat each task token as a short-lived bearer capability. Deliver it only to the intended agent instance, keep it out of prompts and durable transcripts, bind the callback payload to the original task and policy version, and consume it once. A model-generated “success” should be schema-validated and independently checked before it unlocks a high-impact transition. Token leakage turns a narrow workflow pause into authority to assert completion.
Ineeza’s view
This launch is material because it lets teams place established orchestration, approval, retry, and audit mechanisms behind an agent-facing MCP boundary without rebuilding them as model tools. The safe pattern is not merely “put the process in Step Functions.” It is to validate the invocation, align pins with least-privilege IAM, choose execution semantics deliberately, protect callback capabilities, make effects idempotent, and correlate the agent request with the complete workflow and business outcome. The workflow fixes how work proceeds; the surrounding control plane decides whether that work was authorized and whether it truly completed.