Amazon Bedrock Agents vs AgentCore + Strands (2026): Managed Agent or Production Runtime?

Quick verdict

Amazon Bedrock Agents is an opinionated managed service. You configure instructions, a model, action groups, knowledge bases, and guardrails, while AWS owns much of the orchestration. It fits bounded agents where delivery speed matters more than loop control.

Amazon Bedrock AgentCore is framework agnostic infrastructure for agents. Services include Runtime, Identity, Memory, Gateway, Browser, Code Interpreter, Observability, Policy, and Evaluations. You can bring Strands, LangGraph, CrewAI, another supported framework, or custom code.

Strands is an open source framework for writing agents, with a loop, model and tool abstractions, and MCP connectivity. It can run without AgentCore, which can also host other frameworks.

The useful mental model is:

Bedrock Agents is an opinionated agent abstraction. AgentCore is runtime and operations infrastructure. Strands is one way to write the agent.

Assess Bedrock Agents for a simple knowledge and action agent. For custom orchestration, user identity, longer sessions, advanced tools, or policy, build with a framework and consider AgentCore.

At a glance

Decision factor	Bedrock Agents	Bedrock AgentCore	Strands Agents
Layer	Managed agent service	Managed runtime and operations services	Open source agent framework
What you define	Instructions, model, action groups, knowledge base, guardrails	Agent package and the services it consumes	Agent loop, tools, prompts, model, application logic
Orchestration	Service managed and opinionated	Bring your own framework and loop	Model driven loop in code
Hosting	Managed by Bedrock	AgentCore Runtime, with other services optional	Your chosen runtime, including AgentCore
Tools	Action groups, commonly backed by Lambda	Gateway, MCP, direct services, browser, code interpreter	Python tools, MCP, and custom integrations
Identity	IAM execution roles and application controls	Workload identity and user token brokerage patterns	Application implemented, or AgentCore Identity
Memory	Session context and integrations such as Knowledge Bases	Short term and long term memory services	Application implemented, or AgentCore Memory
Observability	Bedrock agent traces and AWS monitoring	OpenTelemetry compatible telemetry and integrations	Framework logging and hooks, richer when paired with an observability stack
Governance	Bedrock Guardrails, IAM, service configuration	Policy and Evaluations, plus AWS security controls	Code level controls, plus runtime and cloud controls
Framework choice	AWS managed orchestration	Framework agnostic	Strands
Best fit	Bounded, configurable managed agents	Custom production agents needing managed infrastructure	Developers wanting a compact, code first agent framework
Main lock in	Agent configuration and Bedrock orchestration	AgentCore service APIs and AWS operations	Framework APIs, usually less infrastructure lock in

The table is a layer comparison, not a feature parity claim. Service capabilities and regional availability change. Verify each required feature in the target AWS region before committing to an architecture.

Stop comparing them as equals

AWS agent comparisons often collapse three decisions:

1. How is the agent authored? This is where Strands, LangGraph, CrewAI, and custom code compete.
2. Where does the agent run and obtain infrastructure capabilities? This is where AgentCore Runtime and its associated services fit.
3. Do we want AWS to own the agent orchestration abstraction? This is the Bedrock Agents decision.

Strands can run in Lambda, ECS, EKS, AgentCore, or elsewhere. AgentCore can host different frameworks. Bedrock Agents means accepting more managed orchestration in exchange for less application code.

This separation prevents teams choosing flexibility without budgeting for runtime, identity, memory, policy, tracing, and operations.

Reference architectures

Bedrock Agents architecture

Application
        |
        v
    Bedrock Agent
        +-> foundation model
        +-> action groups -> Lambda -> business APIs
        +-> Knowledge Bases
        +-> Guardrails
        +-> session and trace

The service orchestrates model, knowledge, and actions. IAM roles govern AWS access, while Lambda action groups bridge to business systems. This is compact, but it constrains how far the loop can be customised.

Strands on AgentCore architecture

Web or mobile application
              |
              v
    Application API and authorisation
              |
              v
    AgentCore Runtime -> Strands agent -> Bedrock model
              |                |
              |                +-> Gateway or MCP tools
              |                +-> Browser or Code Interpreter
              |
              +-> Identity
              +-> Memory
              +-> Policy
              +-> Observability
              +-> Evaluations

