Bedrock Agents Classic locks out new accounts on 30 July 2026: the AgentCore migration map

Summary. From 30 July 2026, Amazon Bedrock Agents — the service AWS launched in November 2023 and has now renamed Bedrock Agents Classic — is closed to new customers. Accounts that have not called CreateAgent or InvokeInlineAgent in the past 12 months will get an AccessDeniedException (HTTP 403), and AWS says there is no exception process. Existing agents keep running, every existing API stays available, and Knowledge Bases and Guardrails are untouched. The model catalog inside Classic freezes on that date, so any model released afterwards is reachable only through Amazon Bedrock AgentCore. AWS is pushing hard: Swami Sivasubramanian, Vice President of Agentic AI at AWS, wrote on 17 June 2026 that "building an agent is simple, but getting it to production can be complex", and disclosed that tasks performed by agents on AgentCore grew 15x in six months, with Nasdaq, Visa and Experian scaling agents in production. AgentCore Runtime bills $0.0895 per vCPU-hour and $0.00945 per GB-hour. Here is what actually breaks, what does not, and the command-level path across.

What changes on 30 July 2026, and what does not

Most coverage of this change calls 30 July a migration deadline. It is not one. AWS's own FAQ is explicit: Bedrock Agents Classic "remains available to existing customers in maintenance mode with no planned end-of-life date." What ends on 30 July is new-account access and forward model support.

The distinction matters for planning. If you are already running agents, nothing goes down that morning. If you are provisioning a new AWS account — a new environment, a new subsidiary, a client account, a fresh sandbox for a proof of concept — that account cannot create a Bedrock Agent at all unless it happens to be allowlisted.

The frozen model catalog is the item that quietly forces a timeline. An agent stack that cannot adopt a newer model is a stack that will be outrun on cost per token and on tool-calling reliability within a couple of release cycles. That is the real clock, not the 30 July date.

Are you allowlisted? Check before you plan anything

The allowlist is automatic and per-account. AWS determines it by whether the account has called CreateAgent or InvokeInlineAgent in the past 12 months. If you run a multi-account organisation — and most teams beyond a single product do — the answer will differ account by account. A production account that has been running agents for a year is allowlisted. The staging account someone spun up last month, or the account your platform team will create for the next business unit, is not.

The error you will see is specific enough to alert on:

            AccessDeniedException (HTTP 403)
Bedrock Agents is in Maintenance Mode. New agent creation is not available
for accounts without prior service usage.
          

A quick way to enumerate exposure across an organisation is to list agents in every account and region you operate in:

            for acct in $(aws organizations list-accounts \
    --query 'Accounts[?Status==`ACTIVE`].Id' --output text); do
  for region in us-east-1 us-west-2 eu-central-1 ap-south-1; do
    echo "== $acct / $region"
    aws bedrock-agent list-agents --region "$region" \
      --query 'agentSummaries[].[agentName,agentStatus]' --output text 2>/dev/null
  done
done
          

Any account that returns nothing is an account that will fail on the next CreateAgent call after 30 July. Infrastructure-as-code is where this bites hardest: AWS confirms existing CloudFormation, CDK and Terraform templates keep working for allowlisted accounts, but the same template applied to a new account will fail. If your platform team provisions environments from a shared module that includes AWS::Bedrock::Agent, that module has a fixed shelf life.

The capability map: Classic to AgentCore

AgentCore is not a drop-in replacement. It is a serverless platform with two entry points — a config-based managed harness that behaves like Classic, and a runtime for code-defined agents where you own the loop. AWS announced general availability of the AgentCore harness at AWS Summit New York on 17 June 2026, alongside Amazon Bedrock Managed Knowledge Base, Web Search on AgentCore, and the integration of Bedrock Guardrails into AgentCore policy.

The migration guide maps Classic features one by one. Four of those mappings are not equivalents, and they are where migration budgets go.

Read that table as a scoping document. If your agent is a model, a couple of action groups and a knowledge base, this is a day of work. If it depends on stage-specific prompt overrides or supervisor-routed multi-agent collaboration, you are writing code, not editing config. AWS's own estimate matches: straightforward agents take hours, while agents with custom orchestrators or multi-agent collaboration "require more significant code work."

The migration procedure, command by command

