TL;DR:

  • Amazon Bedrock Agents is now “Bedrock Agents Classic” and closed to new customers as of July 30, 2026
  • The model catalog is frozen — models released after July 30 won’t appear in Classic
  • Existing agents continue to work with no announced end-of-life date
  • The replacement platform is Amazon Bedrock AgentCore, with a config-based harness path for teams migrating from Classic

Amazon spent three years building Bedrock Agents into a managed orchestration layer for enterprise AI. Then on July 30, 2026, it put the service into maintenance mode, renamed it Bedrock Agents Classic, and closed it to new customers. For teams that have been running production workloads on Classic, the shift raises immediate questions about continuity, model access, and migration timelines.

Here is what actually changed, and what you need to do about it.

What Bedrock Agents Classic Is Now

Classic is in maintenance mode, which AWS defines precisely: existing workloads continue running, support continues, and there is no published end-of-life date. Nothing is being switched off. Your existing agents, action groups, and knowledge bases remain operational.

What is frozen is the model catalog. Foundation models released after July 30, 2026 — new versions of Claude, Amazon Nova, Llama variants, or anything else Bedrock adds to its model lineup — will not be available inside the Classic orchestration layer. If your agents need access to the latest models as they drop, Classic will fall progressively further behind.

This is the functional implication that matters most in practice. Teams that have locked in specific models and don’t need to track new releases can stay on Classic without disruption for now. Teams that depend on model recency — for capability improvements, cost reductions, or staying ahead of deprecated models — need to plan a migration.

What AgentCore Is

Amazon Bedrock AgentCore is the replacement platform, and it is substantially different in architecture from Classic. Where Classic was a managed, opinionated orchestration layer — you declared your tools, knowledge bases, and instructions through the AWS console and Bedrock handled the loop — AgentCore is built around a more programmatic model.

AWS describes it as a platform to build, connect, and optimize AI agents. The core components:

AgentCore Harness: The closest analog to Bedrock Agents Classic for teams migrating. Config-based experience where you declare your model, tools, and system instructions; AgentCore handles compute, memory, identity, and observability under the hood. Teams that want minimal migration friction should start here.

AgentCore Runtime: Managed compute for running agent code, including support for longer-running tasks and persistent execution contexts that Classic didn’t handle well.

AgentCore Memory: Persistent memory layer for agents that need to retain context across sessions — a capability that Classic shipped in a limited form.

AgentCore Gateway: Managed tooling for connecting agents to external APIs and services, replacing Classic’s action groups model with a more flexible interface.

AgentCore Identity and Observability: IAM-based access control and built-in tracing, both of which Classic relied on general AWS services to provide.

Two Migration Paths

AWS has been explicit that there are two routes out of Classic.

Option 1: AgentCore Harness. The fastest migration path for teams that like the managed experience of Classic. You redeclare your agent configuration in AgentCore’s format, which is different from Classic but conceptually similar. AWS has published migration documentation mapping Classic concepts to AgentCore equivalents. This path preserves most of what teams built in Classic while giving access to the full current model catalog.

Option 2: AgentCore Runtime with custom code. For teams that want more control over orchestration logic — using a framework like LangGraph, Mastra, or a custom Python loop — AgentCore Runtime provides managed compute without prescribing the orchestration layer. You bring your own agent code; AgentCore handles hosting, scaling, and the underlying infrastructure.

What To Do Now

If you have agents running on Classic and they’re working, there is no immediate action required. The service will continue functioning. The decision point is model recency.

Check which foundation models your Classic agents use. If those models are on a deprecation timeline with AWS — Claude 2 and Claude Instant, for example, have already gone through deprecation cycles — you will need to migrate regardless of the Classic situation. If you’re using current models and don’t need to upgrade, you have runway.

For new development, the decision is made for you: Classic is closed to new customers. All new agents on AWS should be built against AgentCore from July 30 forward.

Start with the AgentCore Harness if you’re migrating existing Classic workloads. Run the two in parallel — Classic for existing production traffic, AgentCore for new development — until you’re confident in the migration. AWS does not charge differently for Classic vs. AgentCore execution; the cost is the foundation model inference and any additional AgentCore capabilities you use.

The Broader AWS Agent Strategy

The Classic deprecation is part of a larger shift in how AWS is positioning its AI agent services. AgentCore is designed to serve both the console-configured managed path and the code-first path that enterprise development teams prefer. The Classic model, built entirely around an AWS console and API experience, didn’t fit well with teams that wanted to own their orchestration logic in code.

If you were frustrated with Classic’s limitations — particularly around multi-agent coordination, custom memory implementations, and bring-your-own-framework scenarios — AgentCore’s architecture is a meaningful improvement. The migration cost is real but the capability ceiling is substantially higher.

AWS has committed to keeping Classic running with no end-of-life announcement, but the trajectory is clear. Teams that build new agents on Classic are accepting a frozen model catalog and a narrowing support trajectory. The investment in migrating to AgentCore now pays off through continued model access and access to the capabilities AWS is actively developing.

Resources