AWSAWS Certified Generative AI Developer - Professional2026-102.5 Implement application integration patterns and development tools
Compose prompt chains through validated node contracts
Completed by the knowledge check
Learning objective
Compose prompt chains and reusable application workflows with Amazon Bedrock
Core idea
A prompt chain passes one stage’s output into another stage’s input. Its value comes from separating tasks that need different instructions or acceptance rules, not from adding model calls. Each boundary needs a contract: what data arrives, what the stage produces, and what allows execution to continue.
Amazon Bedrock Flows provides nodes and connections for this composition. A prompt node can define a prompt inline or use Prompt management; its inputs fill prompt variables, and its output is the generated model response. Logic nodes route data, and Lambda function nodes let your application perform custom work. These mechanisms make the chain explicit, but a connected graph is not evidence that its generated content is correct.
Use a chain when you can name the benefit of an intermediate result. For example, extract a candidate issue classification, validate it, then draft an answer for the accepted class. If no stage needs a separate contract, a single prompt can be easier to operate. The workflow-product decision belongs to 2.5.3; this lesson focuses on composing and releasing a chain after choosing Bedrock Flows.
How it works
Define the application workflow’s reusable boundary
A stable flow alias ARN plus a typed input/output contract makes the workflow reusable across application callers; see 1.6.8 for node mapping, versioned invocation, and completion events. A managed prompt reused across flows shares generation instructions, whereas the flow contract shares the complete application operation; see 1.6.9 for managed prompt references and conditional processing.
Define the contract from the caller’s task. A batch report workflow might accept a set of questions and approved evidence references, then return reviewed findings for each question. Keep caller identity, source identity, and work-unit identity distinct. A flow reused by an interactive interface and a background worker should not depend on an undocumented assumption that a human is available to answer a clarification.
Compose collection processing with Iterator and Collector
An Iterator node takes an array and emits its items one by one, not in parallel. Its outputs include arrayItem and arraySize; use a different orchestration boundary when parallel execution is required (see 2.5.7). Without collection, a downstream flow output node returns each item’s final result in a separate response. Choose this form when the caller deliberately consumes individual work-unit results rather than one combined report.
A downstream Collector node receives the processed arrayItem values and arraySize, then returns collectedArray. This lets you put a retrieval, generation, and validation sequence between iteration and collection. Retain the work-unit identifier in each processed result so the caller can associate a finding with its question; the collection’s array shape alone is not sufficient application provenance.
Iterator emits items one by one, and Collector turns their processed results into one array; without it, each item returns separately.
The two patterns have different acceptance boundaries. A caller receiving separate item responses can record accepted items while others remain unresolved. A caller expecting a collected report must decide whether an incomplete set is publishable. Define that rule explicitly and test failed or rejected items. Do not mistake the number of generated outputs for the number of accepted findings.
Introduce retrieval and agent work as distinct stages
A Knowledge base node takes retrievalQuery. With modelId configured, it generates a response from retrieved evidence; without modelId, it returns retrieved results as an array. Its outputs therefore differ: outputText as a string or retrievalResults as an array. Choose the mode from what the next stage needs, not merely from the fact that both use a knowledge base.
For a reusable evidence workflow, retrieved results can feed processing that retains source identity before a later prompt produces the answer. A generated string might fit a workflow that delegates that answer stage to the knowledge base node. Changing modes changes the downstream contract. It is not a transparent model substitution, because later nodes may expect an array rather than text.
An Agent node uses an agent alias ARN and returns the agent’s response. It accepts a prompt and associated prompt or session attributes. Place it where flexible tool orchestration adds value, such as investigating missing details, rather than using it as an unexamined replacement for every prompt node. The surrounding application still decides whether the returned response meets the workflow’s acceptance contract.
Agent nodes can require another user turn; AWS documents Flows multi-turn conversation as preview, subject to change. InvokeFlow represents this with flowMultiTurnInputRequestEvent, containing requested input and node information. Preserve the executionId when continuing that conversation; receiving a request for more information is a paused interaction, not the final answer. A background caller must have an explicit path to obtain the missing information or route the interaction for review. A workflow that assumes interactive input is not automatically reusable in an unattended job.
Persist intermediate artifacts and bound refinement
An S3 storage node accepts content and an object key, stores the data in the configured bucket, and returns its S3 URI. An S3 retrieval node takes an object key and loads content from the configured bucket; the documented content constraint is a UTF-8 encoded string. Choose a serialized artifact that meets this contract rather than assuming retrieval supports arbitrary binary input.
Use storage when another workflow stage or caller needs a named intermediate artifact, such as a reviewed evidence summary. Choose keys that preserve work-unit and revision identity, and keep acceptance state separate from the mere presence of an object. Successfully storing a draft does not mark it reviewed. Retrieval of an artifact also does not establish that it is the approved revision for this request.
A DoWhile loop node provides condition and maxIterations. The default maximum is 10, and the maximum must be positive; the loop exits when the condition becomes false or the bound is reached. For iterative refinement, make the condition depend on an explicit application check, and define a terminal result for exhaustion. Repeated rewriting should not erase the original evidence or make unsupported claims look approved.
Evaluate the composition as a whole. Include a failed item, insufficient retrieval, an Agent clarification, an unavailable stored artifact, and an exhausted refinement loop. See 1.6.8 for tracing and structural flow checks; here the acceptance question is whether the same application contract survives all those paths across each caller.
Key distinctions and trade-offs
Individual outputs versus a collected result: Iterator processes items serially and can expose separate results. Collector forms one array for downstream work. Choose the completion policy the caller actually needs.
Evidence retrieval versus generated answers: A Knowledge base node without modelId returns an array; adding modelId returns generated text. That choice changes what downstream processing can inspect.
Reusable workflow versus reusable prompt: A prompt shares instructions. A workflow shares orchestration and its input/output contract, including whether it can ask for another turn.
Persistence improves handoff when intermediates have explicit identity and acceptance state. It creates stale-artifact risk if callers load a convenient key without checking which revision was approved. Extra agent or refinement steps also increase latency, so retain them only when complete-workflow evaluation demonstrates value.
Architecture / decision scenario
An interactive analyst interface and a background reporting worker share a report flow through one alias and contract. Iterator processes an array of questions. For each question, a Knowledge base node omits modelId to return evidence for downstream validation, then a prompt produces a finding. Collector assembles results and their acceptance status into a report array.
An Agent node investigates ambiguous evidence. The interface can answer a flowMultiTurnInputRequestEvent; the background worker instead records a pending review rather than claiming completion. Both callers preserve execution and work-unit identity. The team measures serial processing latency and does not assume Iterator runs the questions concurrently.
The workflow stores a serialized reviewed summary with an S3 storage node. A later stage retrieves the UTF-8 artifact by its revision-specific key. A DoWhile refinement loop has an explicit bound and returns unresolved findings when exhausted. Acceptance tests verify that collection, clarification, persistence, and refinement preserve the same contract for both callers.
Common exam traps
- Expecting Iterator to process its array items in parallel.
- Expecting one combined response without a Collector when output follows iteration.
- Adding
modelIdto a Knowledge base node while keeping an array-based downstream contract. - Treating an Agent request for another turn as a completed background job.
- Using S3 retrieval for arbitrary binary content rather than its documented UTF-8 string input.
What to remember
- Reuse the alias and application contract together, including nonterminal outcomes.
- Choose separate item outputs or Collector aggregation deliberately.
- Preserve the distinction between retrieved evidence and generated text.
- Plan caller behavior for multi-turn Agent input requests.
- Give stored intermediates revision identity and refinement loops a terminal bound.
Knowledge check
A report flow sends 40 questions through an Iterator node, and the team set its latency target assuming the questions run concurrently. Measured latency is far above the target. What explains the gap, and what follows?
maxIterations settingmaxIterations belongs to the DoWhile loop node, and a Collector only assembles results; concurrency has to come from an orchestration layer outside the Iterator.After an Iterator and a per-question prompt node, the flow output node returns one response per question, but the caller expects a single report. Which change provides it?
arrayItem and the arraySizearraySize to the output node so it merges the itemscollectedArray ; the application still keeps each finding’s work-unit identity and decides whether an incomplete set can be published.A Knowledge base node with no modelId feeds a Lambda node that checks the source of each retrieved passage. A teammate adds modelId to the Knowledge base node to improve answers. What changes for the Lambda node?
retrievalQueryoutputText , not a retrievalResults arraymodelId the node returns retrieved results as an array; with it, the node returns a generated string. That changes what downstream stages can inspect, so it is a contract change, not a transparent model swap.A background reporting job invokes the same flow that an interactive interface uses. An Agent node emits flowMultiTurnInputRequestEvent, and no person is available to answer. What should the job record?
executionId for continuation or reviewexecutionIdexecutionId , so an unattended caller needs an explicit pending or review path rather than inventing input or starting over.