The prerequisites are Node.js 20 or later with the AgentCore CLI, or Python 3.10 or later with boto3, plus AWS credentials in one of four regions the migration guide names — us-east-1, us-west-2, eu-central-1 and ap-southeast-2 — and an IAM execution role with the required permissions. Note the mismatch worth checking before you commit: the migration guide still describes those four as preview regions, while the 17 June 2026 Summit announcement declared the harness generally available. Confirm the current AgentCore region list for your workload rather than trusting either page in isolation. There is no ap-south-1 in that named list, which matters for Indian teams with data-residency commitments.

Step one, create the harness and map the old configuration onto it. Review the existing agent's model, action groups, knowledge bases and prompt overrides, then map model to --model-id, action groups to Gateway tools, knowledge bases to a Gateway or retrieval tool, and the prompt to --system-prompt:

            agentcore create --name my-research-agent

agentcore add tool --harness my-research-agent \
  --type agentcore_browser --name browser
agentcore add tool --harness my-research-agent \
  --type agentcore_code_interpreter --name code-interpreter
          

To bring existing action groups across without rewriting them, front them with a Gateway:

            agentcore add tool --harness my-research-agent \
  --type agentcore_gateway --name my-gateway \
  --gateway-arn arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gw
          

Step two, attach the model and instructions:

            agentcore add harness \
  --name my-research-agent \
  --model-id us.anthropic.claude-sonnet-4-6-20250514-v1:0 \
  --system-prompt "You are a research assistant." \
  --tools agentcore-browser,code-interpreter
          

Step three, deploy and invoke. Memory is enabled by default, and --actor-id scopes it per user so long-term strategies keep extracted knowledge isolated:

            agentcore deploy

agentcore invoke --harness my-research-agent \
  --session-id "$(uuidgen)" --actor-id alice \
  "Summarise the open incidents assigned to me"
          

One detail that is easy to miss and useful in production: you can override the model on any single invocation without redeploying, using --model-id on agentcore invoke. That makes A/B testing a model swap cheap, which is exactly what a frozen Classic catalog prevents.

The AgentCore CLI can also import an existing Bedrock Agents Classic configuration as a starting point for either path. AWS says a guided migration agent skill is "under development"; until it ships, the manual mapping above is the documented approach. Do not wait for the tool.

What AgentCore costs

Classic itself was free — you paid only for model inference and downstream resources. AgentCore introduces platform charges on top of inference, so a migration that looks like a straight lift changes the shape of the bill. These are the published list rates on the AgentCore pricing page as of July 2026, before regional variation.

Two things follow. First, the billing model rewards agents that finish: a chatty agent that holds a session open through six tool calls pays vCPU-hours the whole time it is thinking, even though idle I/O wait is excluded. Second, AWS argues the harness is more token-efficient than Classic's internal prompts, so inference cost may fall while platform cost rises. Model that on your own traffic before you sign off on a budget; the direction of the net change depends entirely on session length and tool-call count. If you are already tracking agent spend, the same discipline covered in our FinOps guide for AI and cloud cost in India applies here — meter the sessions before you meter the tokens.

The four gaps that will cost you real engineering time

Stage-specific prompt overrides. Classic let you inject different instructions at pre-processing, orchestration, knowledge base response generation and post-processing. The harness gives you one system prompt. AWS's guidance is to combine the system prompt with command execution and self-managed scripts. If your agent's accuracy depends on a post-processing prompt that reformats or validates output, budget for rebuilding that as an explicit step.

Automatic parameter elicitation. The AMAZON.UserInput tool used to reprompt the user for a missing parameter without you writing anything. In the harness you define an inline function tool, the agent calls it, the harness pauses and returns tool_use to your client code, and your code handles the interaction and sends the result back. That is return-of-control, and it is more code on your side.

Multi-agent routing. The supervisor pattern survives as agent-as-tool through MCP. Routing-mode multi-agent, in AWS's own words, is "not straightforward today." Teams running a router in front of specialist agents should plan to implement that router themselves on AgentCore Runtime with a framework such as Strands, LangChain, the OpenAI Agents SDK or the Claude Agent SDK. Our comparison of production agent frameworks is a reasonable starting point for that choice.

