AWSAWS Certified Generative AI Developer - Professional2026-100 Prerequisites
Choose who controls the next action
Completed by the knowledge check
Learning objective
Understand agent loops, tool calling, and deterministic versus agentic workflows. You should be able to identify who chooses the next action, who executes a tool, and which steps require application-controlled ordering. Detailed loop budgets belong to 2.1.1 and 2.1.7; workflow control belongs to 2.1.5.
Core idea
An agent loop repeatedly asks a model what to do, performs allowed actions, and returns observations so the model can decide whether to continue or answer. Tool calling is the structured interface for requesting those actions. The model’s request and the tool’s execution are separate events.
In a deterministic workflow, application-defined rules choose transitions. In an agentic workflow, the model can choose actions based on the task and observations. Deterministic describes control of the workflow, not a promise that a model called inside it produces identical text on every run. Most useful architectures can combine fixed transitions with bounded model decisions.
How it works
Follow the agent loop
A simple loop has a repeating decision boundary:
request + working context -> model decision
model requests a tool -> validate and execute -> return observation -> model
model returns an answer -> validate -> finish
budget exhausted or action denied -> controlled terminal outcomeThe observation changes what the model knows. An agent investigating a shipment might request the order record, discover that the carrier reference is missing, and then ask the customer for more information. That sequence is useful because the next step depends on information obtained during execution.
The loop also needs termination. A model might request the same unavailable record repeatedly or return an answer before the business operation succeeds. Your application decides whether to continue, deny an action, or stop. A prompt that asks the agent to avoid excessive tool calls expresses intent; it does not replace a counter and deadline enforced by the executor. Implementation of those limits belongs to 2.1.7.
Separate tool requests from tool execution
Bedrock client-side tool use makes this separation explicit. This execution pattern also applies to InvokeModel, Responses, and Chat Completions APIs; the following example uses Converse. With Converse, you provide definitions through toolConfig.tools. A toolSpec includes the tool’s name, description, and inputSchema. The model can return a content block containing toolUse and a response stopReason of tool_use.
The toolUse block identifies the requested tool, its input, and a toolUseId. In this client-side pattern, your code performs the tool call on the model’s behalf. Defining a tool does not make Bedrock execute that business API automatically. Use a model that supports the relevant tool-use capability; the existence of the request field does not establish support for every model.
The application checks the requested operation and arguments, executes an allowed implementation, and returns a toolResult with the matching toolUseId. The documented Converse example adds the tool result in a message with role: user after retaining the model’s tool-request message. The next model invocation receives that observation and can produce a response or make another permitted decision.
The model only requests the tool, and the application executes it and returns the observation.
A tool result can describe failure. The AWS example returns status: error when the requested record cannot be found. That is useful feedback for the model, but the application must still distinguish “not found” from a business operation that completed. Typed validation and retry-safe side effects belong to 2.1.10 and 2.1.11.
Define transitions with workflow rules
AWS Step Functions expresses workflows in Amazon States Language. A Task state performs a unit of work, and a Choice state selects a branch from defined conditions. Next connects states; Succeed and Fail provide explicit terminal outcomes. Application logic, rather than unrestricted model planning, defines the available transitions.
A deterministic workflow can still contain model inference. For example, a model classifies a ticket, the application validates that label, and a Choice state routes it to one of the permitted paths. The classifier can be variable, while the workflow consistently applies the same routing rules to the validated label. State-machine control and model-output variability are different layers.
Use defined transitions when a process must always authenticate a request, validate an operation, or obtain approval before a side effect. The model can help produce a proposal inside that process without owning permission to skip its gates. Human approval patterns belong to 2.1.9.
Combine fixed gates with agentic investigation
A hybrid workflow gives the model freedom where the information path is uncertain and fixes the process where ordering or authority is mandatory. A support agent can choose which read-only record to inspect while an application-owned process controls a refund.
That boundary must exist in execution logic. Telling the model to ask approval is weaker than ensuring that the refund tool rejects any request without an approved action. Tool descriptions help selection; they do not grant business permissions. Keep the available tool set aligned with the actions the caller is actually authorized to perform.
Key distinctions and trade-offs
Choose control by the property the process requires:
| Requirement | Suitable control | Reason |
|---|---|---|
| Every case must follow a known sequence | Deterministic workflow | Explicit states preserve required ordering |
| The evidence path depends on observations | Agentic loop | The model can choose the next useful investigation |
| Investigation is flexible but actions need approval | Hybrid | Fixed gates constrain consequential execution |
| One structured lookup is enough | Direct tool-calling interaction | A broad planning loop adds unnecessary decisions |
Tool calling does not by itself require a fully autonomous agent. An application can permit one lookup, return its result, and end the interaction. Conversely, an agent loop is more than a long prompt: it includes execution, observations, state updates, and termination decisions outside the model.
Agentic control adds flexibility but makes the execution path harder to predict. Fixed workflows make required paths easier to inspect but require you to encode the transitions. Neither choice removes the need to validate model output or business outcomes.
Architecture / decision scenario
A returns assistant handles both questions and refunds. For a question about a missing parcel, it can inspect an order and then choose whether carrier evidence or a customer clarification is needed. A bounded Converse loop exposes only the approved lookup tools and returns each observation through toolResult.
For a refund, the product requires identity verification, eligibility checks, and approval before payment. Those are fixed workflow gates. The team uses Step Functions Task states for the required work and Choice states for validated outcomes. The agent can summarize evidence and propose a refund; it cannot select a shortcut around approval.
A missing-order status: error returns the case to clarification rather than being described as a completed refund. The executor stops a repeating lookup when its application budget is exhausted. Flexible investigation and fixed transaction control coexist without confusing a tool request with execution or an answer with business completion.
Common exam traps
- Assuming a model’s tool request means the tool already executed.
- Expecting client-side Bedrock tool definitions to invoke business APIs automatically.
- Treating deterministic workflow control as deterministic generated text.
- Giving a model freedom to skip mandatory approval steps.
- Treating a prompt instruction as an enforced loop or permission limit.
- Assuming every tool-enabled interaction needs an autonomous planning loop.
What to remember
- The agent chooses; the executor validates and performs allowed actions.
- Match
toolUseIdwhen returning an observation throughtoolResult. - Agent loops need explicit continuation and termination decisions.
- Fixed states own mandatory ordering; models can reason inside those states.
- Choose hybrid control when flexible investigation meets consequential actions.
Knowledge check
A client-side Converse response contains a toolUse block and stopReason: tool_use. Which event has occurred?
In one turn the model requests two lookups of the same tool with different arguments. When the application returns both observations, what tells the model which result answers which request?
name repeated in each toolResulttoolUseId in each toolResultdescription repeated in each resulttoolUse request carries a toolUseId , and the toolResult returned for it carries the same id. A tool name cannot distinguish two calls of one tool, and list order is not the documented link.A support agent must investigate cases by choosing which read-only records to inspect, but every refund must pass identity, eligibility and approval checks in that order. Which control arrangement fits?
A state machine routes each ticket with Choice states on a validated model label. The model’s wording varies between runs. How should this workflow be classified?
An agent keeps requesting the same unavailable record. The team adds “Avoid excessive tool calls” to the system prompt, and the loop still runs on in some cases. What should enforce termination?