AWS releases a Step Functions pattern that lets agents propose and code validate before a booking or payment

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 sits on Serverless Land.

The shape of the state machine

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 fans out per passenger, with MaxConcurrency set to 1000 to bound load on downstream booking and inventory systems, 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 the operator owns.

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 redrive is a no-op 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 design point is that routing, fan-out, retries and the audit trail live 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 a footgun in its own naming, that 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 keep the model out of the write path, which is the part most agent frameworks leave to the developer. Teams elsewhere can borrow the 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.