ComparisonAWS Bedrock & AgentCore

Bedrock Agents Classic, AgentCore harness or Runtime: choosing how to run agents on AWS

Amazon Bedrock Agents is now Bedrock Agents Classic: existing accounts keep it, new accounts cannot create agents, and AWS points new work to AgentCore. That leaves a real choice between the AgentCore managed harness, which runs the agent loop from configuration, and AgentCore Runtime, which hosts your own framework code. This comparison sets out what each path gives you and when to pick it.

Reviewed 10 October 2026 7 min read

On this page

How AWS came to offer three agent hosting paths
Classic, harness and Runtime compared feature by feature
Policy and Evaluations: what they add and their status
Choosing a path by scenario
Bedrock models and Knowledge Bases inside an AgentCore agent
Migration checklist for a Bedrock Agents Classic workload
Questions and answers
Sources

How AWS came to offer three agent hosting paths

Amazon Bedrock Agents launched in November 2023 as a managed way to build agents from action groups, knowledge bases and prompt templates, with AWS running the orchestration¹. From July 30, 2026 it became Bedrock Agents Classic in maintenance mode: accounts without Bedrock Agents activity in the previous twelve months receive an access-denied error when they try to create an agent, no new features are planned and its model catalog is frozen¹.

AgentCore, meanwhile, grew into a set of separately adoptable services for agents built in any framework with any model: Runtime, Memory, Gateway, Identity, Observability, Policy, Evaluations, the Browser and Code Interpreter tools, and a managed harness². AWS recommends the harness for most migrations and configuration-style agents, and code-defined agents on Runtime when you need to own the loop¹.

So the practical question is rarely 'Bedrock Agents or AgentCore?' in the abstract. It is whether an existing Classic agent should stay where it is for now and, for new work, whether the harness or your own code on Runtime should run the loop.

Classic, harness and Runtime compared feature by feature

Criterion	Bedrock Agents Classic	AgentCore harness	AgentCore Runtime with your code
Who runs the agent loop	AWS, from agent configuration and prompt templates	AWS, from a declared model, instructions, tools and limits, powered by Strands Agents	You: your framework code is the loop
Framework choice	None beyond the managed orchestration	None; configuration only, with export to Strands code when you outgrow it	Any framework or none, for example LangGraph, CrewAI or Strands
Tools	Action groups defined by OpenAPI or function schemas, optionally executed by Lambda	Gateway tools, remote MCP servers, built-in browser and code interpreter, inline functions	Anything your code calls, with Gateway and Identity used through the AgentCore SDK
Knowledge bases	Associated directly on the agent	Through a gateway-fronted integration	Through a retrieval tool or a gateway in your code
Memory	Session settings and cross-session memory on the agent	Short- and long-term memory by configuration, scoped per actor	AgentCore Memory called from code, or your own store
Multi-agent patterns	Supervisor collaboration and routing built in	Agent-as-tool for simpler cases	Full control, including routing and graph workflows
Stage-specific prompt overrides	Pre-processing, orchestration, knowledge base response and post-processing	System prompt only; stage overrides are not replicated	Whatever your framework exposes
New features and models	None planned; model catalog frozen	Ongoing	Ongoing

Based on AWS's maintenance-mode comparison and its harness-versus-Runtime feature grid¹³. Check both pages again before committing to a migration plan.

Policy and Evaluations: what they add and their status

Two AgentCore capabilities change the governance picture on both AgentCore paths. Policy associates a policy engine with a gateway and evaluates every tool call against deterministic rules written in Cedar, or drafted in natural language and validated before enforcement. Rules can depend on the caller's identity, the tool and its input parameters, and on what has already happened in the session⁴. Evaluations scores agent sessions and traces, either online against sampled production traffic or on demand from a CI/CD pipeline⁵.

AWS introduced both in preview at re:Invent 2025 and announced general availability of Evaluations in March 2026⁵; its launch post now marks Policy as generally available too⁶. Because Policy is enforced at the gateway, it applies to tools whether the loop is the harness or your own code. Classic agents rely on guardrails and agent configuration instead.

Choosing a path by scenario

