The short answer
Amazon Bedrock Agents was renamed Bedrock Agents Classic and closed to new customers on July 30, 2026. AWS charges nothing for the Classic orchestration layer itself, and AgentCore replaces it with consumption pricing across runtime, memory and gateway, with no separate harness orchestration charge. The cost that matters is not the invoice line, it is the rebuild. AWS documents three capabilities the harness does not replicate directly, and one operational trap that catches larger organizations: the allowlist is per AWS account, based on whether that account used Bedrock Agents in the previous 12 months, and AWS states plainly that there is no exception process.
Last updated: August 2026. Source: AWS, Amazon Bedrock Agents Classic maintenance mode documentation, read August 30, 2026.
AWS spent the summer of 2026 retiring the first generation of its AI services. Amazon Kendra went into maintenance mode on July 30, Amazon Q Business closed to new customers on July 31, and in the same window Amazon Bedrock Agents was renamed Bedrock Agents Classic and stopped accepting new customers. Three products, one month, the same playbook each time.
The Bedrock Agents change has been covered as a deprecation, which it is not, and priced as a migration, which mostly misses where the money goes. Here is what AWS actually documents, including the parts that decide whether this is a weekend of work or a quarter of it.
What exactly changed on July 30, 2026?
AWS's wording is short: "Amazon Bedrock Agents (launched November 2023) is now Amazon Bedrock Agents Classic and will no longer be open to new customers starting on July 30, 2026." Amazon Bedrock itself is unaffected, and AWS is explicit that existing models, Knowledge Bases and Guardrails continue as before. Only the Agents Classic orchestration layer moved into maintenance mode.
For existing workloads nothing breaks. All the APIs stay available: UpdateAgent, GetAgent, ListAgents, DeleteAgent, PrepareAgent, InvokeAgent, plus the action group, knowledge base and alias APIs. Two calls are restricted, CreateAgent and InvokeInlineAgent, and only for accounts without prior usage. Existing IaC templates keep working for allowlisted accounts, and the rename is cosmetic: API namespaces, SDK clients, CloudFormation resource types and IAM action prefixes are all unchanged.
One thing does stop, and it is the reason to plan a move rather than shrug. The model catalog is frozen as of July 30, 2026. Any model released to Bedrock after that date is available through AgentCore and not through Agents Classic. In a category where model quality has been the main axis of improvement, a frozen catalog is a slow expiry even without an end-of-life date.
Can I still create a Bedrock Agent?
Only in an AWS account that already used Bedrock Agents in the previous 12 months. AWS allowlists automatically on that basis, and the allowlist is per account, not per organization. Accounts without prior usage get an 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."
This is the sentence that should change someone's plan: "This applies per-account. If you have multiple AWS accounts, only those with prior Bedrock Agents usage are allowlisted." Plenty of organizations run separate accounts per environment, per team or per subsidiary. A company that has been building on Bedrock Agents in production for a year can still be locked out the moment it provisions a fresh account for staging, a new business unit or an acquisition.
Asked whether an exception is possible, AWS answers in three words: "No. There is no exception process." That is unusually blunt, and it means the workaround people normally reach for, a support ticket and a sympathetic account manager, is not on the table. If a new account needs agent capability, it needs AgentCore.
What does Bedrock Agents Classic cost now?
Nothing, for the orchestration layer. AWS states there is no charge for Bedrock Agents Classic itself, and that you continue to pay only for the underlying model inference and any associated resources such as Knowledge Bases and Lambda invocations. Maintenance mode changed no prices.
That is worth pausing on, because it inverts the usual migration argument. There is no cost saving waiting on the other side of this move. You are not escaping a fee, and a spreadsheet comparing the two on licensing will show a wash. The case for migrating rests entirely on the frozen model catalog, the absence of new features and the per-account allowlist, which are strategic reasons rather than budgetary ones.
How much does AgentCore cost?
AgentCore uses consumption-based pricing across runtime, memory and gateway, and AWS confirms there is no separate harness orchestration charge. So the shape is the same as Classic on the model side, with metered platform capabilities added underneath.
AWS makes one claim about inference cost that is worth testing rather than trusting: the harness "is more token-efficient than Bedrock Agents Classic's internal prompts, so customers may see comparable or lower model inference costs." Note the hedge in "may." Classic's managed orchestration injected its own pre-processing and post-processing prompts on every turn, so a leaner harness plausibly does reduce token spend. Whether it does so for your workload depends on how much of that scaffolding you end up rebuilding as explicit tools. Measure it on one agent before you extrapolate across a fleet.
The honest budget line for this migration is engineering time, not AWS spend. Which brings us to the part AWS documents better than most vendors would.
What does AgentCore not replicate?
AWS publishes a capability comparison table that concedes three real gaps. Credit where it is due: most vendors do not print the list of things their migration target cannot do.
| Bedrock Agents Classic feature | What AWS says about AgentCore | What it costs you |
|---|---|---|
| Stage-specific prompt overrides for pre-processing, orchestration, knowledge base response generation and post-processing | "Not directly replicated." A system prompt covers overall behavior; equivalent behavior "requires combining the system prompt with command execution and self-managed scripts" | Rework for any agent whose accuracy was tuned at a specific stage rather than globally |
| Multi-agent collaboration with roles and routing, for example supervisor agents | "Limited." The supervisor pattern works by exposing agents as MCP tools, but "routing mode multi-agent is not straightforward today." Full collaboration "requires custom framework code" | The largest single item. A routed multi-agent design may need rearchitecting rather than porting |
| Built-in AMAZON.UserInput tool for automatic reprompting and parameter elicitation | Handled by inline function tools returning control to your client code. "Requires explicit tool definition rather than automatic elicitation" | Client-side code you did not previously have to write, per agent |
Everything else maps cleanly. Action groups become MCP tools behind the AgentCore gateway, Knowledge Bases connect through the gateway or a retrieval tool, the code interpreter and session memory have direct equivalents, and tracing is if anything better, since AgentCore provides persistent end-to-end tracing of all agent actions. Guardrails configured on the Bedrock model still apply.
AgentCore also does things Classic could not. It supports the full Bedrock catalog plus OpenAI, Gemini and any OpenAI-compatible endpoint, and you can switch model providers mid-session without redeploying. For teams that felt locked into one vendor's models, that is a genuine gain rather than a consolation.
How long does the migration take?
AWS says hours for a straightforward agent, meaning a model plus action groups plus a knowledge base, using the AgentCore CLI import or harness setup. Complex agents with custom orchestrators or multi-agent collaboration "will require more significant code work."
There is a guided path. AWS publishes an amazon-bedrock skill in its agent toolkit that inspects your existing agent, checks migration eligibility, maps each component to its harness equivalent and drives the CLI to scaffold and deploy. It pauses for approval at each checkpoint and never modifies the source agent, so the old one keeps running while you build the new one. If a feature has no validated harness path, the skill stops and says so rather than guessing, which is the correct behavior.
Migration is also a reasonable moment to ask a question that gets skipped: should you be running this agent at all? A meaningful share of first-generation Bedrock Agents were built to do jobs that are now packaged products. If yours answers customer questions and books appointments, rebuilding the orchestration by hand is a lot of work compared with an AI agent that already handles customer conversations end to end. Porting a custom build is the right call when the logic is genuinely yours, and an expensive habit when it is not.
Is there a deadline to migrate?
No. AWS states there is no migration deadline and that Bedrock Agents Classic remains available to existing customers in maintenance mode with no planned end-of-life date. Regions matter here too: if your workloads run somewhere AgentCore is not yet available, AWS says you can keep using Classic there while migrating new development to a supported region.
This matches what AWS did with Kendra and Q Business, and it matches the wider pattern in this category. Vendors closing a product to new customers almost never publish a shutdown date, which is comfortable for existing customers and useless for planning. The date that actually binds you is not on AWS's calendar, it is the point where the frozen model catalog costs you more in capability than the migration costs in engineering time.
What this means if you are buying rather than building
Three AWS retirements in one month is a pattern worth reading. Bedrock Agents Classic, Amazon Kendra and Amazon Q Business were all first-generation services launched into a category that moved faster than the products did. Teams that had built search and agent workflows on them are now doing a rebuild they did not budget for.
If your reason for building on Bedrock Agents was that you needed answers across company content, price the alternative honestly before you rebuild. Our breakdown of Amazon Q pricing covers what the AWS-native path costs today across Q Business, Q Developer and Amazon Quick, including the hourly index units and the $250 per account monthly fee that per-seat quotes leave out. Bedrock Knowledge Bases versus Kendra covers the same question one layer down, and the wider field with a price column sits on enterprise search tools.
The durable lesson is about where you put the orchestration. Model choice turned out to be portable, since AgentCore takes the whole Bedrock catalog plus other providers. What was not portable was the managed orchestration layer, the stage-specific prompts and the routing logic, which is exactly the part teams assumed was the safe, managed, someone-else's-problem piece. If you are designing the next one, keep the parts that encode your business logic somewhere you control, and treat the vendor's convenience layer as rentable rather than permanent.