AWSAWS Certified Generative AI Developer - Professional2026-102.5 Implement application integration patterns and development tools
Assign reasoning and execution separate boundaries
Completed by the knowledge check
Learning objective
Build advanced application-level agent orchestration with Strands Agents, AWS Agent Squad, and Step Functions patterns
Core idea
An application can need three different forms of orchestration. A model decides which tools help answer a request. A router chooses a specialist for the request. A workflow enforces required business steps and recovery behavior. Treat these as separate decisions, even when one application uses all three.
AWS describes Strands Agents as an open-source, model-first SDK with multi-agent collaboration patterns. AWS’s Agent Squad guidance demonstrates classifier-based routing to specialized agents and human support. Step Functions expresses execution policy in Amazon States Language through states and transitions. Choose the layer from the decision it must own, rather than from the number of agents in a diagram.
This distinction matters when reasoning leads to a side effect. A model can propose a refund, but the application must establish authorization, validate the amount, and decide whether an interrupted execution can safely retry. Adding another agent does not make those requirements durable or enforceable. Tool contracts and retry-safe effects are covered in 2.1.10 and 2.1.11; orchestration must preserve them.
How it works
Compose routing and reasoning without two owners
Strands supports model-led tool use and Swarm, Graph, and Workflow collaboration patterns; see 2.1.2 for selecting a coordination pattern and assigning the final result’s owner. At the application boundary, decide whether a request needs one specialist’s answer or an aggregate of several contributions. A router selecting one destination and a supervisor combining several results solve different problems. Avoid having both silently reinterpret the original request.
AWS’s Agent Squad guidance uses a Bedrock Classifier in a Lambda handler to route to order management, product information, or human support. Its SQS queues and DynamoDB conversation records illustrate a complete application around routing, rather than required dependencies for every deployment. If the selected destination is a Strands specialist, define the handoff as an explicit adapter contract: request identity, selected task, permitted context, and expected result.
Validate classifier output against configured destinations and keep authorization at the business boundary, as described in 2.1.2. Here the additional concern is ownership across layers. Record which component accepted the request, which specialist returned a proposal, and which component publishes the final response. A specialist timeout must not leave the router claiming success merely because classification completed.
A composed request envelope should preserve the original task separately from a delegated subtask. Include enough approved evidence for the specialist to work, without copying every conversation turn into every agent. Return a bounded proposal or answer plus its acceptance evidence. This is an application contract, not an automatic property of Strands or Agent Squad. Test it with a request spanning domains and with one unavailable specialist.
Choose how the workflow invokes agent work
Step Functions can put required transitions around agent work; see 2.1.5 for workflow types, callback gates, and recovery policy, and 2.1.6 for bounded reasoning with the optimized Bedrock InvokeModel integration. A state machine wrapping an agent must also choose its execution interface. Running your Strands application in a Lambda Task and invoking an AgentCore harness are different integration choices.
For a Lambda Task, your handler owns construction of the Strands agent, adaptation of its result, and the response contract passed back to the workflow. Choose this boundary when you need your application code to control that adapter. Do not assume moving an agent into a Task makes every internal tool call visible as a separate workflow state. The workflow observes the handler’s returned result; your application must record the detail needed to investigate internal work.
AWS also provides AgentCore InvokeHarness in Workflow Studio, using arn:aws:states:::bedrockagentcore:invokeHarness. A harness is a managed runtime that orchestrates model inference, tool use, and multi-turn conversations. Configure HarnessArn to select it. This integration is an alternative for harness-backed agent work, not a claim that a Strands object in a Lambda handler is automatically an InvokeHarness deployment.
The optimized harness integration supports Request Response only: neither .sync nor .waitForTaskToken is supported. If your business process needs external approval, place that gate in a separate supported workflow task. Appending a callback suffix to the harness resource does not turn an agent conversation into an approval integration.
The response is Converse-shaped, but only the final assistant message is returned in Output.Message. Earlier conversation turns are discarded, and Output.Message.Content contains only text: tool-use and reasoning blocks are omitted. Usage.InputTokens, Usage.OutputTokens, and Usage.TotalTokens aggregate consumption across turns; Metrics.LatencyMs aggregates invocation latency. These fields help assess the agent step’s operating cost and timing, but its final message is not a complete action audit. AWS exposes a CloudWatch link beside the agent step in execution details for a turn-by-turn view.
Align task lifetime and result aggregation
An InvokeHarness Task has a maximum execution time of 900 seconds, even when TimeoutSeconds is larger. After the Task times out, the harness continues until its own configured timeout. AWS advises keeping the harness timeout within 15 minutes to avoid unexpected costs. Treat this as two execution lifetimes: the workflow’s wait and the agent’s remaining activity.
A timeout handler should record an unresolved outcome and reconcile any possible effects before submitting replacement work; see 2.1.11 for retry-safe effects. A new invocation might overlap the first harness if its lifetime extends beyond the workflow wait. Choose compatible deadlines before deciding that a timed-out task means the agent stopped.
A Task timeout ends the workflow’s wait, not the harness’s activity.
For a request containing independent specialist tasks, a Map state can run the same workflow steps for each input element. That is application-defined fan-out, distinct from an Agent Squad classifier choosing one destination. Attach each result to its work unit and define whether the final answer requires every specialist, accepts a partial set, or routes incomplete work for review. A Choice can select the accepted aggregate route after your application validates the results.
Keep aggregation outside the specialist when the caller needs a uniform completion policy. Otherwise one specialist might declare success with missing evidence while another treats the same condition as failure. The application should expose a consistent terminal outcome regardless of whether reasoning ran in a Lambda handler or a harness task.
Key distinctions and trade-offs
The following boundaries help choose a primary orchestration owner:
| Need | Mechanism | Application responsibility |
|---|---|---|
| Flexible reasoning over tools | Strands agent loop and collaboration patterns | Bound tools, context, and accepted proposals |
| Choose a domain specialist | Agent Squad routing with a Bedrock Classifier in AWS guidance | Validate routes and preserve request identity |
| Required transitions and recovery | Step Functions states, Retry, and Catch | Define valid states and retry-safe effects |
A model-driven plan adapts to unfamiliar requests but makes execution less predictable. An explicit state machine makes transitions reviewable but requires you to model the branches. Layer them when both are necessary: reasoning within a bounded task, execution policy outside it. Avoid two independent routers making contradictory decisions about the same request.
Architecture / decision scenario
A support application uses Agent Squad to classify incoming requests. Product requests go to a Strands specialist running in a Lambda Task, where the handler returns a validated evidence package. A compound return investigation becomes an application work list processed through Map rather than a single classifier destination.
One investigation step invokes an AgentCore harness. The team configures the harness timeout within the 900-second Task cap and records the final message, aggregate usage, and invocation latency. It retains separate action evidence because tool-use blocks and earlier turns are not present in the returned content.
The workflow combines accepted specialist results, then applies the separate business approval gate from 2.1.5. It does not put .waitForTaskToken on InvokeHarness. If the harness task times out, the recovery route marks the investigation unresolved and checks possible effects before replacement work. Routing, reasoning, and durable completion now have distinct owners and compatible interfaces.
Common exam traps
- Expecting an Agent Squad single-destination route to aggregate every specialist’s findings.
- Treating InvokeHarness as an automatic deployment path for any Strands object.
- Adding
.syncor.waitForTaskTokento the optimized harness integration. - Expecting
Output.Message.Contentto contain the agent’s tool calls or earlier turns. - Assuming a 900-second harness Task timeout stops the harness itself.
What to remember
- Give routing, delegated reasoning, and final publication separate owners.
- Choose a Lambda adapter or InvokeHarness from the required execution interface.
- InvokeHarness returns final text and aggregate metrics, not the full conversation.
- Align the harness lifetime with the workflow wait and reconcile uncertain effects.
- Define aggregate acceptance explicitly when Map fans work out to specialists.
Knowledge check
An application routes support requests with Agent Squad’s Bedrock Classifier. One request needs three independent investigations — a delayed order, a damaged item and a refund — and the answer must combine all three findings. Which design produces that answer?
A Step Functions workflow invokes an AgentCore harness and must pause for human approval before the agent’s proposal is applied. Which arrangement is supported?
invokeHarness.waitForTaskToken resource and have the reviewer return the tokeninvokeHarness.sync resource and treat its final message as the approval.sync nor .waitForTaskToken is available. Approval belongs in its own supported workflow task, outside the agent’s conversation.Compliance needs a record of every tool an agent called during an InvokeHarness step, and the team plans to read it from the Task’s output. What will that output provide?
Output.MessageUsage and Metrics.LatencyMs . A tool-call record must come from separate action evidence or the turn-by-turn CloudWatch view, not from the final text.An InvokeHarness Task sets TimeoutSeconds to 1800, and the harness itself may run for 30 minutes. After 15 minutes the Task times out, and its Catch immediately submits a fresh invocation. What is the risk, and what fixes it?
TimeoutSeconds ; raise it further so the Task outlasts the harnessOutput.MessageTimeoutSeconds says, and a timed-out Task does not stop the harness, which runs to its own timeout. A replacement can overlap the first run, so align the two lifetimes and reconcile possible effects before submitting new work.