Amazon Bedrock Agents launched in November 2023. AWS now identifies that orchestration service as Bedrock Agents Classic and states it has not been open to new customers since 30 July 2026. Existing allowlisted accounts continue to use it in maintenance mode. This is a product-lifecycle decision, not a shutdown of Amazon Bedrock models, Knowledge Bases or Guardrails. A new buyer must not mistake historical tutorials for a presently available onboarding path.
How the architecture works
Classic uses a selected foundation model, agent instructions, knowledge bases and action groups. Action groups describe callable APIs and can rely on Lambda or return control to the calling application. The service runs pre-processing and an orchestration loop through the InvokeAgent API, with optional tracing. The new-customer cutoff pertains to the managed Classic orchestration service. AWS recommends AgentCore for new development and describes both managed harness and code-defined runtime paths as possible migration destinations.
A controlled, practical example
For an existing Classic travel-request agent, first inventory agent aliases, action group API schemas, attached knowledge bases, prompts, IAM roles and external Lambda side effects. Freeze a regression set before deciding whether to migrate. Rebuild one read-only lookup action and one approval-gated booking request in the destination architecture. Do not blindly transfer write permissions: assess agent, tool and reviewer identities independently. Compare old and new responses using the same fixed questions and mock reservation data.
Permissions, approvals and trust boundaries
Classic accounts that meet AWS prior-usage criteria may continue use; new accounts can receive access denied when creating a Classic agent. The availability of InvokeAgent for an existing account does not authorize agent writes to customer systems. Keep action groups scoped, audit exact parameters and ensure a proposed booking cannot be applied without authorization. Where Lambda executes a mutating call, provide an idempotency key and independently validate the requestor.
Limits and version caveats
AWS states there is no planned Classic end-of-life date for existing customers, but no new features or model additions to the frozen Classic catalog are promised. Maintenance mode is not general availability for newcomers. A migration can change prompts, tool-call count and state behavior, and AgentCore is not a drop-in compatibility layer. Region support and metering for individual AgentCore features must be checked separately; this article supplies no price or unsupported rollout list.
Where it fits and what to use instead
If starting a new workload, do not design around Classic onboarding. Review AgentCore, a custom framework running on supported infrastructure or ordinary application workflows. If maintaining an existing Classic agent, consider whether the operational risk of migration is smaller than the cost of supporting an aging workflow; document migration and rollback plans instead of inventing a deadline.
How to validate before deployment
Prove that the original account remains allowlisted, check all templates referencing Classic creation APIs, and test migration in a different nonproduction account where possible. Validate knowledge-base evidence fidelity, action behavior, observability, rejected approvals, rate limits and duplicate delivery. Keep a source manifest showing the effective cutoff date. Never promote this article without rereading the AWS maintenance notice.
Version, tier and region applicability
The source links below describe specific capabilities or dated announcements; documentation may change afterward. Where no exact release version, eligible market, service region, contract plan or numeric quota is substantiated, those facts are unknown and are not inferred. This article is a researched implementation guide, not a record of hands-on testing, a license grant, a benchmark, or a current price quote. Independently recheck current product access and commercial terms before deployment.