Here the team owns agent logic, AgentCore provides selected infrastructure, and Bedrock provides models. Services are optional. A deployment can start with Runtime and Observability, then add Identity, Memory, Policy, or specialist tools.

Amazon Bedrock Agents in detail

Bedrock Agents reduces code for an agent that reasons over enterprise information and invokes actions. Developers configure a model, instructions, action groups, optional Knowledge Bases, and Guardrails. The service manages the surrounding orchestration.

Where Bedrock Agents is strongest

It is strong when the use case fits the abstraction, such as a policy assistant that retrieves approved documents and opens a ticket, or a service agent with a small set of bounded actions.

Action groups separate model choice from validated Lambda side effects. Knowledge Bases provide managed retrieval, while Guardrails apply content controls. AWS integrations can simplify procurement, IAM, logging, and network design, and fewer components can benefit a small platform team.

Where Bedrock Agents becomes restrictive

The managed orchestration can be restrictive for custom graphs, deterministic state machines, specialist agents, or long lived processes with complex interrupts. Traces do not provide the control of owning every transition.

Delegated identity is another boundary. An execution role is not the user's OAuth token. Acting as a signed in user requires deliberate consent, scope, storage, refresh, and revocation design.

Use Bedrock Agents when its abstraction matches the workload. Do not force a differentiated agent product into the service merely to reduce initial code.

Amazon Bedrock AgentCore in detail

AgentCore is a collection of managed capabilities, not a single agent builder. Teams can adopt them independently, although integration between services is part of the value.

Runtime

Runtime hosts supported frameworks or custom code in isolated sessions. Research cites sessions of up to eight hours, but verify the current limit and semantics. Runtime does not make application logic durable by itself. Engineers still own retries, side effects, idempotency, state persistence, cancellation, and timeouts.

Identity

Identity addresses workload credentials and access to external services, including acting on behalf of users. The application still needs an end to end authorisation model covering user identity, allowed actions, consent, scopes, and revocation.

Memory

AgentCore Memory separates transient context from longer lived memory strategies. Teams must define retention, tenant boundaries, deletion, and trust. Authoritative customer state still belongs in a system of record.

Gateway

Gateway can expose APIs, Lambda functions, and services as agent tools, including MCP patterns. Validate parameters server side, constrain actions, and make consequential operations idempotent. A well described dangerous tool is still dangerous.

Browser and Code Interpreter

Browser and Code Interpreter support web interaction and code based analysis. They expand the attack surface and cost envelope. Treat web content as untrusted, restrict network and data access, apply resource limits, and keep broad credentials away from generated code.

Observability

AgentCore Observability uses OpenTelemetry compatible signals and AWS monitoring. Correlate the user request with model calls, tools, and side effects. Because telemetry can contain sensitive prompts, documents, and tool inputs, design redaction, access, retention, and data location deliberately.

Policy

AgentCore Policy can enforce controls around tool use, including Cedar and natural language assisted authoring. Enforcement outside the prompt is valuable, but generated policy still requires review, deny and allow tests, versioning, and audit.

Evaluations

AgentCore Evaluations can support repeatable quality assessment, while the organisation still owns datasets, rubrics, thresholds, reviewer calibration, and releases. Payments appears in secondary research as an emerging capability, but should not be presented as available without primary AWS confirmation.

Strands Agents in detail

Strands is an open source SDK for building agents in code. Its model driven approach lets a foundation model choose among declared tools while the framework manages the core loop. Developers can add custom tools, use MCP servers, select models, and shape behaviour through instructions and application code.

Why teams choose Strands

Strands can be concise when an explicitly authored state graph is unnecessary. It aligns with AWS and Bedrock while retaining other deployment options. Agent logic, tools, prompts, validation, and tests remain in normal source control.

What Strands does not provide alone

An SDK is not a production platform. Without AgentCore, the team owns deployment, scaling, isolation, identity, memory, queues, telemetry, policy, evaluation, and incidents. Some organisations already have these capabilities. Others may find AgentCore cheaper. Code length is not a reliability metric, so compare state semantics, failure handling, testing, and ownership.

Pricing and total cost of ownership

There is no single price comparison because the products meter different layers.

