Execution risk · Agent runtimes

Your agent runtime was deprecated without a deadline.

AWS moved Bedrock Agents into maintenance mode on July 30 and froze its model catalog. Existing agents keep answering. Nothing breaks, so nothing escalates. That is the exposure.

Field briefing · HB-2026-0019 The Hikari Blue team · Operator notes from Austin 5 min read

On July 30, Amazon Web Services moved its first agent runtime into maintenance mode. Nothing broke. That is the part worth your attention.

The notice reads as a rename. Amazon Bedrock Agents, launched in November 2023, is now Amazon Bedrock Agents Classic, and the service is closed to new customers (AWS, July 30, 2026). Existing agents keep running. Every management API stays available. AWS states plainly that there is no migration deadline and no planned end-of-life date.

Read one line further. Question in the same notice: will new model versions be available in Bedrock Agents Classic? Answer: no. The model catalog available in Classic is frozen as of July 30, 2026. New models released after that date reach you only through the successor platform, AgentCore.

The clock nobody started

Put the dates in a row. Bedrock Agents launched in November 2023. AgentCore entered preview on July 16, 2025 (AWS, 2025). It reached general availability on October 13, 2025 (AWS, 2025). Classic went to maintenance mode on July 30, 2026.

Thirty-two months from launch to a frozen catalog. The replacement was generally available before the original turned two.

This is not a complaint about AWS. The successor is a better platform, the migration guidance is unusually detailed, and freezing a first-generation orchestration layer after shipping a second is ordinary product discipline. The problem sits on the customer side of the line.

An agent runtime that stops receiving models does not fail. It falls behind. The decay arrives as competitive drift, and drift has no incident number. Hikari Blue · operator note

Three exposures your risk register does not carry

First, a capability freeze that never pages anyone. Your agents keep answering. They answer with the model catalog of July 2026, permanently. Every model your organization adopts after that date lands somewhere else in the estate. The gap between what your agents can do and what your stack can do widens each quarter, and no monitor fires. Outages get escalated. Standing still does not.

Second, an account trap that punishes good segregation. The allowlist is granted per AWS account, based on Bedrock Agents activity in the trailing twelve months. Regulated firms run segregated account estates on purpose, to contain blast radius and separate duties. A firm with agents in three accounts that stands up a fresh production account in September receives an AccessDeniedException on agent creation. AWS confirms there is no exception process. The account discipline your regulator expects is what closes the deployment path.

Third, a migration that is lift-and-shift only where it does not matter. AWS documents the gaps itself. Stage-specific prompt overrides are not directly replicated. Multi-agent routing is described as not straightforward today. Simple agents move in hours. The sophisticated deployments, which is what a bank or an insurer actually builds, need engineering work that nobody has scheduled.

What survives a runtime change

The instructive detail is what the successor kept. AgentCore exposes action groups as tools through its gateway using the Model Context Protocol. MCP published specification version 2026-07-28 two days before the freeze, with a stateless core and per-request capability negotiation (Model Context Protocol, 2026).

That draws the line cleanly. Tool contracts, traces, policies and memory are portable across runtimes. The orchestration loop is not. An enterprise that encoded its agent behaviour inside a vendor's managed loop re-buys that work at every platform change. An enterprise that held the contract outside the runtime changes a target and keeps the asset.

This is the argument for a model-agnostic architecture stated in operating terms, not procurement terms. You rent the loop. You own the contract and the trace.

The governance framing already exists

None of this requires a new control. The NIST AI Risk Management Framework asks that risks and benefits from third-party resources be monitored on a regular basis, with controls applied and documented, and it directs organizations to decommission third-party systems that exceed risk tolerances (NIST AI RMF, MANAGE 3.1).

Most registers interpret that as a test for things that break. A frozen orchestration layer is a third-party dependency that keeps working while it stops improving. It exceeds a risk tolerance quietly, and it does so on a timeline the vendor has explicitly declined to set.

What to examine this month

Three questions, all answerable without a program.

  • Which agent workloads run on a runtime whose model catalog is now frozen, and what business process depends on each.
  • Which accounts in the estate hold the allowlist and which do not. This is a query against twelve months of activity, not a project.
  • Whether tool definitions, traces and policies live inside the runtime or outside it. That answer sets the cost of the next migration, and there will be a next one.

Track one number: the release date of the newest model your production agents can actually call. If that date stops moving while the rest of your stack advances, you are measuring drift.

The question to bring to the next executive session

Which of our agents cannot call the model we adopted last quarter, and who was supposed to notice?

A deprecation with a deadline organizes itself. Someone owns the date, the budget appears, the work ships. A deprecation without one waits for a person to raise their hand.

Sources

The Hikari Blue team · Austin, August 2026

More from the Newsroom

See all articles in the Newsroom →

Find the runtimes that stopped improving.

Thirty minutes with an operator. No slides.

Direct call with one of the partners. We listen, we structure, and we tell you what a portable agent layer (tool contracts, traces, policies held outside the vendor loop) would look like for your specific stack and regulatory perimeter.

Book a 30-minute working session