Blog
Bedrock Agents Classic, AgentCore, and Mantle: What’s the difference?
Senior AWS Consultant
News: Bedrock Agents, renamed Bedrock Agents Classic, has been unavailable to new customers/accounts since July 30, 2026. Existing accounts can continue using the service in maintenance mode. AWS recommends Amazon Bedrock AgentCore as the successor. Please refer to: Amazon Bedrock Agents Classic maintenance mode – Amazon Bedrock
If you currently use or are planning to use AWS Bedrock Agents as your AI platform, you should be aware of this issue.
A possible approach is to upgrade to AgentCore as the runtime and then use LangGraph or Strands as the framework. AgentCore is framework-agnostic, which is a significant advantage.
Bedrock Agents Classic was a managed, configuration-based agent orchestrator (fixed loop, Action Groups, Knowledge Bases). AgentCore represents a different paradigm: It is a bring-your-own-agent (BYOA) infrastructure platform. You can build your agent using a framework of your choice (LangGraph, CrewAI, Strands, Google ADK, raw code). AgentCore provides the underlying infrastructure, including session isolation, memory, tool and gateway connectivity, identity and authentication observability, a code interpreter, and a browser tool. It is described as a “runtime substrate,“ not an agent orchestrator itself.
AgentCore is Amazon’s new agent infrastructure layer. For the actual LLM calls, AgentCore is explicitly model-agnostic: It works with Amazon Bedrock models (via bedrock-mantle or bedrock-runtime), OpenAI, Google Gemini or any LiteLLM-compatible provider. Agents can even switch between model providers during a session. As an agent-hosting layer, AgentCore has three distinct service endpoints and sits above model inference. It can also route requests to several providers:
AgentCore surface | Endpoint pattern |
Control plane (create/manage runtimes, endpoints, gateways) | bedrock-agentcore-control.{region}.amazonaws.com |
Data plane (invoke a deployed agent runtime) | bedrock-agentcore.{region}.amazonaws.com |
Gateway (tool/MCP connectivity) | {gatewayId}.gateway.bedrock-agentcore.{region}.amazonaws.com |
Bedrock Mantle is a separate, lower-level inference engine within Amazon Bedrock that AgentCore can call when using a Bedrock model. AgentCore itself neither owns or replaces it. Mantle provides a newer OpenAI- and Anthropic-compatible endpoint surface with Zero Operator Access (ZOA) and Zero Data Retention (ZDR) enabled by default.
If your agent uses a Bedrock-hosted model as its LLM, that specific model call goes through bedrock-runtime (or bedrock-mantle for a Mantle-exclusive model). However, this is an outbound dependence of AgentCore, not AgentCore’s own API surface.
In a nutshell, here’s what we learned: Migrating from Bedrock Agents Classic to AgentCore is a viable option, but bear in mind that AgentCore is an agent-hosting/orchestration platform with its own dedicated endpoints, not an inference engine. It does not use bedrock-runtime or bedrock-mantle as its interface. Instead, it sits a layer above both and can access either one, as well as non-Bedrock LLM providers.
There are two common ways to use AgentCore:
Capability |
AgentCore harness |
AgentCore Runtime (BYOA) |
|
What it is |
Managed orchestration loop (configuration-based, powered by Strands Agents) |
Serverless hosting for agent code you write in any framework |
|
Model selection |
✅ Configuration field, no code |
🔵 Custom code required |
|
Switch model |
✅ Built-in |
🔵 Custom code required |
|
Agent framework choice |
❌ Fixed (Strands-based) |
🔵 Any framework (LangGraph, CrewAI, Strands, raw code) |
Further reading: AgentCore harness vs. Runtime – Amazon Bedrock AgentCore
Option |
What it is |
Model control plane |
Residency behavior |
Best for |
|---|---|---|---|---|
|
AWS-native + OpenAI/Anthropic-compatible endpoint on Bedrock’s Mantle engine |
Bedrock-managed FMs + cross-Region profiles |
In-Region by default; geoographic/global profiles optional. Provides Guardrails, prompt caching, intelligent routing, and more granular IAM |
General-purpose production inference, Guardrails, prompt routing.Only bedrock-runtime supports geographic//EU/global cross-Region at all — cross-Region inference profiles (geographic or global). Mantle does not support cross-Region routing; it’s always tied to the Region of the endpoint being called. |
|
OpenAI/Anthropic-compatible endpoint on Bedrock’s Mantle engine |
Bedrock-managed FMs, broader model catalog and earlier access to new models |
Always in-Region per deployed endpoint (no cross-Region routing). |
Agentic tool use, asynchronous jobs, Mantle-exclusive models (e.g., Gemma 4)Use it instead of bedrock-runtime only if you need a Mantle-exclusive capability (web search tool, asynchronous/background jobs, Projects, or a Mantle-only model like Gemma 4)Use it for EU Sovereign Cloud use cases, where residency in ESC is enforced structurally (separate partition, single Region, zero operator access) rather than through a geograhic or global profile choice, since ESC does not support cross-Region inference. |
Bedrock Marketplace |
Catalog of 100+ third-party/open models (Hugging Face, specialized vendors) deployed via Bedrock |
Bedrock-managed, some via managed endpoints that you provision |
Region-dependent per model listing |
Access to niche/open models without leaving the Bedrock API surface |
Bedrock Custom Model Import |
Bring your own fine-tuned open-weight model (e.g., a SageMaker-trained Llama/Mistral/Nova) into Bedrock for serverless inference |
You own the weights; Bedrock serves them |
Same Region controls as native Bedrock models |
Custom/fine-tuned models without managing the serving infrastructure |
SageMaker AI real-time endpoints |
Dedicated, self-managed inference endpoints (your choice of instance type, container) |
Full control — any model, any container |
You pick the exact Region/Availability Zone; no AWS-managed cross-Region routing |
Latency/cost/throughput tuning, models not available on Bedrock |
SageMaker HyperPod |
Resilient, large-scale training/inference infrastructure on EKS or Slurm |
Full infrastructure control, orchestration layer exposed |
Entirely within whatever Region/VPC you deploy |
Large-scale custom training and inference at scale, maximum control |
Self-hosted (EC2/EKS + vLLM/TGI/Triton) |
You deploy and operate the serving stack yourself |
Full control |
Entirely your choice — single Availability Zone, single Region, or multi-Region |
Workloads requiring full infrastructure ownership, air-gapped or heavily audited environments |
AgentCore
|
Agent orchestration/hosting layer, calls into any of the above as its model backend |
N/A — it’s a consumer of inference, not a provider |
Inherits residency from whichever inference layer + Region you point it at |
Production agents needing session isolation, memory, tool gateway, identity, observability |
Planning or working on an architecture for an EU-sovereign use case? Stay tuned for our next post.