01
Overview
Amazon Bedrock AgentCore Runtime is designed to let teams move agent execution onto managed infrastructure without forcing the agent itself into one specific framework or model provider. AWS published a concrete migration pattern on September 18, 2026 that moves a multi-model agent from Amazon ECS with AWS Fargate to AgentCore Runtime while preserving its core orchestration logic.
This guide extracts the reusable migration pattern. The AWS reference implementation is a healthcare agent, but AWS explicitly describes the pattern as framework-agnostic and applicable beyond healthcare.
02
What changes when you migrate?
In the AWS example, the self-managed deployment is responsible for ECS task definitions, service configuration, scaling policies, IAM setup and CloudWatch observability. The AgentCore version keeps the existing agent logic but wraps its entry point with AgentCore's runtime interface.
AgentCore Runtime then manages container lifecycle, session-based scaling, identity integration and observability. That does not mean every infrastructure concern disappears: you still own application logic, permissions, dependent AWS services, networking choices and the behavior of any external model or data backend.
03
Prerequisites from AWS's current reference workflow
AWS's September 18 reference lists an AWS account with AgentCore Runtime access and required IAM permissions, AWS CLI v2+, Node.js 20+, AWS CDK, the AgentCore CLI, Python 3.10+, Docker and the bedrock-agentcore Python SDK. Your own stack may not need every service used by the healthcare sample, such as OpenSearch or SageMaker.
Treat those versions as the reference implementation's requirements, not a permanent universal minimum. Recheck the current AgentCore documentation before a production migration.
04
Step 1: wrap your existing agent entry point
The AgentCore Python integration uses BedrockAgentCoreApp, an @app.entrypoint function and app.run(). Your existing agent orchestration can live inside that entry point.
The important migration idea is that AgentCore Runtime does not require rewriting the agent around one proprietary agent framework. AWS's example uses Hugging Face smolagents even though the CLI template flag uses a supported template.
05
Step 2: create an AgentCore project
AWS's reference workflow installs the AgentCore CLI with npm and creates a project configured for a container build, Python and HTTP. It then adds the existing application as a bring-your-own agent.
Do not copy identifiers such as the sample project name into production. Choose names, network mode, model provider and code location that match your environment.
06
Step 3: containerize the agent
The sample uses a Python slim container, installs dependencies, copies the application and exposes port 8080. AWS also recommends a .dockerignore and notes a 2 GB image-size limit in this reference workflow.
Keep the container minimal. A smaller dependency surface also makes security review and deployment troubleshooting easier even though the redesigned Runtime is intended to make cold starts more consistent across image sizes.
07
Step 4: deploy with AgentCore CLI
The current AWS walkthrough deploys with agentcore deploy -y. The CLI builds the container, pushes it to Amazon ECR and creates the AgentCore Runtime agent.
AWS says its sample deployment takes approximately 10–15 minutes. That is a reference estimate for the demonstrated architecture, not a guaranteed deployment time for every project.
08
Step 5: test the deployed agent
AWS documents two paths: invoke it through the AgentCore CLI or call the runtime programmatically with boto3. Production testing should cover more than a successful hello-world response.
Test authentication and IAM boundaries, session isolation, model/backend routing, tool calls, error recovery, concurrent sessions, long-running work, logs/traces and the actual cost profile under representative traffic.
09
What stays the same?
In AWS's migration example, core agent logic, multi-model orchestration, vector retrieval and the interfaces to the model backends remain intact. The main architectural change is who operates the agent execution layer.
This is the strongest reason the migration deserves a separate search intent from a broad AgentCore overview: teams evaluating Runtime need to know how much application code must actually change.
10
AgentCore Runtime vs staying on ECS/Fargate
AWS does not claim that every workload should migrate. ECS/Fargate gives teams direct control over container configuration, networking and scaling policies. AgentCore Runtime is aimed at teams that prefer managed agent infrastructure with built-in session-oriented capabilities.
Choose based on operational requirements rather than novelty. If your team depends on specialized networking, custom scaling behavior or existing container-platform controls, test those requirements before migration.
11
Migration checklist
Before cutover, inventory the current agent's models, tools, data stores, secrets, IAM roles, network dependencies, observability and session state. Reproduce those requirements in a non-production AgentCore environment, then validate behavior under representative concurrency and long-running tasks.
Also compare total cost, not only compute price. Managed Runtime can reduce infrastructure work, but dependent AWS services and model/API usage remain part of the bill.
12
Bottom line
AWS's September 18 reference demonstrates that an existing multi-model agent can move from ECS/Fargate to AgentCore Runtime with the core orchestration preserved and a relatively small Runtime wrapper around the application entry point. The value proposition is managed container lifecycle, scaling, identity and observability rather than a new model or framework.
Use AWS's reference commands as a starting point, then verify current CLI syntax, region availability, IAM requirements, pricing and service limits before production deployment.
Sources
Primary and supporting sources
Use the linked documentation to check current pricing, access and product behaviour. The dates above describe this article; they do not guarantee that every vendor claim remains current.