AWSAWS Certified Generative AI Developer - Professional2026-102.1 Implement agentic AI solutions and tool integrations
Bound reasoning cycles with explicit workflow state
Completed by the knowledge check
Learning objective
Use Step Functions to bound ReAct tool steps and chain-of-thought-style prompting across FM calls
Core idea
For an architect implementing an agent, the useful boundary is the next permitted transition. A model can propose another search or revise its answer; the workflow decides whether that proposal receives another model call or tool invocation. Put the counter, deadline, validation gate, and terminal outcome outside the prompt.
ReAct alternates reasoning, action, and observation. Chain-of-thought-style prompting asks a foundation model (FM) to reason through a problem. Neither pattern supplies an enforceable execution limit. In a Step Functions implementation, expose useful intermediate products such as a plan, an evidence summary, or a proposed action. You do not need to request or persist a model’s private reasoning to coordinate those products.
The choice between workflow and agent control belongs to 2.1.5. Here, assume that you chose a workflow boundary and need to make each cycle finite. A prompt saying “use at most three tools” expresses intent; an application-owned counter tested by a Choice state determines whether a fourth call is reachable.
How it works
Separate proposal, validation, action, and observation
Represent a cycle as model proposal, contract validation, allowed-tool execution, and observation normalization. Each external call is a Task; a Choice routes the validated result to completion, another cycle, or a terminal fallback. Give Choice a Default path for unexpected decisions. Without a matching rule or a default, Step Functions cannot transition out of the state.
The Amazon Bedrock optimized integration uses arn:aws:states:::bedrock:invokeModel. Its ModelId selects the model, and Body carries that model’s native request. Step Functions does not validate the model-specific content of Body. Validate the request before invocation and normalize the response before routing; the existence of an integration does not make arbitrary JSON a valid model contract.
If you prefer a tool-use message interface, a Lambda task can call Bedrock Converse. The caller supplies modelId, messages, and, for supported models, toolConfig. This is a different interface from the optimized InvokeModel task. Do not paste a Converse request into Body and assume that the target model accepts it. Request preparation and message dependencies are covered in 1.3.6 and 1.3.7.
Keep the requested tool name, validated arguments, tool result, evidence references, and workflow counters in separate fields. Treat observations as data from an external boundary. A retrieved page that instructs the agent to bypass validation must not change the allowlist or overwrite the remaining-step counter.
Charge every attempt to the same ledger
Define what one step means before setting its limit. A cycle might contain one model invocation and one tool call, while a parallel proposal might request several tools. Count the actual work you intend to bound. Keep separate counters for model attempts and tool attempts when those costs differ.
For counters local to one execution, use workflow variables declared through Assign, for example on a Pass state, and increment them with JSONata expressions. A following Choice checks the updated values before dispatch; assignments become visible in the next state. Keep the accounting Lambda option for a ledger shared across concurrent callers or executions; see 2.1.7. Never accept the model’s claim that a step was free, necessary, or outside the limit. Reserve an attempt before an external call so a timeout does not leave an uncounted attempt.
Every cycle passes the counter update and the Choice before dispatch, so a proposal reaches a tool only while the counters permit another cycle.
Retry.MaxAttempts limits retries for a state, not model calls across the loop; count retries and repeated visits through admission as described in 2.1.7, and see 1.2.5 for model failover.
Set top-level state machine TimeoutSeconds to bound the entire execution, including repeated cycles; exceeding it fails the execution with States.Timeout. Set TimeoutSeconds on external-call tasks as well; a task exceeding its own deadline fails with States.Timeout. Classify retryable service failures separately from invalid requests and rejected actions. Retry and Catch control recovery; they do not decide whether a repeated write is safe. For a side-effecting tool, preserve a stable operation identifier and reconcile an uncertain result before issuing another write.
Chain explicit products across model calls
A bounded prompting chain can use one FM call to extract candidate facts, another to assess them against supplied evidence, and another to draft an answer. Each stage should have an input contract and an acceptance gate. A fluent explanation from stage one is not proof that its facts are correct.
Choose intermediate products that the next stage can check: source identifiers, required fields, uncertainty labels, and action proposals. Pass the approved product rather than concatenating every previous response into the next prompt. Prompt design and refinement are covered in 1.6.7; this lesson adds execution control across the calls.
Bound the workflow payload as well as the step count. The optimized Bedrock integration permits up to 256 KiB in Body; for larger input it provides Input.S3Uri. Specify Body or Input, not both. Output.S3Uri writes the model response to S3 and replaces the response body with a location reference. Keep a reference and a validated summary in workflow state rather than repeatedly copying large observations.
Key distinctions and trade-offs
The following boundaries answer different questions:
| Boundary | What it determines | What it cannot prove |
|---|---|---|
| Prompt instruction | Requested reasoning and output behavior | That another action cannot execute |
Choice and trusted counters | Which workflow transition is allowed | That the selected tool result is true |
TimeoutSeconds | How long a task can remain active | That an external write never happened |
| Stage validation | Whether an intermediate product meets your contract | That all later stages remain correct |
More explicit stages improve inspection and recovery but add orchestration and model-call overhead. A fixed extraction–validation–draft chain can be easier to govern than a loop. A loop is useful when observations determine the next question, provided its continuation remains bounded.
Architecture / decision scenario
A support assistant investigates a disputed invoice. The team permits three read-only tool attempts and two model proposal attempts, followed by a final response or escalation. These are application policy values, not AWS quotas.
The first FM call proposes an invoice lookup. A validation task checks the tool allowlist and invoice identifier. The accounting task reserves a tool attempt, the lookup returns evidence, and the workflow stores a normalized observation. A second FM call requests another lookup and includes a suggested refund.
A Choice permits the lookup only if a tool attempt remains. It routes the refund proposal to the separate approval workflow in 2.1.9 rather than executing it. An extraction–assessment–draft chain then uses the approved evidence; each stage has its own contract and timeout. If assessment finds conflicting invoice versions, the workflow terminates with escalation instead of giving the model another unbudgeted cycle.
Common exam traps
- Treating a prompt’s maximum-step instruction as an execution boundary.
- Assuming
Retry.MaxAttemptsbounds every visit to a reasoning loop. - Treating a model’s intermediate explanation as validated evidence.
- Confusing
Conversefields with a nativeInvokeModelrequest body. - Counting cycles while ignoring multiple tools or retries within each cycle.
- Retrying a timed-out write without checking whether it already took effect.
What to remember
- The model proposes; trusted workflow state permits the next action.
- Bound model attempts, tool attempts, task duration, the execution deadline, and state size separately.
- Pass validated intermediate products across FM calls.
- Give unexpected decisions a terminal
Defaultroute. - A timeout bounds waiting, while reconciliation resolves uncertain side effects.
Knowledge check
A Step Functions ReAct loop lets the model propose tool calls. The prompt says to use at most three tools, yet in testing the model proposes a fourth and the workflow runs it. Which change makes a fourth tool call unreachable?
Choice before dispatchMaxAttempts: 3 on the Retry field of the tool TaskChoice state checks decides whether the dispatch transition exists at all. Retry.MaxAttempts limits retries of one failed state, not how many times the loop visits it.Each model-call Task in a reasoning loop has Retry with MaxAttempts: 2. A long dispute still produced 40 model invocations, because the loop revisits that Task on every cycle. What bounds the total model work for the request?
MaxAttempts on the model Task to 1Retry.MaxAttempts is per state, so each new visit starts its own retries and the loop’s total is unbounded. Charging every attempt, including retries and repeated visits, to one trusted ledger before dispatch is what makes the whole request finite.A chain uses one FM call to extract candidate facts from a contract and a second to draft a customer answer. The extraction call returns a fluent paragraph that mixes facts with guesses. What should the drafting call receive?
A team moves to Bedrock tool use and puts a Converse request with modelId, messages, and toolConfig into the Body of the optimized arn:aws:states:::bedrock:invokeModel Task. Which implementation is correct?
Converse from a Lambda task, keeping the optimized Task for native requestsBodyInput.S3Uri instead of BodytoolConfig into its ModelId parameterBody carries the model’s native InvokeModel request, and Step Functions does not validate it. Converse is a different interface with its own fields, so a Lambda task calls it. Input.S3Uri changes only where a large native body is stored, not its format.