Bedrock Agents cost shape

Model inference, Knowledge Bases, Guardrails, Lambda, storage, and logging contribute to cost. Check the chosen model and region directly. A managed abstraction may reduce engineering cost even if a service line item is higher.

AgentCore cost shape

AgentCore services have different usage dimensions and dependent AWS costs. Runtime, Browser, Code Interpreter, Memory, Gateway, Identity, Policy, Observability, and Evaluations must be modelled separately. Confirm idle and active metering, free tiers, and model token costs.

Strands cost shape

Strands has no framework licence cost, but engineers, hosting, models, storage, tools, security, observability, and support remain. Existing ECS or EKS capacity increases operational ownership. AgentCore transfers some work to AWS for usage fees.

A production TCO model

Compare annual cost across:

1. Build and migration engineering.
2. Framework and platform operations.
3. Model, retrieval, memory, browser, code, and external API usage.
4. Network transfer, logs, traces, storage, and backups.
5. Security review, IAM, policy, privacy, and compliance.
6. Evaluation datasets, human review, and release gates.
7. Incident response and expected manual recovery.
8. Lock in and future migration effort.

Use representative workload traces: short successful runs, long runs, failed tools, human pauses, and high concurrency. Calculator examples and third party estimates are directional until matched to your traffic and region.

Security, identity, and ownership

AWS provides a strong set of infrastructure controls, but the shared responsibility model still applies. IAM should separate deployment, runtime, tool, and human permissions. Use least privilege roles, private connectivity where required, encrypted stores, secret rotation, and explicit egress controls.

The most important agent security boundary is the tool call. Models and retrieved content can be manipulated through prompt injection. Guardrails can help with content risk, but they do not replace authorisation. Validate every consequential tool invocation outside the model, enforce policy, and require human approval where impact is material.

Bedrock Agents gives AWS more ownership of orchestration. AgentCore plus Strands gives the application team more ownership of code and execution semantics. More control also means more responsibility for insecure tool definitions, state leakage, tenant separation, and unsafe retries.

For Australian and Singaporean organisations, map data movement across inference, Knowledge Bases, memory, traces, backups, support channels, and external tools. Confirm whether every required service is available in Sydney or Singapore and what data may leave the selected region. Regional hosting alone does not establish compliance with the Australian Privacy Act, Singapore PDPA, sector rules, or contractual obligations. Obtain qualified legal and security advice.

Migration paths

Bedrock Agents to Strands on AgentCore

1. Document current behaviour. Export instructions, action schemas, knowledge configuration, guardrails, aliases, and representative traces.
2. Define acceptance tests. Capture successful actions, refusal cases, retrieval quality, authorisation boundaries, latency, and cost.
3. Preserve stable AWS assets. Reuse Bedrock models, Knowledge Bases, Guardrails, Lambda functions, and APIs where their contracts remain suitable.
4. Implement tools in Strands. Wrap existing actions behind validated tool interfaces. Do not expose Lambda functions directly without reviewing parameters and identity.
5. Select AgentCore services deliberately. Begin with Runtime and Observability if appropriate. Add Identity, Memory, Gateway, Policy, Browser, Code Interpreter, or Evaluations only where required.
6. Run in shadow mode. Send copied requests to the new agent without allowing consequential side effects. Compare quality, latency, cost, and policy outcomes.
7. Move traffic gradually. Use application level routing and a rollback path. Keep idempotency keys across old and new implementations.
8. Retire the old agent after evidence. Preserve trace and configuration records according to retention requirements.

Secondary sources mention an import-agent capability in AgentCore tooling. Its current command name, support level, generated framework code, and limitations must be verified in AWS documentation before it appears as a recommended migration shortcut.

Custom framework to AgentCore

An existing LangGraph, CrewAI, Strands, or custom agent can adopt AgentCore incrementally. Containerise or package the runtime according to current requirements, connect observability, and validate session behaviour. Then assess managed identity, memory, gateway, policy, and evaluation against existing services.

Avoid replacing working infrastructure merely to standardise on one vendor. The migration should improve measured security, reliability, operating effort, or cost.

Hybrid architectures

Hybrid does not mean every request passes through every service. It means matching the abstraction to the workload.

