Chaining Steps with Amazon Bedrock Flows
Learn how to build a multi-step AI workflow with Amazon Bedrock Flows. Create a branching support-triage flow on the visual canvas, test it, publish a version with an alias, and call it from Python.
Series: Amazon Bedrock (13 articles)
- …
- 5Chaining Steps with Amazon Bedrock Flows This article
Build a small multi-step AI workflow visually, version it, and call it from Python as if it were a single function.
So far in this series, each article has made a single call to a model. Real apps rarely stop there. A support assistant might read a message, decide what kind of request it is, and then write a different kind of reply depending on the answer. That's three steps, and you can either wire them together in code or build them as a flow.
Amazon Bedrock Flows (often called prompt flows) lets you do the second. You draw the steps on a canvas, connect them, test the whole thing, and call it from your app with one request. In this article we'll build a small one and invoke it from Python.
[Add a sentence or two here about a multi-step task you wanted to automate, or why you looked at flows.]
What you need
- The setup from the earlier articles: Python, boto3 and working Bedrock credentials
- A model you can invoke, with its ID copied from the model's card
- About forty minutes
Flows is an evolving feature, and some parts of it have been added in stages. Check the current Amazon Bedrock documentation for what's available in your Region, and for pricing, before you start.
The flow we'll build
A tiny support triage:
- Input: a customer message arrives.
- Classify: a prompt decides whether the message is about billing or something else.
- Condition: the flow follows one path or the other based on that answer.
- Reply: a different prompt drafts a reply for each path.
- Output: the drafted reply comes back.
It's small on purpose. Once you've built this, the same pattern covers a lot of real workflows.
Step 1: Create the flow
- In the Amazon Bedrock console, open Flows and choose Create flow.
- Name it, for example
support-triage, and let the console create a service role for it. The flow uses that role to call models, so it needs permission to invoke the models you choose.
- You'll land on a canvas with an Input node and an Output node already placed. Everything else goes between them.
Step 2: Add the nodes
Drag these onto the canvas from the node list:
- A prompt node for classifying. Write a short instruction with a variable for the customer's message, such as: "Read this message and answer with one word, billing or other: {{message}}". Pick your model and keep the temperature low so the answer is consistent.
- A condition node. Add a condition that checks whether the classification equals billing. The node has one path for when the condition is true and a default path for everything else. Check the documentation for the exact condition syntax.
- Two more prompt nodes for replies. One drafts a billing reply, the other a general one. Each takes the original message as a variable.
Give each node a clear name. You'll see those names again in your code and in error messages.
Step 3: Connect the nodes
Connections tell the flow where each piece of data goes. Drag from one node's output dot to the next node's input dot.
- Input goes to the classify prompt, and also to both reply prompts, since they need the original message.
- The classify prompt goes to the condition node.
- The condition node's true path leads to the billing reply prompt, and its default path leads to the general reply prompt.
- Both reply prompts go to the Output node.
The canvas will warn you about anything left unconnected or mismatched, such as a text output feeding something that expects an object. Fix those before you go on.
Step 4: Test inside the console
Use the test panel to send a sample message. Try one that is clearly about billing, one that isn't, and one that's ambiguous. Watch which path each takes and read the reply it produces.
This is where flows are most useful. You can see exactly what each node received and produced, so when something goes wrong you can find the step that caused it.
Step 5: Prepare, version and create an alias
When the flow works:
- Prepare it. This validates the flow and makes the latest draft ready to run.
- Create a version. It's a snapshot that won't change, just as with prompts and guardrails.
- Create an alias that points at that version. Your app calls the alias, and you move the alias to a newer version when you're ready.
The alias is the nice part. When you improve the flow later, you publish a new version and repoint the alias. Your code stays exactly the same.
Note the flow ID and the alias ID. You'll need both.
Step 6: Call it from Python
Flows are invoked through the
bedrock-agent-runtime client, not bedrock-runtime . It's the third client name in this series, so it's worth double-checking which one you've grabbed.Python
import boto3REGION = "us-east-1" # use your RegionFLOW_ID = "YOUR_FLOW_ID"FLOW_ALIAS_ID = "YOUR_ALIAS_ID"client = boto3.client("bedrock-agent-runtime", region_name=REGION)response = client.invoke_flow(flowIdentifier=FLOW_ID,flowAliasIdentifier=FLOW_ALIAS_ID,inputs=[{"content": {"document": "I was charged twice for my March invoice."},"nodeName": "FlowInputNode","nodeOutputName": "document",}],)for event in response["responseStream"]:if "flowOutputEvent" in event:print(event["flowOutputEvent"]["content"]["document"])
A few things to note.
The response comes back as a stream of events, so you loop over it and pick out the one that holds the flow's output.
The
nodeName should match the name of your input node. If you left the default, it's FlowInputNode , but check what your canvas shows. A mismatch here is the most common reason a first call fails.The
document value is the text you want to send in. It can also be a structured object if your flow expects one.When something goes wrong
A validation error on the input. Check the node name and output name against your canvas, and check that the data type matches what the Input node expects.
An access error. Make sure your identity is allowed to invoke the flow, and that the flow's service role can invoke the models it uses.
The wrong path is taken. Look at the classify node's output in the test panel. If the model answers "Billing." or "billing issue" and your condition expects exactly "billing," the path won't match. Tighten the prompt, or loosen the condition.
It's slow. Every prompt node is a separate model call, and they run in sequence along a path. Fewer nodes and shorter outputs mean a faster flow.
Flow or plain code?
It's a fair question. A flow is a good fit when the steps are fairly simple, you want to see and change the structure visually, or non-developers need to adjust it. Plain code is better when you need heavy logic, loops over large data, or tight control over error handling. Many teams use both, with flows for the model-focused steps and code around them.
Mistakes to avoid
- Calling the draft instead of an alias. Use a version behind an alias, so your app doesn't change underneath you.
- Vague node names. "Prompt1" and "Prompt2" become a puzzle in a month.
- Skipping tests on ambiguous inputs. A branch that works for obvious cases can break on real ones.
- Forgetting the cost. Each prompt node is a billable model call, so a five-node flow can cost five times a single call.
Where we are now
You've built a branching workflow, tested it, versioned it and called it from code. Combined with reusable prompts and guardrails from the earlier articles, you now have the main building blocks of a managed Bedrock app.
In the next article we'll bring in your own documents with a knowledge base, so the model answers from your content instead of guessing.
Features, node types, condition syntax, Region availability and pricing change often. Check the current Amazon Bedrock documentation before you follow any step here.
Series: Amazon Bedrock (13 articles)
- …
- 5Chaining Steps with Amazon Bedrock Flows This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article