By ByteBot
AWS made two quiet moves last week that every Bedrock agent developer needs to act on. On July 30, Bedrock Agents Classic closed to new customers and had its model catalog permanently frozen. More urgently: on August 6 — four days from now — AWS Agent Registry goes generally available under a completely new namespace. If you use Agent Registry and do nothing, your endpoints, IAM policies, SDK clients, and CLI scripts will fail when the migration window closes on September 17.
Bedrock Agents Classic: What Actually Changed
The product launched in November 2023 is now officially “Bedrock Agents Classic.” Since July 30, new AWS accounts cannot call CreateAgent or InvokeInlineAgent — they get a 403 AccessDeniedException with the message “Bedrock Agents is in Maintenance Mode.” Accounts that have used Bedrock Agents in the past 12 months are allowlisted and unaffected.
If you are an existing customer, your agents will keep running. All the APIs you care about — InvokeAgent, UpdateAgent, ListAgents — are unchanged. What is permanently frozen is the model catalog. Any model AWS releases after July 30 will only be available through AgentCore. If you want to upgrade from an older model, Classic will not get that option. That is the real cost of staying put.
The August 6 Deadline That Actually Breaks Things
The Classic freeze is a soft deprecation with no announced end-of-life date. The Agent Registry namespace change is not soft. On August 6, AWS Agent Registry graduates from public preview to GA — and with it, the service moves from the bedrock-agentcore namespace to a new, dedicated agent-registry namespace. Every surface that references the service changes.
Here is what you must update:
- Endpoints:
bedrock-agentcore.{region}.amazonaws.combecomesagent-registry.{region}.api.aws - IAM action prefix:
bedrock-agentcore:*becomesagent-registry:* - IAM managed policy: Replace
BedrockAgentCoreFullAccesswith the newAgentRegistryFullAccess— the old policy will not be updated to includeagent-registry:*permissions - SDK clients:
boto3.client("bedrock-agentcore")becomesboto3.client("agent-registry") - CLI commands:
aws bedrock-agentcore-controlbecomesaws agent-registry-control - Resource ARNs:
arn:aws:bedrock-agentcore:...becomesarn:aws:agent-registry:... - Observability: CloudWatch namespace, EventBridge source, and CloudTrail event source all change to reflect the new service name
One critical exception: workload identity and OAuth credential provider resources stay under the bedrock-agentcore namespace. Do not do a blanket find-and-replace across your IAM policies — you will break your credential providers.
The API schema also changed. This is not a pure namespace rename. The old name field on registry records is now displayName. A new required name field serves as the deduplication key. The recordType enum (AGENT, MCP, SKILL, CUSTOM) is now required on every record. List APIs switched from GET to POST. Authorization config moved under a discoveryConfiguration wrapper. Your existing code that constructs or parses API requests must be updated.
You have until September 17 to complete the migration. After that, the bedrock-agentcore namespace for Agent Registry shuts down and you lose access to your data. AWS provides a migration script in the agentcore-samples repository that handles extract, transform, and load automatically.
Migrating Bedrock Agents Classic to AgentCore
For existing Classic agents, the recommended path is the AgentCore managed harness. It is the closest equivalent: declare your model, tools, and instructions, and AgentCore handles compute, memory, identity, and observability. Three commands cover the basic setup:
agentcore create --name my-agent
agentcore add harness --name my-agent --model-id us.anthropic.claude-sonnet-4-6-20250514-v1:0 --system-prompt "You are a research assistant."
agentcore deployAWS also built an automated migration skill in the agent toolkit for AWS. Install the toolkit, enable the amazon-bedrock skill, and prompt your coding agent with “Help me migrate my Bedrock Agent to AgentCore harness.” It inspects your existing agent, checks migration eligibility, and drives the CLI to scaffold and deploy the harness — pausing for approval at each step.
For workloads that need more control, AgentCore supports code-defined agents running on its managed runtime. Any framework works: Strands, LangChain, OpenAI Agents SDK, Claude Agent SDK, or custom code. AgentCore also supports multi-provider models — Bedrock, OpenAI, Gemini, or any LiteLLM-compatible endpoint — and can switch providers mid-session without losing context.
What Does Not Map 1:1
Three things in Classic do not have direct harness equivalents. Stage-specific prompt overrides — pre-processing, KB response generation, post-processing — are not directly replicated in the harness. Achieving stage-level control requires combining the system prompt with command execution and self-managed scripts. Multi-agent routing mode is also not directly available; the agent-as-tool pattern works for simpler cases, but the Classic routing mode requires custom framework code. The AMAZON.UserInput built-in tool for automatic parameter elicitation is replaced by explicit inline function tools — equivalent behavior, more verbose setup.
If any of these matter to your workload, review the official capability comparison table before committing to a migration timeline. The Agent Registry migration guide has before-and-after examples for every surface that changes.
Bottom Line
AWS tends to bundle soft deprecations with hard deadlines in the same announcement, and this week is a good example. The Classic freeze is not urgent — your existing agents work today and have no announced end-of-life date. The Agent Registry namespace change is urgent. If you have any code or infrastructure targeting the bedrock-agentcore Agent Registry APIs, audit and update it before September 17. For new agent development on AWS: skip Classic entirely. The model catalog is already frozen, and AgentCore is where all future AWS investment is going.
