AWSAWS Certified Generative AI Developer - Professional2026-102.1 Implement agentic AI solutions and tool integrations
Put mandatory steps under workflow control
Completed by the knowledge check
Learning objective
Choose deterministic Step Functions workflows versus autonomous agent planning by control and failure requirements.
Core idea
Choose the execution owner from the behavior that must remain controlled. AWS Step Functions expresses permitted transitions in Amazon States Language (ASL). An autonomous agent lets a model select actions from its available tools after observing intermediate results. Both can call a model; the difference is who determines the next operation.
Use a workflow when required ordering, approval gates, timeouts, or recovery paths must be explicit. Use autonomous planning when the useful sequence cannot be enumerated economically and the agent can explore within a bounded permission scope. Use a hybrid when a business process has mandatory gates but one step benefits from flexible investigation.
“Deterministic workflow” describes the control structure, not the certainty of every output. A Step Functions task that invokes a foundation model can return variable content. Conversely, giving an agent a detailed procedural prompt does not turn its model-selected actions into an enforced state machine.
How it works
Express mandatory control in a state machine
Step Functions defines both Standard and Express workflows using ASL. A Task invokes work; transitions encode which step follows. Error handling belongs to the state machine rather than to a model’s interpretation of failure text.
A task’s Retry field defines retry behavior through ErrorEquals, IntervalSeconds, MaxAttempts, and BackoffRate. MaxDelaySeconds caps the wait interval, and JitterStrategy: FULL randomizes it to reduce simultaneous retry pressure. Select retriable operational failures explicitly; a denied authorization or invalid business request needs a terminal or alternative path rather than another identical attempt.
A Catch field routes handled failures to another state. TimeoutSeconds sets a task or execution timeout, and HeartbeatSeconds detects a task that fails to send the expected heartbeat. States.TaskFailed matches known task failures except States.Timeout, so a timeout needs its own matching error policy when you use that wildcard.
These mechanisms control retries and transitions. They do not automatically undo a completed side effect. If a task submits an operation and then loses its response, the next attempt must reconcile whether the operation already occurred. Give consequential operations an idempotency contract or a queryable operation identifier before deciding that retry is safe.
Choose workflow semantics deliberately
Standard workflows can run for up to one year and retain retrievable execution history for up to 90 days after completion. AWS describes their execution model as exactly once: tasks and states do not run more than once unless you specify Retry behavior. This fits durable, auditable processes and long approval waits.
That guarantee is not an end-to-end exactly-once business transaction across arbitrary external systems. Explicit retries, caller behavior, and uncertain downstream responses still matter. A state machine can execute the intended retry correctly while the business operation is duplicated because its endpoint lacks deduplication.
Express workflows run for up to five minutes. Asynchronous Express uses at-least-once execution semantics; Synchronous Express uses at-most-once semantics. Choose the mode as part of your failure contract rather than applying one Express guarantee to both. High-volume, short, idempotent processing can fit Express; a multi-day approval process cannot.
Service integration patterns also divide. Standard supports Request Response and, for supported integrations, Run a Job with .sync and Wait for a Callback with .waitForTaskToken. Express supports Request Response only. A callback pattern can hold a process at an external approval gate until the task token is returned; it is not interchangeable with a model saying that approval was granted.
Check support for the particular operation, not just the service name. The optimized Amazon Bedrock integration supports InvokeModel and CreateModelCustomizationJob, with .sync available for the customization job. A service’s support for waiting on a job does not mean that every model invocation should use .sync.
Bound autonomous work inside its chosen scope
A Strands Agent performs a feedback loop: the model chooses a tool, receives its observation, and decides what to do next until it returns a final answer. This can fit investigations where one finding determines which evidence source to consult next.
Your application must supply the tool permissions, shared attempt budget, deadline, and success criteria. See 2.1.1 for the loop controls and 2.1.2 for delegation. Model planning is useful when it can choose among genuinely acceptable paths. It adds risk when the business rule requires a specific gate that the model could skip.
In a hybrid architecture, the workflow owns the mandatory lifecycle and invokes an agent for a bounded step. For example, an agent may investigate an invoice discrepancy and return a proposed explanation. The workflow separately validates the result, obtains approval, and authorizes payment. Do not expose a payment tool to the investigator if payment is supposed to occur only after the workflow gate.
For AgentCore harnesses, use InvokeHarness through arn:aws:states:::bedrockagentcore:invokeHarness: it supports Request Response only, without .sync or .waitForTaskToken, and returns only the final assistant message in a Converse-shaped response. The Task has a 900-second maximum even if its TimeoutSeconds is larger. A Task timeout leaves the harness running until its own timeout, so align the harness timeout with the Task deadline and keep it within 900 seconds.
For a fixed inference step, the optimized Bedrock InvokeModel integration accepts a model-specific Body, which Step Functions does not validate. Validate the generated result separately; see 1.3.7 for native payload validation.
Key distinctions and trade-offs
The following requirements identify the execution owner:
| Requirement | Preferred control | Reason |
|---|---|---|
| Every payment requires a recorded approval | Standard workflow and supported callback integration | The gate is an explicit wait and transition |
| Investigation order depends on discovered evidence | Bounded agent planning | The next useful action changes with observations |
| Short, high-volume, idempotent transformations | Express workflow with the appropriate invocation mode | Duration and execution semantics match the work |
| Variable investigation followed by mandatory approval | Workflow around a bounded agent step | Flexible reasoning remains inside fixed business gates |
Workflow retry versus agent retry: A workflow retries according to named errors and configured intervals. An agent might choose another action after observing failure. Neither should retry a consequential operation without checking whether it already succeeded.
Execution completion versus acceptable output: A successful model task proves invocation completed. It does not prove the generated result meets schema, evidence, or business requirements. Keep the validation gate outside generated claims.
Architecture / decision scenario
A supplier-payment process must collect an invoice, investigate mismatches, obtain a finance approval, and submit payment. Mismatch investigation is variable: the useful next lookup depends on the discrepancy. Approval and payment ordering are mandatory.
The team uses a Standard workflow for the process because approvals can exceed five minutes and execution history is required. It invokes an AgentCore harness investigator through the InvokeHarness Task, with its own timeout aligned to the Task deadline. That agent receives read-only evidence tools and returns an explanation with source and invoice identifiers; it receives no payment capability.
The workflow validates the proposal and uses a separate .waitForTaskToken approval integration. In a JSONPath state definition, $$.Task.Token supplies the token; the approver returns it through SendTaskSuccess or SendTaskFailure. Set HeartbeatSeconds or TimeoutSeconds on the waiting task so that a lost callback cannot wait until the one-year execution quota. Payment uses a business operation identifier so that an uncertain response can be reconciled before retry. Retry handles selected transient failures; Catch routes exhausted attempts or denial to a review outcome.
A prompt-only agent with all tools would leave required ordering to model behavior. An entirely enumerated investigation would require maintaining every possible evidence path. The hybrid keeps mandatory controls explicit while allowing bounded exploration where it adds value.
Common exam traps
- Treating an ASL-defined transition as proof that model output is deterministic.
- Using a procedural prompt instead of an enforceable approval gate.
- Reading Standard’s exactly-once model as a universal guarantee against duplicate external effects.
- Applying at-least-once semantics to Synchronous Express.
- Choosing Express for a process that needs callback waits or more than five minutes.
- Assuming
States.TaskFailedalso matchesStates.Timeout. - Giving an investigator the consequential tool that a later workflow gate is meant to control.
What to remember
- Put mandatory ordering and recovery under an explicit execution owner.
- Choose Standard or Express from duration, integration patterns, and execution semantics.
- Configure retries by error class and preserve idempotency at side-effect boundaries.
- Use agents for bounded variable work, with external validation of their results.
- Combine a workflow and agent when control requirements differ across steps.
Knowledge check
An invoice-mismatch investigation needs lookups whose order depends on what each one finds. A finance approval, which can take days, must come before any payment. Which control architecture fits?
.waitForTaskTokenA short, high-volume pipeline runs as Asynchronous Express workflows. One step posts a ledger entry and is not idempotent, and the team assumes each execution runs at most once. Is the assumption sound?
Retry is specifiedRetry says otherwise describes Standard workflows; the integration-pattern limit is real but says nothing about duplicate execution.A Standard workflow calls a payment API, the response is lost, and the task’s Retry policy makes a second attempt. The payment API has no deduplication. What protects the supplier from being paid twice?
TimeoutSeconds on the payment taskJitterStrategy: FULL on the payment retrierRetry , and it never extended to effects in external systems. The first payment may have succeeded, so the retry needs an idempotency key or a queryable operation identifier to check that before acting; timeouts and jitter change when the retry happens, not whether it duplicates.A task’s Catch uses ErrorEquals: ["States.TaskFailed"] to route failures to a review state. When the task exceeds its TimeoutSeconds, the execution fails instead of reaching review. What explains it?
States.TaskFailed matches every known error except States.TimeoutCatch applies only after a Retry field has exhausted its attemptsTimeoutSeconds is enforced only when HeartbeatSeconds is also setCatch routes only errors that the task’s service raises itselfStates.TaskFailed is a wildcard for known task failures, with the deliberate exception of States.Timeout . A timeout needs its own matcher, or States.ALL as the last catcher, before it can reach the review path.A Standard workflow invokes an AgentCore harness through the InvokeHarness Task with TimeoutSeconds: 1800, and the harness’s own timeout is 60 minutes. What happens on a slow investigation?
.sync pattern.waitForTaskTokenInvokeHarness Task runs for at most 900 seconds whatever TimeoutSeconds says, and it supports Request Response only, without .sync or a callback. A Task timeout does not stop the harness, which runs on to its own timeout, so set that timeout within 900 seconds and in line with the Task deadline.References
- AWS, Choosing workflow type in Step Functions
- AWS, Handling errors in Step Functions workflows
- AWS, Discover service integration patterns in Step Functions
- AWS, Invoke and customize Amazon Bedrock models with Step Functions
- AWS, Strands Agents SDK: A technical deep dive into agent architectures and observability
- AWS, Invoke Amazon Bedrock AgentCore harness with Step Functions