Amazon Bedrock AgentCore vs Bedrock Agents Classic: Migration Questions

Evidence check: 25 October 2026. Product details reflect the referenced documentation observed at this cutoff; exact plans, prices, regional eligibility and unverified release dates are not claimed. This is an editorial guide, not a hands-on test.

Two service families, different responsibilities

Bedrock Agents Classic describes a managed orchestration sequence with knowledge bases and action groups. AWS documentation states that Classic is no longer open to new customers while existing customers may continue using it. AgentCore is presented as modular agent infrastructure including runtime, memory, identity, tools, browser execution and observability. A team evaluating new projects should verify current eligibility and feature status, not assume that an old Agents console tutorial applies to a new deployment.

Architecture with AgentCore

A runtime hosts code and manages session isolation, while tool gateways and identity controls determine which systems the agent can reach. The official overview documents multiple framework integrations. These components still require configuration: isolation does not automatically prove your secrets are safe, your user permission checks are correct or every region supports the same service options.

Action approval pattern

Classic Agents documentation describes a return-control option for action groups. Rather than automatically calling a function, the service can return proposed invocation inputs to the developer, who then invokes a service and feeds the result back. This separation offers a natural place for an application-level human approval policy. Implementations should retain the exact proposal and verify authorization before making a consequential external call.

Browser execution risks

AgentCore Browser supplies a managed browser session, not authority to click through every connected system. Restrict the session’s IAM role and network access, set timeouts and require confirmation before destructive or sensitive interactions. Verify result state through the application, not through an assistant’s final prose.

Migration and procurement

Inventory existing agents, versions, aliases, knowledge-base associations and action-group integrations. Compare operational semantics and rollback options before choosing a new architecture. Check service region availability, entitlement, model-provider terms, storage and variable runtime charges in official AWS pages near procurement; this profile intentionally avoids numerical pricing.

Alternatives

LangGraph or Google ADK can define orchestration while AgentCore provides selected runtime services. Conventional serverless functions may be enough for workflows without dynamic planning. Avoid rebuilding a stable integration solely because a platform uses the word “agent.”

Split runtime decisions from agent design

A hosted runtime, identity service, browser and memory layer solve different needs. Document which services your application would actually adopt and whether an agent framework lives above them. For example, a read-only document assistant may not need any browser capability. A browser-based procurement workflow should require explicit role scoping, bounded sessions, user review and reconciliation of external state.

Safe migration sequence

First capture current Classic agent behavior, action group schemas, session handling and knowledge-base references. Reproduce those expectations in isolated tests and confirm the new identity boundary before switching traffic. Add telemetry and resource-budget enforcement, then compare outcome correctness and p95 latency. Migrate incrementally rather than treating a platform announcement as proof of feature parity. AWS regional access, runtime billing and particular identity integrations vary; verify each with a dated source before production selection. Do not migrate old conversation data without checking its retention and consent requirements.