AWS’s Agents Propose. Deterministic Code Decides.

In the example, no agent directly commits a reservation or payment. Step Functions coordinates the workflow, Lambda validates structured output, and explicit service integrations own side effects, retries, idempotency, and audit history.

Let the model propose; let code commit

Models are useful where the input is ambiguous: extracting intent, comparing options, or producing a candidate plan. They are a poor substitute for a constraint that can be written as code: inventory must be available, a price must remain within a limit, an identifier must belong to the current account, or a payment must not be submitted twice.

The proposed action should therefore be a typed, versioned object. Deterministic validation can reject missing fields, stale state, unauthorized resources, impossible transitions, or values outside policy. Only then should a narrowly scoped component call the system of record.

A timeout does not mean the write failed

Multi-step agents encounter the same distributed-systems problems as every other workflow: partial failure, retries, duplicate messages, timeouts, and long waits for a person. Step Functions does not make model output correct, but it can make execution state visible and replayable.

Idempotency is particularly important. A model may repeat an instruction, an orchestrator may retry after a timeout, and a downstream API may have completed even though the response was lost. The write path needs a stable operation key and a documented response for duplicates. The receiving API must honor that key; an orchestrator cannot make a non-idempotent downstream write safe just by retaining execution history.

One failure I would test before enabling automatic writes

Consider a hypothetical booking adapter: it commits a reservation, but the response is lost before the workflow records success. On retry, generating a new operation ID can create a second reservation. Reusing the original key should return the existing outcome, provided the downstream service supports that contract.

The key must identify the approved operation, not just the passenger. Two legitimate decisions for the same passenger must not collide, and changing the destination or amount under an old key should be rejected. If the booking succeeds but compensation fails, retain the booking result and retry or reconcile the compensation step separately. Replaying the whole business transaction is not automatically a rollback.

I would test these cases against a disposable mock: lost response after commit, duplicate delivery, changed payload under the same key, and failure of the second write. Check the resulting records, not only whether the workflow finishes. These are proposed acceptance cases, not a deployed airline test.

Human review should be a state, not a chat

High-risk or uncertain proposals should enter a durable approval queue with the evidence, proposed change, policy result, and expiration time attached. A “yes” in a conversational transcript is difficult to audit and easy to detach from the exact transaction it approved. AWS places the wait on a separate callback task, not the AgentCore invocation. Bind approval to the proposed operation and recheck mutable availability and authorization before committing; an approval from hours ago cannot reserve inventory by itself.

I would also keep agent memory outside the authority decision. Context can explain a request, but current identity, entitlement, account ownership, and resource state should be fetched at validation time.

Before adopting the pattern, identify which component owns each write, its deduplication key, and how an operator resolves an unknown outcome. If that last answer is “rerun the agent,” the transaction design is not finished.

Source

AWS: validating multi-agent decisions with Step Functions and Bedrock AgentCore.