Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsAWS Step Functions helps you build an AI application by coordinating the work around a model: it can call Amazon Bedrock, pass results between tasks, branch or repeat steps, run work in parallel, and wait for a person or another service. Bedrock supplies model and agent capabilities; Step Functions defines when tasks run and how the application responds to their results. It is an orchestrator, not an AI model, and it does not make model outputs more accurate.
What Step Functions does in an AI application
AWS describes Step Functions as a way to create workflows, also called state machines, for distributed applications, process automation, microservices, and data or machine-learning pipelines. A state machine represents a process as states; a Task state hands a unit of work to another service or API. As AWS puts it, “With AWS Step Functions, you can create workflows, also called State machines, to build distributed applications, automate processes, orchestrate microservices, and create data and machine learning pipelines.” AWS Step Functions documentation
In an AI workflow, that separation clarifies responsibilities: Bedrock performs model inference or provides agent capabilities, while Step Functions controls the sequence, branching, data flow, and waits. A workflow might prepare input, invoke a model, inspect the result, route it to another task, and request human review when needed. The model request format, model identifier, permissions, and response handling still depend on the specific model and application.
How to connect Step Functions to Amazon Bedrock
Step Functions has an optimized Bedrock integration for invoking models and running model-customization jobs. A Task state can invoke a specified model; the state machine then continues with the task result according to its definition. See AWS’s Bedrock integration documentation for the supported actions and request details.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →#1 Best Overall
- Define the application steps. Decide what happens before and after inference: for example, input preparation, model invocation, validation, a conditional route, or a human approval task.
- Choose the Bedrock operation and model. Configure the integration for the operation you need and provide the model-specific request body. Do not assume one payload works for every model.
- Connect the task to the rest of the state machine. Map the request and result so later states receive the fields they need. Add branches, loops, or parallel tasks when the application requires them.
- Set permissions and failure handling. Grant the state machine only the required IAM permissions, and decide how errors, retries, timeouts, and unsuccessful results should be handled.
- Choose the workflow type and integration pattern. Confirm that the selected workflow supports the waiting behavior you need before building around it.
Choose the workflow type around the wait you need
Step Functions integrations use request-response, run a job and wait (.sync), or wait for a callback with a task token (.waitForTaskToken). Support varies by workflow type and integrated service; these patterns are not interchangeable. AWS’s integration overview documents Bedrock request-response for Standard and Express workflows, while Bedrock job-waiting and callback patterns are documented for Standard.
| Workflow type | Bedrock patterns documented by AWS | Use this distinction when |
|---|---|---|
| Standard | Request-response, run a job and wait, and callback patterns for Bedrock, as listed in AWS’s integration documentation. | The workflow needs a documented job-waiting or callback pattern, or its process design otherwise calls for Standard. |
| Express | Request-response for Bedrock, as listed in AWS’s integration documentation. | The required Bedrock interaction is request-response and the rest of the workflow fits Express. |
Check the current optimized integration matrix for the service-specific support before implementation. Standard and Express do not share every integration pattern.
Patterns for building generative AI workflows
AWS’s serverless prompt-chaining example combines Step Functions, Bedrock, and Bedrock Agents. Its scenarios illustrate different orchestration shapes; they are useful starting points, not proof that generated content is correct or that the sample is production-hardened. The AWS prompt-chaining example demonstrates:
- Sequential prompt chaining: Run one analysis, then use its output as input to the next task.
- Iterative processing: Iterate over a generated list, applying work to each item.
- Parallel work: Run distinct prompts at the same time, or run one prompt with different inference settings and compare the outputs in a later state.
- Human input: Insert a person’s review or decision into the workflow where automated processing should pause for input.
- Agent and external API interaction: Chain agents that interact with external APIs as part of a larger process.
These patterns help make application control flow explicit. They do not replace application-level checks for whether a model response is valid, safe, or suitable for the next step.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
When to use Distributed Map for AI workloads
For workloads that fan out across large datasets, a Distributed Map state can run iterations as separate child workflow executions with separate histories. AWS lists example reasons to consider Distributed mode: a dataset larger than 256 KiB, an execution history expected to exceed 25,000 events, or a need for more than 40 concurrent iterations. If no concurrency setting is specified, AWS documents a default of 10,000 parallel child executions. That default is not a recommended target for every workload.
Distributed mode is supported in Standard workflows, not Express. Review the Distributed Map guidance and validate concurrency, quotas, payload handling, and cost for your workload before setting a large fan-out.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Where AgentCore fits
AWS documents a Step Functions integration that invokes a Bedrock AgentCore harness. AWS describes the harness as a managed runtime coordinating model inference, tool use, and multi-turn conversations, with access to tools and memory. The capability offers another option when an application needs agent behavior alongside explicit workflow control; it does not eliminate the need to decide which steps the surrounding state machine should coordinate.
AWS release listings date an AgentCore-powered agentic reasoning step to 2026-06-03 and the addition of 28 integrations, including Bedrock AgentCore, to 2026-03-26. Those dates are launch announcements, not confirmation of availability in every AWS account or Region. Check the current AgentCore integration documentation for support in your target Region and account.
Design checks before deployment
- Workflow shape: Decide whether the process is sequential, conditional, iterative, parallel, human-reviewed, or agent-driven.
- Waiting requirements: Match request-response, job waiting, or callback behavior to the integration pattern supported by the chosen workflow type and service.
- Model-specific details: Verify the model ID, request body, response structure, payload limits, and required permissions for the exact operation.
- Reliability and operations: Define error handling, retries, timeouts, observability, and how downstream tasks should treat incomplete or invalid outputs.
- Scale and cost: Set concurrency deliberately, account for child executions and service quotas, and assess the workload’s actual cost rather than relying on a published default.
- Regional support: Confirm that each required service and integration is available in the AWS Region where the application will run.
For implementation details and further patterns, use AWS’s Step Functions prompt-chaining sample alongside the service integration guides. Recheck the current documentation when implementing: supported patterns, request requirements, quotas, and regional availability are service-specific.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
