A Bedrock Agents to AgentCore migration is not urgent. It is inevitable, though, for any agent you plan to keep improving. Amazon Bedrock Agents is now called Bedrock Agents Classic. It closed to new customers on 30 July 2026, it gets no new features, and its model catalogue is frozen. AWS has also announced no end-of-life date. Moving to Amazon Bedrock AgentCore means picking one of two paths: the managed harness, which is configuration-based and closest to Classic, or a code-defined agent on AgentCore Runtime. You then remap each Classic component, run both systems in parallel and switch over only when evaluation results match.
This guide is for engineers who own a working Classic agent. For interview practice, use the Bedrock AgentCore interview questions. For the wider AWS AI stack, see AWS for AI and FDE engineers, and for Bedrock basics, the AWS Bedrock interview guide.
What actually changed for Bedrock Agents Classic
Teams often misread the AWS maintenance-mode page as either "it's being shut down" or "nothing changed". Here is what it says.
- The name. Bedrock Agents (launched November 2023) is now Bedrock Agents Classic. API namespaces, SDK clients, CloudFormation types and IAM prefixes are unchanged.
- Who is allowlisted. Allowlisting is per account: an account with Bedrock Agents activity in the previous 12 months keeps working. Other accounts in the same organisation are not covered, and there is no exception process.
- What new accounts get. In a non-allowlisted account,
CreateAgentandInvokeInlineAgentreturnAccessDeniedException(HTTP 403) with a maintenance-mode message. Other APIs, includingInvokeAgent,UpdateAgentand the alias APIs, remain available. - Frozen model catalogue. Models inside the Classic orchestration layer are fixed as of 30 July 2026. New models arrive through AgentCore, and Bedrock inference itself keeps getting them.
- No end-of-life date and no deadline. AWS still recommends migrating, because no new features are planned.
- Knowledge Bases and Guardrails are not affected. Only the agent orchestration layer is in maintenance.
One detail catches platform teams: Infrastructure as Code templates that create Classic agents keep working only in allowlisted accounts. If your landing zone creates fresh accounts per environment, a Terraform or CDK pipeline that worked last year can fail with a 403 in a new account. AWS also says inline-agent migration guidance is still forthcoming.
Stay on Classic for now, or migrate now?
No deadline means time to plan, not permission to ignore it. Triage each agent separately; most organisations end up with agents in both columns.
| Signal | Stay on Classic for now | Migrate now |
|---|---|---|
| Agent maturity | Stable, low-change agent that meets its targets | Agent with an active roadmap of new tools and behaviours |
| Model needs | The current model is good enough and its cost is acceptable | You need a model released after the catalogue freeze, or a non-Bedrock provider |
| Accounts | Runs only in allowlisted accounts | New accounts, regions or environments must be created |
| Features used | Uses stage-specific prompt overrides or routing-mode multi-agent collaboration, which need code work to move | Model + action groups + knowledge base: the simple shape AWS describes as hours of setup |
| Region | The harness is not yet available in your required region | The harness or Runtime is available where your data must stay |
| Governance | Audit has signed off the current design and nothing is changing | You need per-user identity to downstream systems, tool-level policy or online evaluation |
| Inline agents | You depend on InvokeInlineAgent and are waiting for AWS's inline guidance | New ephemeral-agent work, which AWS points to the harness |
"Stay for now" still needs a review date and an owner. An agent that cannot adopt newer models slowly becomes a cost and quality liability.
The two migration paths, and the tooling
Path 1: the AgentCore harness (AWS's recommended default)
The harness is a configuration-based agent: you declare model, system prompt, tools, memory and limits, and AgentCore runs the loop (built on Strands Agents), with each session in its own isolated microVM on Runtime. AWS calls it the closest analogue to Classic and says to use it unless you need to own the loop. A harness can later be exported to Strands code and run on Runtime, so it is not a dead end.
Path 2: code-defined agents on AgentCore Runtime
Here you own the loop, in any framework (Strands, LangChain or LangGraph, OpenAI Agents SDK, Claude Agent SDK or plain code), packaged as a container on Runtime. Choose it for a custom orchestrator, routing-style multi-agent collaboration, stage-specific prompt overrides or an existing framework codebase. The trade-off: Memory, Gateway and Identity become SDK calls in your code rather than config fields. How these agents reach tools and each other is covered in AI agent protocols explained.
Migration tooling
- The
amazon-bedrockskill in the agent toolkit for AWS. It guides a coding assistant through inventory, an eligibility check, component mapping and a written plan, then pauses for approval before deploying with the AgentCore CLI. It never modifies the source agent, and it stops if a feature has no validated harness path, which makes it a useful assessment tool too. - AgentCore CLI import. It can import a Classic configuration as a starting point for either path. Manually, the flow is
agentcore create,agentcore add harness,agentcore add tool,agentcore deploy.
Both move configuration. Neither proves the new agent behaves like the old one.
Component mapping: Classic to AgentCore, gaps included
Based on the AWS comparison table and harness docs. The third column is what you tell stakeholders before committing to a date.
| Bedrock Agents Classic | AgentCore equivalent | Gap / what to watch |
|---|---|---|
| Action groups (OpenAPI or function schema, optional Lambda executor) | Gateway targets exposed as MCP tools wrapping the same REST APIs and Lambda functions, or code-level tools | Tool names and descriptions change shape. Re-test tool selection, because the model sees a different tool list |
| Knowledge base attached to the agent | Still a Bedrock Knowledge Base, reached as a tool: a Gateway-fronted integration or a code-level retrieval tool | The built-in Gateway KB connector supports managed knowledge bases with IAM outbound auth only. A customer-managed KB (your own OpenSearch or Aurora store) needs a retrieval tool, such as a Lambda target calling Retrieve |
| Session and memory settings (idle TTL, cross-session memory) | AgentCore Memory, short-term and long-term with strategies, scoped per user by actor ID | Classic session summaries do not carry over. Decide whether history must be migrated or can start fresh |
| Guardrails attached to the agent | Guardrails stay on the Bedrock model call, and agent-level enforcement moves to Gateway policies (Cedar-based Policy in AgentCore) | Two layers instead of one. Re-run your red-team set against both |
Return of control and AMAZON.UserInput | Inline function tools: the harness pauses, returns tool_use to your client, and resumes on a matching toolResult in the same session | Automatic parameter elicitation becomes an explicit tool you define. This is also how you build approvals |
| Code Interpreter action group | AgentCore Code Interpreter | Direct equivalent |
| Trace UI (pre-processing, orchestration, KB, observations) | End-to-end tracing through AgentCore Observability in CloudWatch | Span names differ. Rebuild dashboards and alarms instead of expecting them to port |
| Stage-specific prompt overrides | Harness system prompt covers overall behaviour. Full control needs a code-defined agent | Not directly replicated on the harness. This is the most common reason to choose Path 2 |
| Multi-agent collaboration (supervisor, routing) | Agent-as-tool on the harness. Full patterns need framework code on Runtime | Limited. AWS says routing mode is "not straightforward today" |
| Custom orchestrator | Code on AgentCore Runtime | Not available through the harness |
| Versions and aliases | Immutable harness or Runtime versions plus named endpoints. DEFAULT tracks the latest version | Every config update creates a version. Point production at a named endpoint, never at DEFAULT |
Watch the versioning row. In Classic you cut a version and moved an alias. In AgentCore, every update creates an immutable version and DEFAULT follows it, so a client calling DEFAULT ships every config change straight to production. Named endpoints move only when you update them, and rollback is repointing. For approval UX behind inline tools, see human-in-the-loop AI.
To practise this kind of migration on guided projects, Cloudsoft's FDE PRO program covers AWS-first agent engineering with MCP tools, observability and evaluation gates, in Ameerpet or live online.
IAM and identity changes
IAM is where migrations usually stall.
- New service principal and execution role. The harness assumes a role you own, trusted by
bedrock-agentcore.amazonaws.com, with Bedrock invoke, CloudWatch Logs, X-Ray, workload identity, Memory andInvokeGatewaypermissions. The CLI scaffolds it; scope it down to specific inference profiles and ARNs. - Dual permissions for callers.
InvokeHarnessneeds bothbedrock-agentcore:InvokeHarnessandbedrock-agentcore:InvokeAgentRuntime. CloudTrail records harness activity underAWS::BedrockAgentCore::Runtime, so update audit queries. - Action group Lambdas get a new caller. Behind Gateway, a gateway service role calls them, so resource policies need redoing.
- Per-user identity requires JWT inbound auth. With SigV4 callers, the harness does not propagate per-user identity downstream; user-scoped OAuth tokens and on-behalf-of exchange need a bearer JWT on the OAuth inbound path. Replacing a shared service role is often the most valuable upgrade, and the most work.
- Lock down direct command execution.
allowedToolsdoes not coverInvokeAgentRuntimeCommand; do not grant it to application callers. - Validate caller input. Under the shared responsibility model this is yours, including stripping caller-supplied
model,additionalParamsandskillsfields.
Broader patterns are in AI agent identity and access management.
Observability and evaluation
AgentCore Observability emits OpenTelemetry-compatible telemetry into CloudWatch. The harness traces model calls, tool calls, memory operations and shell commands automatically, once you enable CloudWatch Transaction Search (one-time per account). Code-defined agents add their own spans, and OTel compatibility lets you also feed an existing backend such as Langfuse.
AgentCore Evaluations has three modes, each with a migration role:
- Batch evaluation scores many sessions from CloudWatch Logs, with ground truth (expected responses, assertions, tool trajectories) as session metadata. AWS positions it for baselines and before/after comparison.
- On-demand evaluation scores chosen traces. Use it on cases where the systems disagree.
- Online evaluation samples live traffic with built-in LLM-as-judge or custom evaluators. Turn it on during the parallel run and leave it on.
Classic traces are in a different format, so replay one curated test set through both systems and score both with the same evaluator. Building that set is covered in AI agent evaluation.
How the pricing model changes
AWS says Classic itself has no charge: you pay for inference and resources such as Knowledge Bases and Lambda. AgentCore is consumption-based, metered per capability:
- Runtime bills per second for CPU and memory consumed. CPU is free during I/O wait, but memory bills while the session lives, so idle timeouts matter.
- Gateway bills per operation (tool listing, invocation, search, indexing). Memory bills for events, stored long-term records and retrievals. Policy bills per authorisation request. Evaluations bills by evaluator tokens or per evaluation. Observability is billed through CloudWatch ingestion, storage and queries.
- The harness has no separate charge. AWS says it is more token-efficient than Classic's internal prompts. Measure that in the parallel run, since unused tool definitions add input tokens unless trimmed with
allowedTools.
Set execution limits (iterations, timeout, token budget, idle timeout) and tag the harness; tags propagate to its managed Runtime and Memory, but a separate Gateway needs its own.
A step-by-step migration plan
Inventory -> Baseline eval -> Build on AgentCore
| |
v v
Gap report Shadow run (both live)
|
v
Parity gate -> Canary -> Cut-over
|
v
Keep Classic warm -> Decommission- Inventory. Per agent: model, action groups and Lambdas, knowledge bases (managed or customer-managed), guardrails, prompt overrides, collaborators, aliases, callers, account and region. Run the skill for an eligibility verdict.
- Freeze a baseline. Build a test set from redacted real transcripts: happy paths, tool-heavy flows, refusals, guardrail triggers, past failures. Score Classic on task success, tool-call correctness, groundedness, latency and cost per conversation.
- Choose the path for each agent. Harness by default; code-defined where the gap report demands it.
- Rebuild the tool layer first. Put existing Lambdas and APIs behind Gateway unchanged, with policies mirroring old rules.
- Wire identity, memory and knowledge. JWT inbound auth for per-user scoping, Memory with actor IDs, KBs via connector or retrieval tool.
- Deploy behind a named endpoint. Pin
stagingandprodendpoints to versions. - Shadow run. Mirror sampled production requests to AgentCore with write tools stubbed, and score both with the same evaluators.
- Parity gate. Agree thresholds in advance: no regression on critical intents, no new policy violations, latency and cost within tolerance. Review disagreements by hand.
- Canary and cut-over. Route a small share of users with online evaluation on, widen gradually, roll back by repointing.
- Decommission deliberately. Keep Classic warm for an agreed period, then retire its roles, alarms and runbooks.
Migration risks to plan for
- Behaviour drift. A new loop changes tool choice and tone even on the same model.
- Lost prompt overrides. Stage overrides often hold business rules; decide where each one moves.
- Exposed write tools. Without Cedar policies and approval tools, Gateway can widen who reaches a write API.
- Region availability. At the time of writing, the AWS regions page lists the harness and Memory in Asia Pacific (Mumbai) but not in Asia Pacific (Hyderabad), where Runtime microVMs are available. Check the current table against your data-residency needs before you commit to a path.
- Two systems to operate. The parallel run doubles on-call scope; give it an end date.
Illustrative example: a bank GCC in Hyderabad
Consider a bank's global capability centre in Hyderabad that runs three Classic agents: a staff-facing policy Q&A agent, a card-dispute triage agent with action groups calling core banking APIs, and a supervisor agent that routes between them.
Triage gives three outcomes. The policy agent (model plus a customer-managed KB on Aurora pgvector) moves to the harness with a retrieval tool, since the managed-KB connector does not apply. The dispute agent moves to the harness too: Lambdas behind Gateway, return of control becoming an inline request_refund_approval tool answered from the case system, Cedar policies blocking refunds above a threshold without an approval record, and JWT inbound auth from Entra ID so core banking calls carry the analyst's identity. The supervisor uses routing-mode collaboration, so it is rebuilt as a LangGraph graph on Runtime with the other two as tools.
A shadow period with refund writes stubbed, a parity review with risk, and a named prod endpoint complete the cut-over; Classic stays warm until the next audit. No business logic changed. The work was identity, policy and evaluation.
FAQ
Is Amazon Bedrock Agents being shut down?
No. Bedrock Agents Classic is in maintenance mode. It closed to new customers on 30 July 2026, gets no new features and has a frozen model catalogue, but AWS has announced no end-of-life date and no migration deadline for existing customers.
Why do I get AccessDeniedException when creating an agent?
Your account is not on the allowlist. Only accounts with Bedrock Agents activity in the previous 12 months can call CreateAgent and InvokeInlineAgent. Other accounts receive AccessDeniedException (HTTP 403), and there is no exception process, so use AgentCore in that account.
Should I choose the AgentCore harness or a code-defined agent on Runtime?
Start with the harness unless you need to own the orchestration loop. Choose a code-defined agent for stage-specific prompt overrides, routing-style multi-agent collaboration, a custom orchestrator or an existing framework codebase.
Do my Bedrock Knowledge Bases and Guardrails need to be migrated?
No. Both are unaffected. Knowledge Bases are reached from AgentCore as tools, through the Gateway connector for managed knowledge bases or a retrieval tool for customer-managed ones. Guardrails still apply to model calls, with agent-level policy enforced on Gateway.
What replaces return of control in AgentCore?
Inline function tools. The harness pauses, returns the tool call to your client code, and resumes when you send the matching tool result in the same session. The same mechanism implements human approvals.
How do Classic aliases map to AgentCore?
Every harness or Runtime update creates an immutable version. Named endpoints point to specific versions, while the DEFAULT endpoint tracks the latest one. Point production at a named endpoint and roll back by repointing it to an earlier version.
Is there an automated migration tool?
Yes. The amazon-bedrock skill in the agent toolkit for AWS inventories a Classic agent, checks eligibility, writes a plan and deploys a harness through the AgentCore CLI after your approval. The CLI can also import Classic configurations. Neither replaces evaluation.
Will AgentCore cost more than Bedrock Agents Classic?
It depends on the workload. Classic has no charge of its own beyond model inference and resources, while AgentCore meters Runtime, Gateway, Memory, Policy, Evaluations and observability separately. AWS says the harness uses fewer tokens, so measure cost per conversation during the parallel run.
Migrating an agent without breaking its users is the work Forward Deployed Engineers do: inventory, identity, tooling, evaluation and a careful cut-over, from AI demo to enterprise outcome. To build those skills on real projects, explore the AI Forward Deployed Engineer course (FDE PRO), or start with the Amazon Bedrock and GenAI course. Classes run in Ameerpet or live online, and you can book a free demo on +91 96660 19191.
