AWS Is Freezing Bedrock Agents Classic on July 30. Here's Your Migration Path

Amazon Bedrock Agents shipped in November 2023 as AWS’s answer to “how do I build an AI agent without stitching together a dozen services myself.” It’s now called Bedrock Agents Classic, and as of July 30, 2026, it stops accepting new customers. If you built on it in the last two years, this is the week to figure out what that actually means for you.

What’s changing, specifically

AWS’s own documentation is clear about the scope of the change, and it’s narrower than “shut down.” Existing Bedrock Agents Classic customers can keep running what they’ve already built. What ends on July 30 is new sign-ups, and the model catalog available inside Agents Classic freezes as of that date. Any model Bedrock adds to its lineup after July 30 will be available through AgentCore, not through Agents Classic.

That second part is the one worth paying attention to even if you’re not planning to migrate immediately. A frozen model catalog means your Agents Classic deployment is functionally locked to whatever’s available today. If a new frontier model lands on Bedrock in six months and you want to route an agent to it, Agents Classic won’t be the way to do that.

Why AWS is doing this

Bedrock Agents Classic isn’t an isolated case. It’s one of roughly 20 AWS services, alongside Kendra and Amazon Q Business, that AWS recently moved into maintenance mode, closing them to new customers within a short window of each other. Read individually, each looks like a routine product lifecycle decision. Read together, it’s a consolidation: AWS spun up several overlapping ways to build AI-powered applications over the past two to three years, and it’s now steering both new and existing workloads toward a smaller, more unified stack centered on AgentCore.

That’s a reasonable strategic move for AWS. It’s also a reminder that a managed AI service launched by even the largest cloud provider isn’t guaranteed a long shelf life while the underlying agent technology is still moving this fast. Two years from initial GA to “closed to new customers” is a short product lifecycle by any normal cloud-service standard.

AgentCore: the migration target

AWS’s documented recommendation is to migrate Agents Classic workloads to Bedrock AgentCore. The AgentCore harness keeps the same basic mental model Agents Classic customers are used to: you declare a model, a set of tools, and instructions, and the platform runs the agent loop. Where it diverges is scope. AgentCore treats compute provisioning, memory, identity, and observability as first-class platform concerns rather than things you assemble separately, which is a meaningful difference if your Agents Classic setup currently leans on other AWS services glued together by hand to cover those gaps.

A basic AgentCore agent declaration looks similar in shape to what an Agents Classic customer would already recognize:

{
  "agentName": "support-triage-agent",
  "foundationModel": "anthropic.claude-opus-5",
  "instruction": "Triage incoming support tickets and route to the correct queue.",
  "actionGroups": [
    {
      "actionGroupName": "ticket-tools",
      "actionGroupExecutor": {
        "lambda": "arn:aws:lambda:us-east-1:123456789012:function:ticket-router"
      }
    }
  ],
  "memoryConfiguration": {
    "enabledMemoryTypes": ["SESSION_SUMMARY"]
  }
}

The config shape is familiar. What’s new is that memory, identity, and observability configuration live in the same declaration instead of being wired through separate services, which is worth testing against your own tool integrations before you commit to a migration timeline.

What to actually do this week

1. Inventory what’s running on Agents Classic today. Note which models each agent uses and whether any of them are candidates for an upgrade you’d want in the next 6-12 months.
2. Stand up a parallel AgentCore agent for your highest-value workload. Don’t migrate production traffic yet, just confirm your tool integrations, identity setup, and memory requirements map cleanly.
3. Check whether any planned work depends on a model not yet in the Agents Classic catalog. If it does, that work should target AgentCore from the start rather than building on a platform that won’t get the model you need.
4. Set a real migration timeline for production workloads, even if it’s 6-12 months out. “It still works” is true right up until the day it isn’t the platform anything new ships on.

This kind of platform transition is exactly the sort of infrastructure decision that’s easy to defer until it becomes urgent. If you’re weighing whether to migrate now, wait, or re-architect your agent stack entirely while you’re at it, that’s a conversation worth having with our engineering team before a frozen catalog makes the decision for you. It’s also a good moment to revisit how you’re tracking AI coding and agent output through your delivery pipeline in general, since a platform migration is as good a checkpoint as any to tighten that up.

The specific deadline here is July 30, 2026. The broader lesson holds regardless of which cloud you’re on: a managed agent platform is still a young enough category that “built two years ago” can mean “already the legacy option.” Plan your agent architecture with that turnover rate in mind, not against it.