AWS’s Agents Propose. Deterministic Code Decides.

AWS published a multi-agent reference architecture in which models interpret requests and propose actions, but deterministic code validates the decisions and performs the real-world writes. That boundary is more important than the architecture’s agent count.

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.

Orchestration supplies the boring guarantees

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.

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.

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.

A lot of agent architecture is presented as a choice of models and prompts. AWS’s example is useful because it makes the less glamorous layer visible. Agents propose; ordinary software decides whether a proposal is valid and owns what happens next.

Source

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