Bedrock Agents Classic: maintenance mode and the mapping
Lesson 5 of 6 in Amazon Bedrock AgentCore, Service by Service.
If you inherited an AWS agent built before 2026, it is probably a Bedrock Agent Classic, and your first job is to read the maintenance-mode notice precisely rather than dramatically.
What AWS actually says. Amazon Bedrock Agents launched in November 2023. It is now Amazon Bedrock Agents Classic, closed to new customers starting July 30, 2026. It remains available to existing customers in maintenance mode, with no migration deadline and no planned end-of-life date — and no new features are planned. Amazon Bedrock itself, Bedrock Knowledge Bases, and Bedrock Guardrails are not affected; only the Agents Classic service is.
Read those two sentences together and you get the real engineering situation: nothing breaks on a date, and nothing improves either. Your Classic agent will keep running while the platform’s roadmap, integrations, protocol support and documentation gravity all accumulate somewhere else. That is a slow tax, not a cliff — and it should be planned like a slow tax.
Myth: “Maintenance mode means our agent stops working.”
No. It means closed to new customers and no new features. AWS states there is no planned end-of-life date and no migration deadline for existing customers. Treat migration as a roadmap decision driven by what you want next — MCP tools, A2A, per-session isolation, Cedar policy, evaluations — not by fear of a switch being thrown.
Myth: “Our Knowledge Bases and Guardrails are dead too.”
Explicitly not. The maintenance-mode page notes Bedrock, Knowledge Bases and Guardrails are unaffected. Knowledge Bases keep working unchanged, and after migration you connect them through AgentCore Gateway. Guardrails configured on a Bedrock model still apply when that model is invoked through AgentCore, with agent-level enforcement available via Gateway policies.
Myth: “Migration means rewriting the agent from scratch.”
Usually not. AWS documents two paths — the managed harness (declare model, tools and instructions; AgentCore handles compute, memory, identity and observability) and code-defined agents on AgentCore in any framework. The AgentCore CLI can import existing Classic configurations, and an amazon-bedrock skill in the AWS agent toolkit automates skill-driven migration. Most of the work is re-homing action groups as tools, not rethinking the agent.
Fact: some things genuinely do not map
The maintenance-mode page documents its own gaps, and they are the honest reason a migration can stall: stage-specific prompt overrides are not directly replicated; routing-mode multi-agent collaboration “is not straightforward today” (a supervisor pattern is achievable by exposing an agent as an MCP tool); and custom orchestrators need Runtime, not the harness. If your Classic agent leans on any of these, scope the migration around them first rather than discovering them in week three.
| Bedrock Agents Classic | AgentCore equivalent | What actually changes for you |
|---|---|---|
Managed orchestration loop | AgentCore harness | Still config-based: declare model, tools, instructions. |
Action groups (OpenAPI or function schema + Lambda) | MCP tools via AgentCore Gateway, or code-level | Your Lambda stays; it becomes a Gateway target published as an MCP tool. Other agents — and other frameworks — can now use it too. |
Knowledge Base association | Gateway-fronted KB integration or a retrieval tool | The Knowledge Base is unchanged. Retrieval becomes an explicit tool the model chooses, which is more visible and more evaluable. |
| AgentCore Code Interpreter | A separately addressable service with network modes, file limits and CloudTrail logging — usable from agents that are not on AgentCore at all. |
Session and memory configuration | AgentCore Memory strategies | The big conceptual change: you now choose short-term versus long-term, and configure strategies for extraction. More power, more design work. |
Guardrails / policy on the agent | Bedrock Guardrails plus policy enforcement on AgentCore Gateway | Enforcement splits into two placements: model-level filtering, and deterministic Cedar authorization on every tool call. |
Return of control | Inline function tools | The human-in-the-loop hand-back becomes an ordinary tool your own code implements — less magic, more control over the approval gate. |
Harness or code-defined? Pick your migration target
Interactive decision tree — outcomes:
- Managed harness — the recommended target
Declare model, tools and instructions; AgentCore handles compute, memory, identity and observability. Closest in spirit to Classic, least code. The CLI can import your existing Classic configuration, and the harness can export to Strands code later if you outgrow config.
- Code-defined agent on Runtime
Custom orchestrators need Runtime, not the harness. Bring Strands, LangGraph, the OpenAI Agents SDK, the Claude Agent SDK or your own code, containerise it, and keep the orchestration you already trust while gaining session isolation, Memory, Gateway and Observability.
- Code-defined, supervisor pattern
Achievable by exposing each specialist agent as an MCP tool the supervisor can call — Gateway makes this natural. Budget design time: what was a checkbox in Classic is now an architecture you own (and can therefore inspect and evaluate).
- Documented gap — scope this first
AWS states routing-mode multi-agent collaboration is not straightforward today. Do not assume parity: prototype the routing behaviour on AgentCore before committing to a migration date, and re-read the maintenance-mode page — this is exactly the kind of gap that closes over time.
- Documented gap — stage-specific prompt overrides
These are not directly replicated. Extract what the overrides were really doing — usually input shaping, tool gating, or output formatting — and re-express it as instructions, an inline tool, or a code-defined agent step. Migrating the intent works; migrating the mechanism does not.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.