Amazon Bedrock Agents, launched November 2023, closed to new customers on July 30 and is now called Bedrock Agents Classic. Existing agents keep running, and AWS states plainly that there is no end-of-life date and no migration deadline.
The model catalog is frozen as of that same date, so the deadline exists, it just arrives quietly as your agent falls behind the models everyone else is running.
What did not survive the generation change is the interesting part: four capabilities have no clean equivalent in the replacement, and all four are where teams put their business logic.
What actually changed
Two API calls are now gated: CreateAgent and InvokeInlineAgent. If your AWS account has had Bedrock Agents activity in the past 12 months, you are allowlisted and nothing changes for you. If it has not, both calls return AccessDeniedException with HTTP 403 and the message "Bedrock Agents is in Maintenance Mode. New agent creation is not available for accounts without prior service usage."
The allowlist is per-account and there is no exception process. AWS computes it automatically from the past 12 months of usage. Spin up a fresh account for a new environment and it cannot create a Bedrock Agent, even when the account beside it can.
Everything else stays. UpdateAgent, GetAgent, ListAgents, InvokeAgent, the action group APIs, the knowledge base APIs, and the alias APIs remain available to everyone. The bedrock-agent namespace, the SDK clients, the CloudFormation resource types, and the IAM action prefixes are unchanged, so existing Terraform and CDK keeps working for allowlisted accounts.
AgentCore, the replacement, went generally available on July 23. Classic closed its doors seven days later.
The comparison table is the document worth reading
AWS published a capability mapping from Classic to AgentCore, and most rows are clean. The managed orchestration loop maps to the AgentCore harness. Knowledge bases map to gateway-fronted retrieval. Session and memory config maps to AgentCore memory. The AMAZON.CodeInterpreter action group maps to the AgentCore code interpreter.
Four rows are not clean, and they have something in common.
Stage-specific prompt overrides do not survive. In Classic you could override the prompt at pre-processing, orchestration, knowledge base response generation, and post-processing. The AgentCore harness gives you one --system-prompt. AWS's own wording is that equivalent behavior "requires combining the system prompt with command execution and self-managed scripts."
AMAZON.UserInput does not survive as a built-in. Classic would automatically reprompt the user to elicit a missing parameter mid-orchestration. On the harness you define an inline function tool, the harness pauses and hands tool_use back to your client code, and your client code runs that conversation. Same outcome, except the elicitation logic is now yours to write and keep.
Multi-agent collaboration is listed as "Limited." The supervisor pattern is possible by exposing agents as MCP tools. Routing-mode multi-agent is, in AWS's words, "not straightforward today." Full multi-agent collaboration requires custom framework code.
Custom orchestrators are not available through the harness at all. You drop down to AgentCore runtime and deploy your own orchestration code.
The pattern is hard to miss. The generic loop ported over fine. The four places where teams encoded their specific behavior are the four places you rewrite.
Action groups are the fifth case and the most work in practice. In Classic an action group was an OpenAPI or function schema plus an optional Lambda executor, attached to the agent. On AgentCore, tools go through the gateway as MCP tools. The Lambda still exists and the capability is the same, but the plumbing between agent and tool is now separate infrastructure you deploy, secure, and pay for.
No deadline is not the same as no clock
AWS is being straightforward. Nothing breaks, no forced migration, no end of life. A team on Classic can do nothing for a long time.
Then there is this line in the FAQ: the model catalog available in Bedrock Agents Classic is frozen as of the maintenance mode effective date. Models released after July 30 appear in AgentCore, not in Classic. Bedrock itself, meaning model inference, knowledge bases, and guardrails, keeps receiving new models. The freeze applies specifically to the Classic orchestration layer.
That is the clock. Your agent will keep performing exactly as well as it did on July 30, 2026, indefinitely, while agent capability keeps moving underneath it.
For scale, look at what one week produced. On July 31 DeepSeek shipped a checkpoint with the same architecture and the same parameter count as its April preview, changed only the post-training, and moved DeepSWE from 7.3 to 54.4. That is the current rate of change on the exact axis that matters for agents. A pinned catalog against that curve is not stability. It is decay with a polite announcement.
If you are on Classic and choosing to wait, price the choice honestly. You are committing to run that workload on July 2026 models for as long as the workload lives.
The migration tool is an agent
AWS's recommended migration path is an agent skill. The agent toolkit for AWS ships an amazon-bedrock skill you point at an existing Bedrock Agent. It inspects the configuration, checks migration eligibility, maps each component to its harness equivalent, produces a written plan, pauses for your approval, then drives the AgentCore CLI to scaffold and deploy. It never modifies the source agent, and when it hits a feature with no validated harness path it stops and suggests alternatives.
Set the recursion aside, because the operational detail is the useful part. The migration surface was well-defined enough that AWS could hand it to a coding agent with a checkpointed approval flow. That says something real about how mechanical most of these migrations are. AWS estimates hours for a straightforward agent, meaning model plus action groups plus knowledge base, with most of the effort going into reviewing generated code and redeploying action groups behind the gateway. Complex agents with custom orchestrators or multi-agent collaboration are explicitly flagged as more significant code work.
Cost changes shape too. Classic carried no charge for the orchestration layer itself, you paid only for inference and the resources behind it. AgentCore is consumption-based across runtime, memory, and gateway. AWS argues the harness is more token-efficient than Classic's internal prompts, so inference may drop, but there are now line items where previously there were none.
The part that generalizes
When AgentCore went GA I argued the plan-act-observe loop was moving out of application code and into managed runtimes, and that this was the right direction, because nobody's competitive advantage lives in their retry logic. That still holds.
This is the invoice for it. Bedrock Agents was AWS's flagship agent product for 32 months and is now the thing you migrate off. The successor reached GA one week before the predecessor stopped accepting new customers. A team that built on Classic in 2024 got roughly two years of stability out of a managed abstraction.
That is not an argument against managed runtimes. It is an argument for knowing which parts of your agent are portable. The declarative shell, model, tools, and instructions moves between vendors and generations cheaply. The stage-specific prompt surgery, the parameter elicitation behavior, and the routing between specialist agents is where you are exposed, because that is the layer each vendor implements its own way and drops between generations.
Write those parts as though you will have to port them. On a 32-month cycle, you will.