Observability continuity. Classic's trace UI showed pre-processing, orchestration, action group calls and knowledge base queries in one view. AgentCore provides persistent end-to-end tracing, but the shape of the data changes, and dashboards and alerts built on Classic traces will need rebuilding. Teams that instrumented with vendor-neutral conventions have less to redo, which is the argument for OpenTelemetry GenAI semantic conventions over bespoke trace parsing.

India-specific considerations

Three points matter for Indian teams and for global teams running Indian workloads.

Region availability is the first. The migration guide's named region list — us-east-1, us-west-2, eu-central-1, ap-southeast-2 — has no Indian region in it. If an agent handles personal data under the Digital Personal Data Protection Act 2023 and your architecture assumed ap-south-1 residency, moving the orchestration layer to Singapore or Northern Virginia is a data-flow decision, not a deployment detail. Check the live region list before you promise anything to a compliance reviewer, and document where session memory is stored, because AgentCore Memory persists conversation events by design.

Cost sensitivity is the second. Indian engineering teams running agents for domestic products work at price points where a platform charge that global teams treat as rounding is material. At $0.0895 per vCPU-hour, an agent holding a single vCPU for eight hours a day across a 31-day month is roughly $22, about ₹1,900 at mid-2026 rates, before memory, Gateway and inference. Ten such agents is a line item someone will ask about. Meter first.

Timing is the third. Indian teams frequently provision a fresh AWS account per client engagement. Every one of those accounts created after 30 July 2026 starts life without Classic access. If your delivery playbook includes "spin up a client account and deploy the agent template," rewrite the template now rather than discovering the 403 in front of a client.

A short plan for the next ten days

Inventory first: list every AWS account and region where bedrock-agent APIs have been called in the past 12 months, and mark which accounts are allowlisted. Then classify each agent as simple (model, action groups, knowledge base) or complex (stage-specific prompts, custom orchestrator, multi-agent routing). Migrate one simple agent end to end on the harness to calibrate effort and cost against your own traffic, and only then schedule the complex ones. Update any infrastructure-as-code module that provisions AWS::Bedrock::Agent so new environments target AgentCore resources instead. Finally, set a review date for the frozen model catalog, because that is the constraint that will actually force the rest of the work.

The real cost here is usually the migration of the surrounding glue, not the agent definition.

Context on how much of this is worth doing at all: The Register reported in July 2025 that Gartner expected around 40 percent of AI agent projects to be cancelled by 2027 for lack of results. A forced platform migration is a good moment to check whether an agent is earning its keep before you pay to move it. If it is delivering, the migration is straightforward. If it is a proof of concept that never graduated, deleting it is cheaper than porting it. For patterns that have survived that test, see our write-up of enterprise AI agent use cases running in production.

FAQ

How eCorpIT can help

eCorpIT is a CMMI Level 5 certified technology consultancy in Gurugram and an AWS partner, and our senior engineering teams have been building production agent stacks on Bedrock since the original Agents API. We scope migrations the way this article does: inventory the accounts, separate the config-level agents from the ones that depend on stage-specific prompts or multi-agent routing, and model the AgentCore bill against your real session traffic before anything moves. If you want a second opinion on your exposure before 30 July, or an agent migrated end to end as a reference implementation, talk to our team.

References

1. Amazon Bedrock Agents Classic maintenance mode — Amazon Bedrock User Guide, AWS

1. AWS Summit New York 2026: New ways to make AI agents more effective at work — Swami Sivasubramanian, Vice President of Agentic AI, AWS, 17 June 2026

1. Amazon Bedrock AgentCore pricing — AWS

1. Amazon Bedrock AgentCore supported regions — AWS

1. What is Amazon Bedrock AgentCore — AWS Developer Guide

1. AgentCore managed harness documentation — AWS Developer Guide

1. Getting started with the AgentCore CLI — AWS Developer Guide

1. AWS goes full speed ahead on the AI agent train — The Register, 17 July 2025

1. AI Agents – Amazon Bedrock Agents — AWS

1. New in Amazon Bedrock AgentCore: Build agents with broader knowledge and continuous learning — AWS Machine Learning Blog

1. Top announcements of the AWS Summit in New York, 2026 — AWS News Blog

Last updated: 22 July 2026.