Amazon Bedrock AgentCore and AWS Step Functions can both participate in a multi-step AI application, but they solve different orchestration problems. AgentCore is designed for dynamic agentic systems in which a model can reason about a goal, use tools, maintain context, and decide what to do next. Step Functions is a state-machine service in which the allowed workflow and transitions are declared ahead of time.
That distinction is increasingly important because Amazon Bedrock Agents entered maintenance mode as Amazon Bedrock Agents Classic and stopped accepting new customers on July 30, 2026. AWS directs new agentic workloads toward AgentCore, while Step Functions remains the service for deterministic workflow orchestration.
Agentic reasoning and deterministic workflow execution have different owners. An agent may select which information to request or recommend a next action, while AWS Step Functions can enforce a declared multi-step process with explicit retries, approvals and observable states. For an equipment-replacement request, require the agent’s proposal to be checked by an authorized inventory service before a state machine commits the order; a conversational assertion that approval occurred is not a transaction receipt. Bedrock AgentCore provides managed capabilities for newer agent workloads, whereas AWS stopped admitting new customers to Bedrock Agents Classic in July 2026. This service lifecycle matters when selecting a greenfield design. In third-party AWS AIP-C01 agent-orchestration practice cases, the best reasoning names where dynamic decision-making ends, where deterministic control begins and how failure or duplicate events are recovered. These are independent exam-preparation questions, not the AWS official exam portal.
Agentic orchestration chooses actions at runtime
An agentic application is not merely a long sequence of API calls. The model interprets the current goal and context, then decides which tool or action is useful next.
An operations agent might inspect an alert, search a knowledge source, query an asset inventory, ask the user for clarification, call a remediation tool, evaluate the result, and decide whether another action is required. Another request may follow a completely different path.
That runtime flexibility is the defining feature. The developer constrains the tools, identity, policies, memory, and safety boundaries, but does not predeclare every possible sequence of steps.
This makes agents useful for open-ended tasks where the correct path depends on natural-language intent and intermediate results. It also creates new governance requirements because the application must control what the agent is allowed to decide and execute.
AgentCore provides managed building blocks for agents
Amazon Bedrock AgentCore is a platform for building, deploying, connecting, and operating AI agents. Its capabilities include managed runtime environments, memory, identity and credential management, gateways for tools and services, built-in tools, observability, and other agent-focused infrastructure.
The key architectural value is that these capabilities address problems specific to agentic workloads. An agent needs a secure identity when it calls an external service, a place to run reliably, a way to expose governed tools, and observability that can trace interactions beyond one model invocation.
AgentCore Identity, for example, provides workload identities and credential-management patterns intended for agents and automated workloads. That is different from embedding long-lived API keys in prompts or application code. Gateway can centralize access to tools and runtime targets, while resource-based and identity-based policies help define who may invoke agent resources.
AgentCore therefore belongs where the model itself participates in deciding the next action.
Step Functions executes a declared state machine
Step Functions defines workflows as state machines. States can invoke services, branch with Choice, run work in parallel, iterate over collections, wait, retry, catch failures, and terminate explicitly.
The important point is that the valid paths are defined before execution. Input data can influence which branch runs, but the application still knows which states and transitions are possible.
That determinism is valuable for business processes, approvals, ETL orchestration, infrastructure workflows, and regulated operations where the organization needs predictable sequencing and auditable control flow.
Step Functions is also strong when error handling itself must be explicit. Retry policies, catch paths, timeout behavior, compensation steps, and failure states can be modeled directly in the workflow rather than left to a model’s reasoning.
The choice is dynamic reasoning versus deterministic control
A useful test is to ask who decides the next step.
If a model should evaluate the user’s goal and choose among tools dynamically, the workload is agentic. If application designers can enumerate the possible states and want the workflow to follow those declared transitions exactly, Step Functions is the natural orchestrator.
This does not mean agents are “smart” and state machines are “simple.” A Step Functions workflow can be extremely sophisticated, and an agent can still be constrained to a narrow set of actions. The distinction is where decision authority resides.
A financial approval process may require deterministic state transitions even if one state uses a foundation model to summarize a document. A research assistant may need dynamic tool selection even if some individual tool calls launch deterministic workflows behind the scenes.
Combine them when an agent reaches a controlled business process
AgentCore and Step Functions can be combined, but the handoff must respect the service integration pattern. AWS documents an optimized Step Functions InvokeHarness task that invokes an AgentCore harness through a request-response interaction; that task does not support the Step Functions synchronous-job or callback-token pattern. The task can run for at most fifteen minutes, even if the harness itself continues after the task times out. For a long-running purchase, maintenance approval or multi-day ticket, let a declared state machine own the durable approval and completion state, invoke an agent only for the bounded reasoning step, and use a correlation ID to recover results or prevent duplicate actions after timeout. The opposite composition also works: an agent can request an authorized tool that starts a controlled state-machine execution.
This combination is useful when natural-language reasoning should decide whether a process is needed but the process itself must remain controlled. An IT assistant might interpret a user’s request and determine that a password-reset workflow is appropriate. Once that decision is made, Step Functions can execute the approved sequence with explicit validation, logging, retries, and rollback behavior.
The agent remains responsible for interpretation and interaction. The state machine remains responsible for the controlled procedure.
This separation limits how much operational authority is delegated to the model and makes high-impact actions easier to audit.
Tool security is more important than prompt cleverness
An agent becomes dangerous when its tools are overprivileged. A well-written system prompt is not a security boundary.
Use least-privilege IAM, workload identities, narrowly scoped credentials and resource-level policies. AgentCore identity and safe tool actions require separate checks for who is invoking a gateway, which tools that identity may use and whether the specific customer or resource in the tool parameters is authorized. A valid token is not sufficient if the gateway is configured only to authenticate, or if downstream services skip their own authorization. High-impact actions should record the human approver and tool result in durable business state rather than accepting a model-generated sentence as proof of approval.
Step Functions also relies on IAM roles for the actions executed by states. The difference is that a state machine’s possible actions are declared, whereas an agent may decide among a set of available tools at runtime.
For both services, the safest architecture constrains permissions at the resource layer. If a model prompt is manipulated, the underlying credentials should still prevent the application from performing an unauthorized action.
State and memory have different meanings
Step Functions state is workflow data passed between states during an execution. It supports deterministic process logic: inputs, outputs, branch decisions, retries, and execution history.
Agentic memory is conversational and task-oriented. An agent may need short-term context for the current interaction and longer-term information that helps personalize or continue work across sessions. AgentCore includes memory-oriented capabilities designed for that pattern.
Do not use conversational memory when workflow state is what the business process requires. Likewise, do not try to force an open-ended conversation into a state machine by enumerating every possible user utterance.
The data model should match the interaction model. Workflow state answers “where is this process?” Agent memory answers “what context helps this agent reason about the user and task?”
A useful additional boundary is long-running reliability. Step Functions is designed to retain workflow state across waits, retries, service interruptions, and asynchronous callbacks. An agent runtime may participate in a long-lived interaction, but business processes that must survive hours or days, wait for an external approval, or resume deterministically after a failure are usually easier to reason about in a state machine. The agent can initiate or interpret the process while Step Functions owns the durable execution state. That distinction becomes especially important when an operation has financial, compliance, or customer-impact consequences and operators need to know exactly which step is pending.
Observability should reveal decisions as well as failures
Traditional workflow monitoring focuses on which state ran, how long it took, and whether it succeeded. Agentic observability must also explain tool calls, model interactions, latency, errors, and the context that led to a decision.
AgentCore components expose monitoring information for runtime and tool activity, while AWS services such as CloudWatch remain important for operational metrics and alarms. Teams should track tool invocation counts, latency, throttling, failures, token usage, and security-relevant actions.
Step Functions execution history gives a strong deterministic trace of the state machine. When the two services are combined, retain correlation identifiers so an operator can connect the user’s request, agent decision, workflow execution, and downstream resource changes.
A production GenAI system is not observable if the team can see that an API failed but cannot explain why the agent called it.
Choose the boundary intentionally
Use AgentCore when the application requires model-driven planning, dynamic tool selection, multi-turn interaction, managed agent runtime capabilities, or agent-specific identity and memory. Use Step Functions when the process should follow a declared state graph with explicit branching, retries, waits, parallelism, and failure handling.
Use both when the agent should reason about the task but execution must cross into a controlled workflow. This is often the strongest pattern for enterprise systems because it keeps flexible interpretation at the edge and deterministic operations at the point where business state changes.
The core AIP-C01 distinction is therefore not “AI orchestration versus old orchestration.” It is dynamic, model-directed action selection versus deterministic, application-declared workflow control. Good architectures decide deliberately which decisions belong to the model and which must remain in code and policy.