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.

Change	Effective 30 July 2026	Practical impact
New-customer access	CreateAgent and InvokeInlineAgent restricted to allowlisted accounts	New accounts receive AccessDeniedException (HTTP 403); no exception process exists
Existing agents	Unaffected	UpdateAgent, GetAgent, ListAgents, DeleteAgent, PrepareAgent, InvokeAgent, action group, knowledge base and alias APIs all remain available
Model catalog	Frozen inside Classic	Models released after 30 July 2026 are available only through AgentCore; Bedrock inference itself keeps getting new models
Pricing	No change	There is no charge for Classic itself; you pay for model inference, Knowledge Bases and Lambda invocations as before
Naming	Bedrock Agents becomes Bedrock Agents Classic	API namespace bedrock-agent, SDK clients, CloudFormation resource types and IAM action prefixes are unchanged
Knowledge Bases and Guardrails	Unaffected	Both continue to work and are not part of maintenance mode

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.

Bedrock Agents Classic feature	AgentCore equivalent	Migration effort
Managed orchestration loop	Supported out of the box in the harness	Low: declare model, tools, instructions
Action groups via OpenAPI or function schema plus Lambda executor	Tools exposed through AgentCore Gateway as MCP tools wrapping REST APIs and Lambda, or code-level @tools	Medium: redeploy action groups behind Gateway
Knowledge Base attached to agent config	Gateway-fronted knowledge base integration, or a code-level retrieval tool	Low to medium: the Knowledge Base resource itself is unchanged
Stage-specific prompt overrides (pre-processing, orchestration, KB response generation, post-processing)	Not directly replicated; only a single --system-prompt on the harness	High: requires combining the system prompt with command execution and self-managed scripts
AMAZON.UserInput automatic reprompting and parameter elicitation	Inline function tools; the harness pauses and returns tool_use to client code	Medium: you must define the tool explicitly and handle the round trip yourself
Multi-agent collaboration with supervisor roles and routing	Agent-as-tool pattern via MCP; routing-mode multi-agent is "not straightforward today"	High: full collaboration needs custom framework code on AgentCore Runtime
Custom orchestrator	Supported on AgentCore Runtime, not through the harness	Medium: you leave the managed path
AMAZON.CodeInterpreter action group	AgentCore Code Interpreter	Low
Session and memory config (idle TTL, memory types, cross-session memory)	AgentCore Memory, short-term and long-term with configurable strategies	Low to medium
Guardrails attached declaratively to the agent	Guardrail configuration in Bedrock, enforced through AgentCore Gateway policy	Low
Trace UI and APIs across pre-processing, orchestration, action groups and KB queries	Persistent end-to-end tracing of all agent actions	Low

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.

AgentCore component	Published rate (July 2026)	What drives it
Runtime, Browser tool, Code Interpreter	$0.0895 per vCPU-hour and $0.00945 per GB-hour	Active resource use only; idle time waiting on model responses or tool calls does not accrue CPU charges
Gateway tool invocations	$0.005 per 1,000 invocations	Every action group call that now routes through Gateway
Gateway tool indexing	$0.02 per 100 tools indexed per month	Tool catalogue size, not traffic
Identity	$0.010 per 1,000 tokens or API keys requested by the agent	Credential fetches per session
Memory (short-term)	$0.25 per 1,000 new events	Conversation turns written to memory
Memory retrieval	$0.50 per 1,000 memory record retrievals	Every long-term memory lookup
Evaluations	$1.50 per 1,000 evaluations	Automated scoring runs, model usage billed separately

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

Does Bedrock Agents Classic stop working on 30 July 2026?

No. AWS states that existing agents continue to function normally and that all APIs, including UpdateAgent, GetAgent, InvokeAgent and the action group and knowledge base APIs, remain available. Only CreateAgent and InvokeInlineAgent become restricted, and only for accounts without prior service usage in the previous 12 months.

How do I know whether my AWS account is allowlisted?

The allowlist is applied automatically per account, based on whether that account called CreateAgent or InvokeInlineAgent in the past 12 months. Multi-account organisations will find some accounts allowlisted and others not. Accounts without prior usage receive an AccessDeniedException with HTTP status 403 when they attempt agent creation.

Is there a deadline to migrate off Bedrock Agents Classic?

No. AWS says Classic remains available to existing customers in maintenance mode with no planned end-of-life date. The practical pressure comes from the frozen model catalog: models released after 30 July 2026 are reachable only through AgentCore, so a Classic agent cannot adopt newer models over time.

What happens to my Bedrock Knowledge Bases and Guardrails?

Both are unaffected by maintenance mode and continue to work. When migrating, you connect a Knowledge Base through AgentCore Gateway or a code-level retrieval tool, and the underlying resource stays unchanged. Guardrails configured on the Bedrock model still apply, with agent-level enforcement handled through AgentCore Gateway policies.

Will my CloudFormation or Terraform templates break?

Existing templates that create or manage Bedrock Agents keep working in allowlisted accounts, and the API namespace, SDK clients, CloudFormation resource types and IAM action prefixes are unchanged. Templates applied to new accounts without prior usage will fail, so provisioning modules should target AgentCore resources instead.

Which AgentCore path replaces the Classic experience most closely?

The managed harness. You declare the model, tools and instructions, and AgentCore handles compute, environment, memory, identity and observability. AWS recommends the harness unless you have an existing agent codebase to migrate or need orchestration the harness cannot express, in which case you deploy code-defined agents on AgentCore Runtime.

How much does AgentCore cost compared with Classic?

Classic carried no charge of its own; you paid for model inference and associated resources. AgentCore uses consumption pricing, with Runtime listed at $0.0895 per vCPU-hour and $0.00945 per GB-hour in July 2026, plus Gateway, Memory and Identity charges. AWS argues harness prompts are more token-efficient, which may offset some inference cost.

Can AgentCore use models from providers other than AWS?

Yes. AgentCore supports the full Amazon Bedrock model catalog plus additional providers including OpenAI and Gemini, and any OpenAI-compatible endpoint. AWS states that you can switch between model providers mid-session without redeploying, and the harness accepts a model override on an individual invocation through the CLI.

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
2. 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
3. Amazon Bedrock AgentCore pricing — AWS
4. Amazon Bedrock AgentCore supported regions — AWS
5. What is Amazon Bedrock AgentCore — AWS Developer Guide
6. AgentCore managed harness documentation — AWS Developer Guide
7. Getting started with the AgentCore CLI — AWS Developer Guide
8. AWS goes full speed ahead on the AI agent train — The Register, 17 July 2025
9. AI Agents – Amazon Bedrock Agents — AWS
10. New in Amazon Bedrock AgentCore: Build agents with broader knowledge and continuous learning — AWS Machine Learning Blog
11. Top announcements of the AWS Summit in New York, 2026 — AWS News Blog

Last updated: 22 July 2026.

Comments

[Raju Dandigam]

The distinction between "not an EOL" and "still a real planning deadline" is the useful part here. Teams with multi-account AWS setups are absolutely going to get surprised if they assume allowlisting is effectively global. I also like that you called out model-catalog freeze as the real clock, because reliability and tool-calling behavior usually move before official service retirement does. This feels like the kind of change that deserves a per-account smoke check in CI or Terraform policy, not just a migration doc.