A bank, insurer, or SaaS platform might keep an internal HR assistant on Bedrock Agents, while customer facing case analysis uses Strands on AgentCore for tenant identity, custom state, evidence checks, and telemetry. Both can share models, Guardrails, Knowledge Bases, tools, and governance.

A custom orchestrator may also invoke Bedrock Agents as a specialist if nested calls do not obscure cost, latency, and traces. Long workflows may still require a durable workflow or event system. AgentCore Runtime does not replace every workflow engine.

Which should you choose?

Choose Bedrock Agents if

You need a bounded agent with a small set of actions and managed retrieval. Choose it when service managed orchestration is acceptable, console and configuration based delivery helps the team, and the use case does not require a highly custom state machine or delegated user identity.

Choose AgentCore if

You already have or intend to build custom agent code and want managed production infrastructure. It is especially relevant for longer sessions, external identity, governed tool access, browser or code execution, OpenTelemetry based operations, policy enforcement, and systematic evaluations. Confirm regional availability for every selected service.

Choose Strands if

You want a compact code first framework, model directed tool use, MCP connectivity, and strong alignment with AWS. Use it with your existing runtime when your platform already supplies production controls, or pair it with AgentCore to reduce infrastructure work.

Choose another framework on AgentCore if

Your application naturally requires explicit graph state, role based orchestration, or an existing framework investment. AgentCore's value is framework agnosticism. Strands is a preferred AWS native option, not a mandatory one.

Choose a hybrid estate if

Your organisation has both simple managed agents and differentiated agent products. Standardise security, tools, telemetry, and evaluation where practical, but do not force every workload into one orchestration abstraction.

Related: agent framework comparison · AgentCore sandbox comparison · private AI on AWS Bedrock · AgentForge Saigon 2026

FAQ

Is AgentCore a replacement for Bedrock Agents?

Not directly. AgentCore provides infrastructure for custom agents, while Bedrock Agents provides managed orchestration. AgentCore creates a migration destination for workloads that outgrow the managed abstraction, but Bedrock Agents remains suitable for bounded use cases.

Is Strands part of AgentCore?

They are complementary but distinct. Strands is an open source framework. AgentCore can host Strands and other frameworks. Strands can run outside AgentCore.

Are Bedrock Agents built on AgentCore?

Do not assume this from architecture diagrams or secondary articles. Even if AWS shares underlying technology, customers interact with different service abstractions and contracts. Verify any formal product relationship in current AWS documentation before publishing such a claim.

Can AgentCore run LangGraph or CrewAI?

AWS describes AgentCore as framework agnostic and documents support for multiple frameworks. Confirm current packaging, protocol, and feature requirements for the exact framework version.

Does AgentCore provide durable workflows?

It provides runtime and session capabilities, but durable business workflows also require correct state persistence, retries, idempotency, and side effect management. Validate those semantics for your design rather than equating a long session with a durable workflow engine.

Do Guardrails and Policy solve prompt injection?

No. They add important controls, but no single product eliminates prompt injection. Combine content controls with tool authorisation, parameter validation, least privilege identity, isolation, monitoring, and approval for high impact actions.

Can we keep our Bedrock Knowledge Base during migration?

Usually that is a sensible target architecture because a custom agent can call AWS retrieval services. Confirm API compatibility, permissions, metadata filters, latency, and retrieval quality for the new path.

Which is cheaper?

It depends on workload and staffing. Bedrock Agents can reduce engineering. Strands can reduce framework overhead but still needs a runtime. AgentCore can reduce platform work while adding metered services. Model and tool costs apply across approaches. Use measured traces and current regional prices.

Conclusion

Bedrock Agents, AgentCore, and Strands should not be placed in a simple winner table. They answer different architecture questions.

Bedrock Agents is the shortest managed path when the service's orchestration model fits. Strands is a way to write a custom agent with normal software engineering control. AgentCore is a set of managed production capabilities that can host Strands or another framework.

Start with the least complex layer that meets the requirement. Move from Bedrock Agents when custom orchestration, end user identity, state, tools, policy, or evaluation creates a documented constraint. Preserve Bedrock models, Knowledge Bases, Guardrails, and validated tool services where useful. For larger AWS estates, a deliberate hybrid is often more robust than a forced standard.