Bedrock Agents Classic and moving to AgentCore

Bedrock Agents Classic and moving to AgentCore

Amazon Bedrock Agents let you build an agent in the cloud console: you pointed at a model, described actions calling your functions, attached a knowledge base, and received a working assistant with no loop to write.

That service is today called Amazon Bedrock Agents Classic and accepts no new customers. Existing ones may continue using it, and for new deployments the vendor directs you to Amazon Bedrock AgentCore.

That is the most important fact in this text, so if you are looking for where to start building an agent on this cloud, the answer is: not with this product.

What maintenance mode actually means

Worth breaking apart, since the phrase sounds alarming and needs precision.

The service runs. Agents already built answer, call actions, and reach knowledge bases as before. Nobody is switching anything off overnight, and the vendor commits to continuing support for existing customers.

New accounts cannot be onboarded as of 30 July 2026, though, so when starting a project in a fresh environment that route is closed regardless of how well it fits.

Access is decided per individual account. An account with activity in the service over the past twelve months was allowlisted and keeps working, while the rest receive a permission denial when creating an agent, with no exception process. The block covers agent creation alone, since the remaining interface calls were left untouched.

What will not come: new features. The product stopped where it stood, and development moved elsewhere. That covers the model catalogue too, frozen on the day maintenance mode took effect: models released later are available in the successor and no longer here. For a tool whose value depends on keeping pace with models and protocols, that is a real factor.

The practical conclusion for current users is calm: the vendor has set neither a wind down date nor a migration deadline, and the bill does not change, since the agent layer itself was never charged for. The pressure therefore comes not from a deadline but from the frozen model catalogue, and that is what marks the point where migration stops being optional.

What this product was

Worth describing, since its concepts carry over to the successor and help explain the difference.

An agent consisted of several elements. An action group described what the agent could do, by naming an interface schema and the function serving it. A knowledge base attached a document collection the agent could draw answers from. Prompt templates let you change behaviour at four stages: preprocessing, orchestration, knowledge base response generation, and post processing.

Deployment happened through versions and aliases. You tested the agent on a test alias, then created a version and a production alias, and the application called the alias rather than the agent itself. That arrangement was good and deserves noting, since it gives deployments with rollback without changing application code.

The whole thing's advantage was that you wrote no loop. The vendor handled breaking a task into steps, calling functions, memory, and encryption, while you described what the agent should be able to do.

Its drawback was the same thing from the other side. The flow's shape was fixed, and going beyond it required working around the service or abandoning it. That is in fact why the successor looks different.

AgentCore, the successor

The new service became generally available in October 2025 and is built on a different principle.

Instead of one product assembling an agent for you, you receive a set of composable services: a managed agent loop, a runtime, a gateway to tools, memory, a browser, code execution, identity, observability, access policy, quality evaluation, optimisation, payments, and a resource catalogue. Each can be used alone or together with the rest, and the list grows from quarter to quarter.

The philosophical shift is clear, though it does not consist of taking the ready made loop away. The predecessor said: describe an agent and we will run it. The successor offers two routes: configure an agent inside a managed loop, or write it yourself, with the same infrastructure around it either way.

That managed loop, generally available since June 2026, is the closest analogue to the old service and the vendor points at it as the default migration path. You declare a model, an instruction, and tools, and the service runs the orchestration, calls the tools, minds the context window, persists state across turns, and isolates sessions. An old agent's configuration can be imported with a command line call rather than retyped.

Three elements deserve knowing, since they solve problems that are expensive to handle yourself.

The runtime provides sessions lasting up to eight hours with full isolation between them. That differs from ordinary serverless functions, where an execution time limit ends a long task halfway.

The gateway turns existing interfaces and functions into tools available to an agent, and connects to servers speaking the protocol described in the MCP registry. That saves writing an intermediary layer for every system separately.

Memory provides a durable layer with control over how facts get extracted and consolidated, which in a self built implementation is several days of work.

What that means for your code

The practical difference reduces to one question: who writes the agent loop.

In the predecessor you wrote none. In the successor you choose: the managed loop still writes it for you, and when you need something beyond it you write it yourself or use a ready set, Strands Agents from the same vendor or LangChain agents for instance, while the services supply the infrastructure around it.

The split is simple. An agent that fitted the shape the predecessor imposed moves onto the managed loop and stays a configuration. An agent that did not fit and was worked around moves onto your own code: more work at the start, and migration removes the workarounds. The boundary runs at stage specific prompt overrides and at multi agent collaboration, since the managed loop does not reproduce those directly.

Note too that the new approach binds you to no particular agent toolkit. The runtime accepts code, so you can run an agent written with any library, or even your own loop.

The price is more pieces to understand. A dozen or so composable services give flexibility and require decisions you did not previously have to make.

What the successor is made of

Since the successor is a composable set, it pays to know what you actually receive, because half of it is usually unnecessary at the start. Below are the parts you begin with in practice; the rest of the catalogue, such as access policy, quality evaluation, or agent payments, comes later.

The managed loop takes orchestration off your hands. You supply a model, an instruction, and a tool list, while execution, memory handling, and session isolation happen on the service's side. Every session receives its own virtual machine with a filesystem and a shell, so tasks that require running something rather than merely answering fit inside it.

The runtime is where your agent code executes. Its value lies in session length and isolation: every conversation gets its own isolated environment, so one user's data cannot reach another through shared process state.