If
You need a new internal assistant with a model, instructions and a handful of tools, and you have no framework code yet.
Then
Start on the AgentCore harness.
It gives the managed experience Classic offered, with memory, identity and tracing included, and changes are configuration rather than redeployments.
If
You already have a LangGraph, CrewAI or custom agent that works in a notebook.
Then
Host that code on AgentCore Runtime and connect Gateway, Identity and Memory through the SDK.
Rewriting a working graph as harness configuration throws away control you built, while Runtime keeps your framework.
If
A Classic agent is in production, meets its requirements and needs no newer models.
Then
Leave it running, plan its migration and build new agents on AgentCore.
AWS has set no deadline, but a frozen catalog and no new features make Classic a dead end for change.
If
A Classic agent uses supervisor routing or stage-specific prompt overrides.
Then
Plan a code-defined migration to Runtime rather than to the harness.
AWS lists routing-mode collaboration and stage overrides as not directly replicated in the harness.
If
The workload is regulated and tool use must follow strict rules.
Then
Use either AgentCore path behind a gateway with Policy, and restrict the runtime so it can be invoked only through that gateway.
Rules enforced outside the agent's code cannot be argued around by a manipulated prompt.
If
Sessions must last days, need GPUs or share an instance among collaborating agents.
Then
Use Runtime on the Instances compute type rather than the default microVMs⁷.
Instances run on AWS-managed EC2 capacity in your account and support multi-day sessions.

Bedrock models and Knowledge Bases inside an AgentCore agent

Migration checklist for a Bedrock Agents Classic workload

AWS publishes a migration skill in its agent toolkit and a CLI import path that inspect a Classic agent and map its components to the harness¹. Whichever route you take, work through these points.

0 of 8 checked

Inventory each Classic agentModel, action groups, knowledge bases, prompt overrides, guardrails, aliases and the applications that call it.
Map action groups to gateway toolsOpenAPI and function schemas become MCP tools behind AgentCore Gateway, wrapping the same APIs or Lambda functions.
Replace user prompting and return of controlClassic's built-in user-input tool and return of control become inline function tools that pause and hand back to client code.
Decide what happens to stage prompt overridesFold them into the system prompt, or move the agent to code on Runtime if they carry real logic.
Rebuild multi-agent routing deliberatelyAgent-as-tool covers simple supervisor cases; anything more needs framework code.
Replace aliases with versions and endpointsAgentCore releases immutable versions to named endpoints, so rollback means repointing an endpoint.
Update infrastructure as codeNew environments in accounts without Classic usage must provision AgentCore resources instead.
Run old and new agents side by sideCompare outputs on the same evaluation set before switching callers over.

Questions and answers

What drives cost on AgentCore compared with Bedrock Agents Classic?

Classic itself has no charge; you pay for model inference and resources such as Knowledge Bases and Lambda. AgentCore uses consumption-based pricing for the services you use, with no separate charge for harness orchestration¹. Model tokens, session compute, memory and gateway calls are the main drivers, so model expected traffic against the current AgentCore pricing page rather than assuming parity⁸.

Is AgentCore available in every AWS Region?

Not necessarily, so check the AgentCore Regions list for each service you plan to use. AWS notes that Classic workloads in a Region without AgentCore can keep running there while new development moves to a supported Region¹. Factor data-residency rules into that choice before moving anything.

Can an AgentCore agent use models that are not on Bedrock?

Yes. The harness supports models from Amazon Bedrock, OpenAI, Google Gemini and LiteLLM-compatible providers and can switch provider within a session, while Runtime works with any model your code can call³. Classic is limited to its frozen Bedrock catalog. Data-handling terms differ by provider, so treat a non-Bedrock model as its own review.

Will my existing Bedrock Agents Classic agents stop working?

No. AWS states that existing agents continue to function, the APIs remain available to accounts with prior usage, and there is no migration deadline or planned end-of-life date¹. The trade-off is that Classic receives no new features or models, so migration becomes a question of when the agent next needs to change.

Sources

Amazon Bedrock Agents Classic maintenance mode — Amazon Web Services · checked 10 October 2026
What is Amazon Bedrock AgentCore? — Amazon Web Services · checked 10 October 2026
AgentCore harness vs. Runtime — Amazon Web Services · checked 10 October 2026
Policy in Amazon Bedrock AgentCore: Control Agent Interactions — Amazon Web Services · checked 10 October 2026
Amazon Bedrock AgentCore Evaluations is now generally available — Amazon Web Services · checked 10 October 2026
Amazon Bedrock AgentCore adds quality evaluations and policy controls for deploying trusted AI agents — AWS News Blog · checked 10 October 2026
Host agent or tools with Amazon Bedrock AgentCore Runtime — Amazon Web Services · checked 10 October 2026
Amazon Bedrock AgentCore pricing — Amazon Web Services · checked 10 October 2026

Get a second opinion on your AgentCore hosting path

Describe the agent, any existing Classic or framework code, and your governance requirements. We will reply with the path we would choose and the migration or build steps that carry the most risk.

Discuss your agent hosting