AWSAWS Certified Generative AI Developer - Professional2026-101.6 Implement prompt engineering strategies and governance for FM interactions
Connect prompt stages with explicit data contracts
Completed by the knowledge check
Learning objective
Build sequential prompt chains using Amazon Bedrock Prompt Flows.
The objective calls the service capability Amazon Bedrock Prompt Flows. AWS documentation names it Amazon Bedrock Flows; this lesson uses that documented name.
Core idea
A sequential prompt chain makes the result of one stage an explicit input to the next. Amazon Bedrock Flows implements that relationship through a graph of nodes and connections. The architectural decision is where to place an intermediate contract that makes a multi-step task easier to inspect, validate, and maintain.
A chain is useful when stages have distinct responsibilities, such as extracting facts and then composing a response from those facts. Splitting one vague prompt into several vague prompts does not improve reliability. Each additional stage needs a defined input, a useful output, and an acceptance rule, because an upstream error can otherwise become authoritative context downstream.
Use this Bite for sequential dependencies. Conditional routing, reusable processing resources, and pre/postprocessing are covered in 1.6.9. Keep the prompt-testing practices from 1.6.6 at both the individual-stage and complete-flow levels.
How it works
Define the graph and its boundaries
A flow definition contains nodes and connections. CreateFlow creates the flow, and UpdateFlow updates its working draft. PrepareFlow prepares that draft so it can be invoked. The visual builder exposes the same design: add nodes, configure their inputs and outputs, and connect the appropriate ports.
Begin with a Flow input node and end with a Flow output node. The input node supplies a document output; the output node accepts a document input. Place prompt nodes between them in the order imposed by data dependencies. Draw the specific dependency that matters: the second prompt consumes the first prompt’s result, rather than receiving only the original request through another connection.
A prompt node can reference a saved Prompt management prompt or define one inline. A saved resource is selected through sourceConfiguration.resource.promptArn. An inline source specifies the model, template, and inference configuration inside the node. Refer to 1.6.2 for template variables and version-qualified prompt references rather than rebuilding their governance here.
The prompt node’s inputs fill its template variables, and its modelCompletion output is a String. This matters even when the generated text looks like JSON. A textual JSON response is still a string at the prompt node boundary; do not wire it directly into a downstream Object input and assume the connection parses it. Add explicit parsing when the next stage needs structured data.
Extract inputs without inventing transformations
Each node input declares a name, a type, and an expression. Bedrock evaluates the expression against the whole incoming value and checks whether the result matches the configured type. It also checks node output types. Supported data types include String, Number, Boolean, Object, and Array.
Input expressions use a supported subset of JSONPath and begin with $.data. For an object, $.data.request extracts the request field. For a primitive string, number, or boolean, only $.data is available. That distinction prevents a common design error: applying an object-field expression to the string emitted by a prompt node.
Keep extraction separate from transformation. An expression can select a field or array member; it does not replace application code that parses generated JSON, verifies a business rule, or reshapes a record. Use the processing boundaries in 1.6.9 when a stage needs those operations.
Preserve context deliberately. If the second prompt needs both the first response and the original approved evidence, configure both inputs and their connections. Do not assume every node receives an implicit shared conversation history. The node’s configured inputs are the contract you can inspect and test.
Prepare and test the working draft
Bedrock checks graph connectivity, the presence of a flow output node, required input/output type matches, and valid conditions with a default outcome. These checks establish structural validity. They do not prove that a summary is accurate or that an intermediate extraction preserved every important fact.
After changing a flow in the console, save it before testing; unsaved changes do not apply to the test. Through the API, prepare the working draft with PrepareFlow and invoke it through the test alias. AWS creates a DRAFT working version and a TSTALIASID test alias when the flow is created.
InvokeFlow identifies the flow through flowIdentifier and the alias through flowAliasIdentifier. The request supplies inputs with content.document, nodeName, and nodeOutputName to address the configured Flow input node and its output. Match the document’s type to the graph’s declared boundary.
Set enableTrace to true to inspect the intermediate inputs and outputs. In the console, Show trace also exposes node execution duration. Compare the first incorrect intermediate result with the final error to find the stage responsible. Changing the final prompt cannot repair an extraction that omitted the deciding fact unless the final stage also receives the original evidence.
Handle completion and publish a stable chain
InvokeFlow returns an event stream. A flowOutputEvent carries the output node’s response in content.document. A flowCompletionEvent reports completionReason, either SUCCESS or INPUT_REQUIRED; a failure arrives instead as a separate exception member of the stream, such as validationException or dependencyFailedException. The stream can also carry flowTraceEvent and flowMultiTurnInputRequestEvent. Treat the answer as complete only after SUCCESS, rather than accepting the first returned document as a completed answer.
Deployment uses an immutable numbered flow version and an alias that points to it. Invoke the production alias rather than the mutable working draft. To change the deployed chain, create a version and repoint the alias. An alias can also point back to a previous version. This releases the graph; prompt artifact review remains the concern of 1.6.3.
Key distinctions and trade-offs
Sequential dependency versus multiple invocations: Two prompts called by the same application are not necessarily a chain. A chain has an explicit result dependency between stages.
Graph validity versus answer quality: Type and connectivity checks catch wiring defects. They cannot establish factual completeness or correct reasoning. Test stage outputs and complete-flow outputs separately.
Prompt version versus flow version: A prompt reference identifies an instruction artifact. A flow version preserves the graph snapshot. Record both so that a passing test can be associated with the deployed configuration.
A single prompt avoids intermediate contracts and extra inference work. A chain gives you inspection points and narrower responsibilities, but also adds latency and opportunities to lose information. Keep a stage only when its measurable benefit justifies those costs.
Architecture / decision scenario
A technical-support assistant turns an incident report into an approved troubleshooting explanation. The team builds Flow input → extraction prompt → explanation prompt → Flow output. The first prompt extracts symptoms and observed facts; the second writes guidance from those facts and separately supplied approved evidence.
Both prompt completions are strings. The explanation prompt consumes the extraction string with $.data, while an object field from the original input supplies the approved evidence. The team checks every connection and prepares the draft before invoking TSTALIASID with tracing enabled.
A failing case reveals that extraction dropped the reported software version. The final explanation confidently recommends the wrong procedure. The team fixes the extraction contract and adds that incident to both stage and end-to-end regressions. After acceptable results, it creates an immutable flow version and points the production alias to it. The caller checks the output and completion events before returning guidance.
Common exam traps
- Assuming a generated JSON string is a typed flow object.
- Applying
$.data.fieldto a primitive prompt completion. - Assuming downstream prompts receive implicit shared history.
- Treating a prepared graph as proof of accurate responses.
- Testing unsaved changes or deploying through the mutable test alias.
- Returning the first stream event as the final successful answer.
What to remember
- Connect explicit inputs and outputs to express stage dependencies.
- Prompt nodes fill variables and emit
modelCompletionstrings. - Expressions extract data; processing code performs transformations.
- Prepare and trace the draft, then evaluate the full chain.
- Deploy an immutable flow version through an alias.
Knowledge check
A flow has an extraction prompt and an explanation prompt, both fed from the Flow input node. The explanation never reflects what extraction found. Which change makes the two stages a sequential chain?
modelCompletion to an explanation inputdocument to a second explanation inputAn extraction prompt returns text formatted as JSON, and the next node declares an Object input that reads its decision field. How should the flow connect them?
modelCompletion straight to the Object input$.data.decision as the expression on the Object inputPrepareFlow to convert the string during type checksmodelCompletion is a String , even when its text looks like JSON. For a primitive input only $.data is allowed, so a field expression cannot reach inside it, and preparation checks types rather than converting them; parsing and validation are an explicit processing step.A tested flow is ready for production traffic, and the team must be able to return quickly to an earlier graph. What should the application invoke?
DRAFT working version through TSTALIASIDTSTALIASID alias after the draft is prepared once moreTSTALIASID points to the mutable working draft and is meant for testing.The application calls InvokeFlow and reads the event stream. When may it treat the output document as a completed answer?
flowOutputEvent delivers a documentflowTraceEvent shows that the output node ranflowCompletionEvent reports completionReason: SUCCESSINPUT_REQUIRED while failures arrive as separate exception members of the stream. The caller accepts the document only after SUCCESS and then applies its own output validation.