AWS published a Step Functions pattern that checks agent plans before payments

Ben Freiberg and Nithin Chandran Rajashankar at AWS published a Step Functions pattern on 14 September that runs Amazon Bedrock AgentCore agents inside a state machine and puts a deterministic Lambda check after every agent step. AWS states the rule as "agents propose, and deterministic code validates". The worked example is airline rebooking after a flight cancellation, and the reference code is published on Serverless Land.

How the state machine is built

A cancellation event from Amazon EventBridge starts the workflow. An enrichment step pulls the passenger manifest, current bookings, loyalty status and preferences into the execution state. A Distributed Map then starts one branch per passenger, with MaxConcurrency set to 1000 to limit the load on the booking and inventory systems it calls, against a Distributed Map default of 10,000 parallel child executions.

Inside each per-passenger branch, one AgentCore task proposes the top three rebooking options, and a Lambda then confirms each proposed flight is bookable by checking live availability, fare rules and route validity, rejecting hallucinated options. A second AgentCore task drafts the customer-facing notification text only, and a second Lambda computes the entitlement against rule tables before any compensation issues. AWS names EU Regulation 261/2004 and US Department of Transportation refund rules as illustrative frameworks, and says the bands and amounts are configuration that the operator sets.

What the vendor is arguing

AWS says only deterministic task states write to the reservation system or issue a payment, and only after a deterministic validation step has passed. Bookings and payments are idempotent, with a token derived from the passenger ID and the decision ID, so a retry or a rerun has no effect and a duplicate booking or a second payment cannot happen. Unresolved cases route to human agents through a Step Functions callback pattern that pauses the case at zero compute cost.

The main design idea is that routing, parallel branches, retries and the audit trail are all handled in Step Functions. Every state transition is recorded with input and output. A branch decision becomes a deterministic state a team can test in isolation, with the same input producing the same route on every run.

The integration itself

Step Functions has an optimised integration for AgentCore harness that calls InvokeHarness against a target harness ARN, with a per-task timeout raised to 15 minutes so an agent has time to reason. AWS notes the trade-off: the agent call is request-response only, there is no .sync and no .waitForTaskToken on the agent step, and only the final assistant message returns to the state machine. AWS also points out an easy mistake caused by its own naming: the service name is spelled bedrockagentcore without a hyphen in the Step Functions resource string, and bedrock-agentcore with a hyphen in the AgentCore ARN.

The pattern is written against airline rebooking, but AWS says it applies anywhere an automated decision has real financial or regulatory consequences. Teams already committed to Step Functions get a vendor-supported way to stop the model from writing directly to booking and payment systems, which is the part most agent frameworks leave to the developer. Teams elsewhere can reuse the same split without the AWS-specific pieces: a proposal step, a check step that runs against live data, and a separate execute step that only runs on validated input.

Source

Primary source: Validating multi-agent decisions with Step Functions and Bedrock AgentCore on the AWS Compute Blog. Coverage: AWS agents will suggest your new flights. Code decides what gets booked on The New Stack.