AWS closes Bedrock Agents Classic to new customers, pushing new agent builds toward AgentCore

Amazon Web Services has put its original managed agent service for Amazon Bedrock into maintenance mode for new adoption. The service formerly known as Amazon Bedrock Agents is now documented as Amazon Bedrock Agents Classic, and AWS says it is no longer open to new customers starting July 30, 2026.

That does not mean existing deployments stop working. AWS says current customers can continue using Bedrock Agents Classic, and it separately states that Amazon Bedrock models, Knowledge Bases, and Guardrails are not affected by the change. But the direction for new agent workloads is clear: AWS is recommending Amazon Bedrock AgentCore as the comparable path for new or migrated agent applications.

For teams building on Bedrock, this is more than a service-name change. It shifts the default architecture for AWS-hosted agents from the older Bedrock Agents interface to a newer runtime and tooling stack centered on AgentCore. For platforms that provide an AI API gateway, LLM routing layer, or enterprise agent infrastructure, the cutoff creates a compatibility and migration question that sits alongside ordinary model selection.

What changed on July 30

AWS documentation now identifies Amazon Bedrock Agents as Amazon Bedrock Agents Classic. The same maintenance-mode guidance says Bedrock Agents Classic is closed to new customers from July 30, 2026, while existing customers can continue using it.

The practical meaning depends on the customer’s AWS account and current usage. Existing production systems built on Classic should not assume an immediate shutdown based on the public maintenance notice alone. However, new teams, new accounts, and organizations standardizing future agent infrastructure should treat Classic as a legacy path rather than the default Bedrock agent service.

AWS points new and migrating customers to Bedrock AgentCore. The company describes AgentCore as supporting managed orchestration and a broader set of production-agent capabilities, including tool exposure through the Model Context Protocol, memory, identity, observability, and tracing. Those features suggest AWS is moving from a narrower managed-agent builder toward a more general agent runtime for long-lived, tool-using applications.

One boundary is also important: the change is about Bedrock’s managed agent orchestration layer, not the entire Bedrock platform. AWS says Bedrock models, Knowledge Bases, and Guardrails are not affected. A team can still use Bedrock model inference or retrieval and safety components even if it needs to revisit the agent orchestration service around them.

Why this matters for agent builders

Agent infrastructure has become harder to treat as a thin wrapper around a model call. A production agent often needs tool permissions, memory rules, identity mapping, logging, evaluation, and cost attribution. When the managed orchestration layer changes, developers may need to review how prompts, tool schemas, retrieval, guardrails, and monitoring are wired together.

That is especially true for enterprises that adopted Bedrock Agents Classic as a managed alternative to building their own orchestration. If those companies now create additional environments, onboard new business units, or rebuild in new AWS accounts, they may encounter different availability and recommended architecture than the one used by their existing deployments.

The cutoff also affects vendors and internal platform teams that abstract Bedrock behind a unified interface. A multi-cloud or multi-model platform cannot treat this simply as “route to an AWS model.” It may need to know whether a customer is invoking plain model inference, a Knowledge Base workflow, a Guardrails policy, a Classic agent, or an AgentCore-hosted workload. Those are different operational surfaces with different migration risks.

For Model Gate users and similar gateway customers, the lesson is that LLM API routing is no longer only about price, latency, and model quality. Agent placement matters too. A gateway can help centralize API-key management, usage analytics, team controls, and spend visibility, but it still has to respect the capabilities and lifecycle status of the underlying provider services.

Who is affected

The most directly affected group is AWS customers planning new managed-agent builds on Bedrock. If they have not previously used Bedrock Agents Classic, they should expect AgentCore to be the recommended path. Teams that already run Classic agents can continue using them, according to AWS, but should plan for the service’s maintenance posture when making long-term roadmap decisions.

Cloud architects are affected because reference architectures may need updating. Documentation, Terraform modules, internal golden paths, and security reviews that assumed Bedrock Agents Classic as the standard managed agent layer should be checked against AgentCore’s APIs, identity model, observability features, and operational requirements.

Security and governance teams are also in scope. AgentCore’s emphasis on identity, tool exposure, observability, and tracing reflects the problems enterprises are now trying to solve: which user or service is acting, which tools an agent can call, what data it can retrieve, how a decision can be audited, and how runaway tool loops or expensive model calls are detected.

Software vendors building on Bedrock may need a dual-support period. Existing customers may still be on Classic, while new customers may need AgentCore. That can mean additional testing, feature flags, customer-specific deployment logic, and clearer documentation about which Bedrock agent path is supported.

Practical consequences and open questions

The first practical step is inventory. Teams should identify whether they use Bedrock Agents Classic, plain Bedrock model APIs, Knowledge Bases, Guardrails, or custom orchestration outside Bedrock. The maintenance-mode notice affects those categories differently.

The second step is to map migration dependencies rather than assuming a direct lift-and-shift. Agent workloads may depend on tool definitions, retrieval configuration, prompt templates, IAM permissions, audit logs, and application-specific error handling. Moving to AgentCore may be an opportunity to improve observability and identity controls, but it can still require integration work.

The third step is cost and governance review. New agent runtimes often make it easier to connect more tools and run more autonomous workflows. That increases the value of usage analytics, request-level attribution, and budget controls. In a gateway environment, teams should decide which calls flow through a central policy layer and which remain inside AWS-managed orchestration.

Some details remain account-specific. Independent commentary has suggested that eligibility may depend on prior account usage and that some newly released post-cutoff models may not become available through Classic. Those points should be verified against the customer’s own AWS account and AWS’s current maintenance-mode documentation before being treated as policy.

The larger signal is clear enough: AWS is not exiting Bedrock agents, but it is moving new agent work away from the original Bedrock Agents interface. For developers and platform teams, the safe assumption is that future AWS agent investment will concentrate around AgentCore, while Bedrock Agents Classic becomes a compatibility concern for existing deployments.