Agentic AI and Multi-Agent Orchestration on AWS
Agents on Bedrock AgentCore, orchestrated by Step Functions
AWS has taken a modular position: Amazon Bedrock AgentCore is a set of services you can adopt individually rather than one framework you buy into, and it is deliberately framework-agnostic and model-agnostic. That suits organisations that want to own their orchestration code. The design decision that matters most here is keeping AWS Step Functions as the deterministic owner of the workflow and treating the reasoning call as a step inside a state machine, rather than letting a model own control flow it will eventually get wrong.
Why AWS
When this is the right platform.
- AgentCore is modular. You can adopt the runtime, the gateway, memory or identity independently rather than committing to a whole framework, which suits teams with existing agent code.
- It is framework-agnostic and model-agnostic by design, so an agent written in Strands Agents, LangGraph or your own code can run on the same managed runtime.
- Step Functions is a genuinely mature deterministic orchestrator. Branching, retries, timeouts, parallelism and human approval are platform features rather than things you implement.
- Bedrock Guardrails can be called independently of any model through an API, so the same policy applies to content your own code generated.
- Session isolation is strong. The runtime gives each session its own isolated environment, which matters when agents execute generated code or drive a browser.
Where it is less suited
We would rather say this now than after a migration.
- Bedrock Agents Classic is closed to new customers and is not a base for new work. An existing estate there is migration work, and supervisor and collaborator multi-agent collaboration lives on that older product. Confirm its current support position against AWS documentation before committing to a migration date.
- Availability status in this area is genuinely unclear in places. AWS sources contradicted each other on the managed agent loop while we were researching, so we do not state a status for it and we design so preview capabilities are replaceable rather than load-bearing.
- Modularity is a real advantage and a real cost. Adopting the runtime, gateway, memory, identity, policy and observability means more services to understand and operate than a single opinionated framework would.
- The gateway makes exposing tools easy, which makes over-exposing them easy too. Thirty tools reachable by one agent is a design problem regardless of how little effort it took to connect them.
- There is no organisation-wide way to remediate a badly configured agent the way Azure Policy can remediate a resource. Governance here is convention, code and review rather than an inherited platform control.
- Naming and packaging across the agent services has moved repeatedly, so blog posts, prescriptive guidance and existing code do not all agree. We verify against your deployed version rather than an article.
Business outcomes
What AWS delivers here.
- A state machine that owns the workflow
- Step Functions holds branching, retries, timeouts and approval, with reasoning as a step inside it. Control flow stops being something a model improvises per run.Agreed measure: Completion rate and unattended failure rate for the named workflow, baselined before build.
- Existing APIs usable as tools without rewriting them
- Current APIs, functions and services exposed through one governed endpoint with runtime discovery, so agents gain capability without credentials being distributed into agent code.Agreed measure: Number of tools reachable per agent and how many bypass the governed endpoint.
- Policy enforced before a tool runs
- Guardrails on agent actions authored as policy and applied by intercepting tool calls before execution, rather than expressed as instructions in a prompt.Agreed measure: Proportion of write actions covered by an enforced policy or an approval step.
- Portable orchestration
- Agent code written against an open SDK and run on a managed runtime, so the orchestration you invest in is not welded to one vendor's agent abstraction.Agreed measure: Share of orchestration logic held in your repositories rather than platform configuration.
- Traces in the monitoring you already use
- Step-by-step agent telemetry emitted in an OpenTelemetry-compatible form, landing in your existing stack rather than a separate console nobody watches.Agreed measure: Share of production runs with a complete retrievable trace in your primary tooling.
- Safe execution of generated work
- Agent-generated code and browser automation run in isolated sandboxes rather than in your application runtime, which is what makes those capabilities usable at all.Agreed measure: Whether any agent-generated code executes outside an isolated session, verified at handover.
Common client problems
What we usually hear first.
We are on Bedrock Agents already. What happens to us?
The original Bedrock Agents is now positioned as Bedrock Agents Classic and is closed to new customers, so treat it as an existing estate with a migration ahead of it rather than a foundation to build on. Nothing breaks immediately. What we would not do is start new work there or extend it significantly. We scope the move onto the current runtime as a planned piece of work, usually alongside a release you were making anyway.
Do we need Strands Agents, or can we use LangGraph or our own code?
Any of them. The runtime is deliberately framework-agnostic, so this is a team decision rather than a platform constraint. Strands is AWS-originated and has multi-agent coordination primitives built in, which shortens the path if you are starting fresh. If your team already has working LangGraph or bespoke orchestration, running it on the managed runtime is usually better than rewriting it to match a vendor's preferred SDK.
Should the agent decide the workflow, or should Step Functions?
Step Functions, in almost every case we have seen. This is the single most consequential design decision on the page. A state machine gives you deterministic branching, retries, timeouts, parallelism and human approval as platform behaviour, and a reasoning call becomes one step inside it. Letting a model own control flow means every run is a slightly different program, which is exactly why prototypes work and production does not.
How do we expose 30 internal APIs to agents without a huge integration project?
That is what the gateway capability is for: existing APIs, functions and services are turned into agent-consumable tools behind one governed endpoint with runtime discovery, rather than each being wrapped by hand. The honest caveat is that it does not remove the need to think about each tool's permissions and blast radius. Exposing 30 tools to one agent is a design smell regardless of how easy the plumbing became.
Some of what we want is in preview and we cannot depend on that.
Correct, and this area needs more care than usual. During our own research, AWS sources contradicted each other on the availability status of the managed agent loop, so we do not state a status for it on this page. We design so that anything preview is a replaceable component rather than load-bearing, and we tell you which parts of a proposal sit in that category before you commit.
Can agents on AWS use our Microsoft identity provider?
Yes. The identity capability works with existing providers including Microsoft Entra ID, so agents can act for themselves or on behalf of a user with pre-authorised consent without you standing up a second directory. This is genuinely useful for organisations whose workforce identity is Microsoft but whose workloads are on AWS. The complexity is in the consent and delegation design rather than the federation itself.
How we deliver
Our AWS delivery approach.
- 01
Assessment and advisory
The AWS assessment concentrates on where determinism belongs, which AgentCore modules you actually need, and what is preview, because adopting all of it is neither necessary nor free.
- Determinism boundary drawn first. Which steps belong in a state machine and which genuinely need a reasoning call, decided before any agent framework is selected.
- Module scope chosen deliberately. Which AgentCore capabilities you need given what you already run, since it is modular and adopting everything adds operational surface for no gain.
- Framework decision on team skill. Strands, LangGraph or existing bespoke orchestration judged on what your team can maintain, since the runtime does not force a choice.
- Classic migration assessed. Any existing Bedrock Agents Classic estate scoped for migration, since it closed to new customers and is not a base for new work.
- Preview dependency mapped. Every capability in the design whose availability status is preview or unclear, recorded with the date and source checked.
- Identity federation design. How agents authenticate against your existing provider and what on-behalf-of consent looks like for the actions in scope.
- 02
Architecture and implementation
Step Functions owns the workflow, the managed runtime hosts the agents, the gateway is the only route to a tool, and policy is enforced at the interception point rather than requested in a prompt.
- Step Functions as the orchestrator. Branching, retries, timeouts, parallelism and human approval held in a state machine, with reasoning calls as steps inside it.
- Agents on the managed runtime. Session isolation, fast starts and long-running asynchronous support, hosting whichever framework your team maintains.
- One gateway for every tool. Existing APIs, functions and services turned into agent-consumable tools behind a single governed endpoint with runtime discovery.
- Memory scoped by decision. Short-term conversation memory separated from anything persisted across sessions, with sharing between agents an explicit choice.
- Sandboxes for generated work. Agent-generated code and browser automation confined to isolated managed environments rather than your application runtime.
- Idempotent tool implementations. Every write-capable tool safe to call twice, because a state machine that retries will eventually retry a step that already succeeded.
- 03
Security and governance
The AWS model gives you a clean interception point for policy and strong session isolation. Both are worth designing around deliberately rather than accepting defaults.
- Policy enforced at the gateway. Tool calls intercepted and checked against declarative policy before execution, so a guardrail is not merely a prompt instruction.
- Agent identity federated, not duplicated. Agents authenticate through your existing provider, acting for themselves or on behalf of a user with pre-authorised consent.
- Guardrails applied to your own output too. Content policy invoked independently of a model call, so text your own code produced is checked by the same rules.
- Least-privilege roles per tool. Each tool implementation given its own narrowly scoped role rather than a shared execution role that grows over time.
- Session isolation verified. Generated code and browser automation confined per session, checked at handover rather than assumed from the service description.
- Trajectories retained for audit. Full step-by-step traces kept for the period your records policy requires, since a final answer cannot be audited alone.
- 04
Adoption and enablement
Because AgentCore is modular, adoption here is as much about your team owning the right pieces as about end users trusting the output.
- Team owns the orchestration code. Handover on the state machine, the agent code and the tool definitions, since these are yours to change rather than platform configuration.
- Approval steps inside the state machine. Human approval modelled as a first-class workflow state, so a pending decision is visible and resumable rather than a stalled loop.
- Autonomy widened by gate. Propose-only, then approve-then-act, with a recorded decision before any step runs unattended.
- Traces wired into existing tooling. Telemetry landing in the monitoring your team already watches rather than a separate console that goes unopened after week two.
- Runbooks for agent failure. What to do when a run stalls, loops or fails mid-workflow, including how to resume a state machine safely.
- Agent register maintained. Which agents and tools exist, who owns each and what it can reach, kept current as the estate grows.
- 05
Managed continuation
The modular model means more moving parts to watch. Continuation focuses on evaluation regressions, cost per run and the parts of the platform that are still settling.
- Evaluations on every change. Model, prompt and tool changes re-scored against the held-back set, with regressions blocking promotion rather than being logged.
- Cost per run trended. Token and tool spend per completed run tracked over time, since a model change or new retry pattern can double cost with no code change.
- Preview and rename tracking. Capabilities whose status was unclear at design time watched for change, because sources in this area have contradicted each other.
- Classic migration progress. Any remaining Bedrock Agents Classic workload tracked to completion rather than left indefinitely on a closed product.
- Tool and schema drift. Downstream API changes detected before they become silent failures inside an agent loop or a retry storm.
- Monthly report with one recommendation. Task success, incidents, spend per workflow and the single improvement we would make next.
Reference architecture
An agentic workflow on AWS, layer by layer.
How the pieces fit together on AWS. Every engagement adapts this, and we will tell you which layers you already have.
- 01
Deterministic control
Branching, retries, timeouts and approval owned by a state machine.
- AWS Step Functions
- Human approval state
- AWS Lambda workers
- 02
Agent runtime
Session-isolated hosting for whichever framework your team maintains.
- AgentCore Runtime
- Strands Agents or LangGraph
- AgentCore Memory
- 03
Tools and policy
One governed endpoint, with policy checked before a tool executes.
- AgentCore Gateway
- AgentCore Policy
- Amazon API Gateway
- 04
Identity
Federated agent identity, acting for itself or on behalf of a user.
- AgentCore Identity
- Microsoft Entra ID federation
- Scoped IAM roles
- 05
Evaluation
OpenTelemetry traces and scored runs feeding your existing stack.
- AgentCore Observability
- Amazon CloudWatch
- Held-back evaluation set
Across every layer
- Retrieved content and tool output treated as untrusted
- Idempotent writes so a retry cannot double-apply
- Cost per run instrumented from the first build
- A named owner recorded per agent
Technology reference
The AWS services we build with.
A reference architecture view of the platform services used in this domain, and what each one does in the design.
Agent platform and orchestration
Amazon Bedrock AgentCoreThe modular agent platform. Its Runtime hosts agents with session isolation, Memory holds short and long-term state, Gateway exposes tools, Identity handles authentication, Policy enforces action guardrails and Observability emits traces.
Amazon BedrockModel access plus Guardrails, which can be applied independently of a model call so the same policy covers your own generated content.
AWS Step FunctionsThe deterministic orchestrator owning branching, retries, timeouts, parallelism and human approval, with reasoning as a step inside the state machine.
AWS LambdaTool implementations behind the gateway and the deterministic task workers inside state machines.
Identity and access
AWS Identity and Access ManagementNarrowly scoped execution roles per tool rather than one shared role that accumulates permissions.
AWS Secrets ManagerCredentials for downstream systems held outside agent configuration and rotated independently.
AWS KMSCustomer-managed keys encrypting agent state, memory and retained trajectories.
Tools and integration
Amazon API GatewayFronts existing REST APIs before they are exposed as agent tools, applying authentication and throttling.
Amazon EventBridgeEvent-driven triggers that start a workflow, and decoupling between the state machine and downstream systems.
Amazon S3Document and artefact storage for inputs an agent reads and outputs it produces.
Grounding, state and evaluation
Amazon OpenSearch ServiceRetrieval with document-level access control where grounding must respect existing entitlements.
Amazon DynamoDBWorkflow and conversation state where you want it in your own table rather than platform-managed storage.
Amazon CloudWatchThe monitoring backend agent traces, metrics and evaluation results land in.
Amazon SageMaker AICustom model training and evaluation where a predictive step sits alongside the reasoning steps.
Product names and icons are trademarks of Microsoft and Amazon Web Services, reproduced unmodified from their official architecture icon libraries to identify the technologies used in these architectures. Their presence does not indicate partnership, certification or endorsement by either vendor.
AWS questions
What people ask about doing this on AWS.
Cost, lock-in and the parts that go wrong, answered before you have to ask twice.
What is Amazon Bedrock AgentCore, in practical terms?
A set of separate services for running agents in production, which you can adopt individually rather than as a package. The runtime hosts agents with session isolation, memory handles conversation state, the gateway turns existing APIs into agent tools, identity handles authentication, policy enforces what a tool call may do, and observability emits traces. It is framework-agnostic, so your own agent code can run on it.
Why use Step Functions if AgentCore can run the agent loop?
Because a state machine gives you deterministic branching, retries, timeouts, parallelism and human approval as platform behaviour, and an agent loop gives you a model deciding those things differently on each run. Reasoning belongs inside a step, not around the whole workflow. This is the design decision that most often separates an agentic prototype that impresses from a production workflow that finishes reliably.
Are we locked into AWS if we build agents this way?
Less than you might expect, and it is worth being precise about where the lock-in actually sits. Agent code written against an open SDK and traces emitted in an OpenTelemetry-compatible form are portable. What is not portable is the gateway configuration, the policy definitions and the Step Functions state machines, which are real re-implementation work. Keeping orchestration logic in your repositories is what keeps that cost bounded.
What does it cost to run agents on AWS?
The variable part is model inference per run, which has a long tail because a retrying loop multiplies its own cost. On top of that sit runtime execution time, gateway and memory usage, state machine transitions and log retention. None of those individually surprises people; the combination at production volume sometimes does. We instrument cost per completed run from the first build and model the pathological iteration case, not just the average.
Can one agent supervise others on AWS today?
Supervisor and collaborator multi-agent collaboration is a feature of the older Bedrock Agents Classic product, which is closed to new customers, so it is not where we would start new work. On the current platform, multi-agent coordination comes from the agent SDK's own primitives running on the managed runtime, with the state machine still owning the overall workflow. In practice we would question whether you need supervision rather than sequencing.
Related industries
Where this work has the most leverage.
Logistics and Warehousing
Shipment and document automation, proof-of-delivery processing and exception dashboards that let a small team run a large network.
Professional Services
Governed enterprise search, document intelligence and secure copilots that respect matter confidentiality and conflict boundaries.
Manufacturing and Distribution
Demand and inventory intelligence, production analytics and supplier automation built on data your planners already trust.
Free discovery workshop
Start with a agentic ai discovery workshop.
Bring one challenge. We will assess whether AWS is the right platform for it before recommending anything.