The part of agent work that isn’t agent work
If you run a multi-model agent on your own containers, a familiar split shows up: the orchestration logic is the interesting part, and the container lifecycle, scaling policy, identity wiring, and observability are the tax. The AWS Machine Learning Blog post published September 18, 2026 frames the problem that way — teams on self-managed infrastructure such as Amazon ECS with AWS Fargate spend more time on infrastructure than on agent logic as workloads grow.
The post’s answer is a migration walkthrough: take an existing multi-model healthcare agent and move it onto Amazon Bedrock AgentCore runtime, the managed deployment capability of AgentCore. The stated goal is to cut infrastructure management while keeping the agent’s capabilities, including triple-model orchestration and vector-enhanced knowledge retrieval.
What actually moves, and what stays
The migration is deliberately narrow. The sample agent keeps its Hugging Face smolagents logic and gains an AgentCore wrapper: BedrockAgentCoreApp initializes the app, @app.entrypoint decorates the function the runtime calls per request, and app.run() starts the server. Per the post, the agent code between the decorator and the return statement is unchanged from the standalone version.
from bedrock_agentcore.runtime import BedrockAgentCoreApp
app = BedrockAgentCoreApp()
@app.entrypoint
def healthcare_agent_entrypoint(payload):
user_input = payload.get("prompt", "")
model_type = payload.get("model_type", "sagemaker")
agent = TripleHealthcareAgent(vector_store=vector_store)
return str(agent.run(user_input, model_type=model_type))
if __name__ == "__main__":
app.run()Scaffolding runs through the AgentCore CLI: agentcore create builds the project, and agentcore add agent --type byo registers your existing code as a bring-your-own agent. One detail worth flagging: the --framework flag only picks a CLI template. The post notes the actual code uses smolagents, which runs on AgentCore regardless of that selection.
Three backends, one request shape
The agent still routes across three model backends — SageMaker AI with BioM-ELECTRA-Large-SQuAD2 for biomedical queries, Amazon Bedrock with Llama 3.1 70B Instruct for broader medical reasoning, and a containerized model server for self-hosted deployment — plus OpenSearch Service for vector retrieval. The post says all three implement Hugging Face Messages API compatibility, so request and response formats stay consistent whichever backend answers.
Model choice is explicitly an implementation decision, not a requirement. The earlier standalone version used Claude 3.5 Sonnet V2; this one uses Llama 3.1 70B Instruct, which the post offers as evidence that the runtime is model-agnostic. If you are weighing where model selection belongs in your stack, that framing echoes a question we looked at in Kimi K3 on Bedrock: where the cache breakpoint goes — the runtime is the constant, the model is a routing decision.
The tradeoff you are actually accepting
You give up direct control of deployment configuration. The post is upfront that ECS with Fargate means full control, and that managed runtimes are the option teams choose as agentic workloads evolve and scale. In exchange, AgentCore runtime handles container lifecycle, scaling, identity, and observability.
The post also carries a caveat that matters more than the architecture diagram: the solution is a sample for demonstration, and production deployments handling medical or other sensitive queries use Amazon Bedrock Guardrails for content filtering and grounding validation as a standard control. Nothing in the supplied material describes what that guardrail configuration looks like in practice.
What to check before you migrate
The prerequisites are ordinary but non-trivial: an AWS account with AgentCore runtime access, AWS CLI 2.0+, Node.js 20+ for the deployment CLI, AWS CDK, the AgentCore CLI, Python 3.10+, Docker running for code execution isolation, the bedrock-agentcore Python SDK, and access to Bedrock, SageMaker AI, and an OpenSearch Service domain in your Region. The container side is a pyproject.toml for dependencies and a Dockerfile exposing port 8080.
If your agent already separates orchestration from infrastructure concerns, the migration is mostly packaging. If it doesn’t, the decorator will not fix that for you — it just moves the boundary. The complete implementation lives in the sample-healthcare-agent-with-agentcore-on-aws GitHub repository linked from the post.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.