The gateway turns what you already have into tools for an agent. Instead of writing a wrapper per interface, you point at a schema or a function and the gateway exposes it in a form the agent understands.

Memory handles conversation threads and facts held longer. The self managed variant lets you define how facts get extracted and consolidated, which matters in a domain where general rules fail.

The browser and code execution give an agent the ability to click through pages and run computations in an isolated environment. Those are needed for research and analysis tasks and unnecessary for an assistant answering from a knowledge base.

Identity handles on whose behalf the agent acts and stores refresh tokens in a vault. That is the part most often done badly in a self built deployment, since it looks like a detail while concerning permissions.

Observability closes the list and is what makes the rest legible. Traces showing what went to the model and which tool was called are the precondition for diagnosing anything.

Practical advice: start with the managed loop, or with the runtime plus observability, and add the rest when a need appears. Taking the whole catalogue at once gives you a dozen things to configure before a first answer.

Costs and what counts differently

The billing model changes along with the architecture, and it deserves computing before migrating.

In the old service you paid mainly for model calls, since orchestration was included. In the new one you pay separately for runtime execution time, for model calls, and for whichever services you use.

The consequence is that long sessions now carry a price. An agent waiting half an hour for a user's reply cost nothing during that time in the old model and holds resources in the new. Check whether your case assumes continuous conversations or answers to single questions, since the difference in the bill can be substantial.

The second factor is the agent's step count. That one is common to both approaches and usually dominates: a run with six tool calls is six model calls of rising cost, since context accumulates with every step.

The third is memory. Extracting facts from a conversation requires model calls, so cost grows with the number of events recorded rather than questions asked. That is where deciding what reaches memory affects the bill more than choosing a service.

Price one real run before deciding, since the cost distribution usually surprises and rarely looks like what the team assumed.

Bedrock Agents against the alternatives

Treat the first row purely as a description of the current state rather than an option. No new deployment will happen there, and existing ones run with no announced end date, only with a frozen model catalogue.

The second and third rows do not exclude each other, since they sit at different levels: one is infrastructure, the other a library for writing the agent you run on that infrastructure. Confusing them is a common misunderstanding when reading vendor material.

The fourth row is a choice on a different axis. An agent written with a library not tied to a cloud vendor can move elsewhere, at the price of providing yourself what the services supply: session isolation, durable memory, and identity.

How to plan the move

An order that limits risk when you hold a running agent in the old service.

Start with an inventory of what it actually does. List the action groups with their schemas, the attached knowledge bases, and every place where you modified prompt templates. That last one gets skipped most often, and it is precisely where behaviour nobody remembers tuning resides.

Then reproduce the agent inside the successor. Check first whether it fits the managed loop, since a configuration plus importing the old settings with the vendor's command then suffices, and reach for your own code with a chosen library only when the answer is no. Compare results across the same query set. A few dozen real questions with answers suffices to see the differences, and differences there will be, since the old service's orchestration prompts are its own.

The third step is infrastructure. Knowledge bases work independently of the agent, so they usually need no reproducing. Memory, session isolation, and identity were included in the old service and now have to be chosen deliberately.

The fourth is running in parallel. The old agent serves traffic, the new one receives a copy of the same queries without answering users, and you compare. The switch follows a week with no surprises.

Move safeguards deliberately too, since they form a separate layer. Content filters and rule verification, described in the text on Bedrock Guardrails, can be invoked regardless of where the agent runs.

Common mistakes

The first is starting a new project with this service. It accepts no new customers, so time spent reading its documentation is wasted.

The second is relying on tutorials without checking their date. Material describing agent building in this service as the current approach predates the change and misleads.

The third is assuming the new service requires writing the loop yourself. The managed loop accepts an agent described by configuration, and action groups correspond there to tools exposed through the gateway, so the old question about describing actions does have an answer, just in a different place.

The fourth is migrating without comparing results. The old service's orchestration prompts are its own, so a reproduced agent behaves differently, and without a test set you will see that only from reports.

The fifth is skipping modified prompt templates during the inventory. That is usually where tuned behaviour the team forgot about resides.

The sixth is deferring migration with no deadline. The absence of a public wind down date does not mean there will be none, and moving an agent under pressure costs more than doing it deliberately.

FAQ

Does Bedrock Agents still work?

Yes, under the name Amazon Bedrock Agents Classic and in maintenance mode. Existing customers may continue, while as of 30 July 2026 the service accepts no new ones and receives neither new features nor new models, and the vendor directs new deployments to AgentCore.

What is AgentCore?

A set of composable services for building and running agents: a managed agent loop, a runtime with long sessions, a gateway turning interfaces into tools, memory, identity, and observability. It became generally available in October 2025, and the managed loop in June 2026.

Do I have to migrate immediately?

No public wind down date and no migration deadline exist, so haste is unnecessary. The sensible route is planning the migration for a quarter with room, running in parallel and comparing results, rather than moving under deadline pressure.

How does AgentCore differ from Strands Agents?

In level. AgentCore is infrastructure: running, memory, identity, tools, and a managed loop for agents described by configuration. Strands Agents is a library for writing the agent itself, which you run on that infrastructure. They do not compete but complement each other.

What about knowledge bases?

They work independently of the agent, so migration usually requires no reproducing them. That is the part that transfers most easily, unlike action groups and modified prompt templates.

The maintenance mode notice sits in the service documentation, and the successor in the AgentCore documentation.