If you are currently using something like LangGraph to build customer support agents, you probably own the entire stack—the container, the web server, and the conversation state. Even if your model calls are already going to Amazon Bedrock, you're still stuck managing the operational overhead. I've been looking into how to migrate these agentic workloads to Amazon Bedrock AgentCore, and it basically breaks down into a two-stage deployment strategy to offload that "plumbing" work.
The Operational Burden #
When you build an agent from scratch, you aren't just writing logic; you are managing a massive list of operational tasks. The transition from a manual setup to a managed one involves mapping your existing code to specific AgentCore features.
Here is how the core components shift during a migration:
Execution Environment: Instead of managingbuild_graph(...)
inside a custom container and web server, you move to theAgentCore Runtime. This usesBedrockAgentCoreApp
and an@app.entrypoint
function, running each session on its own microVM to ensure isolation.Tool Management: Instead of using@tool
functions bound withToolNode
orllm.bind_tools
, you leverage theAgentCore Gateway. You can publish tools as Model Context Protocol (MCP) tools (e.g.,supportTools___name
) that target AWS Lambda.State Persistence: You swap outMemorySaver()
and manualthread_id
management forAgentCore Memory. This uses anAgentCoreMemorySessionManager
where state is automatically keyed byactor_id
and the session.
A Step-by-Step Migration Path #
The migration doesn't have to happen all at once. You can treat it as an incremental upgrade to your AI workflow.
Stage 1: Transition to Managed Runtime and Memory
In this stage, you keep your existing graph logic exactly as it is. You aren't rewriting how the agent "thinks"; you are just changing where it "lives." By moving to the AgentCore Runtime, Gateway, and Memory, you get a hosted agent with managed tools and durable state without touching your core reasoning logic.
Stage 2: Rebuilding with Model-Driven Planning
Once the infrastructure is stable, you can rebuild the loop using Strands Agents. This moves you away from hard-coded conditional edges and toward model-driven planning. You replace your manual graph transitions with a more flexible loop where the model decides the next step based on the tools available via
MCPClient.list_tools_sync()
.### Stage 3: The AgentCore Harness
The final step is handing the entire loop over to an AgentCore harness. This is the most automated level, where the orchestration is handled by the service rather than your custom code.
If you're worried about security during this move, you should also integrate Amazon Bedrock Guardrails. This allows you to filter harmful content and, more importantly, validate grounding against your source documents to prevent hallucinations or prompt injection attempts before they hit your backend.
[The harness matters more than the model weights now 12d ago](/en/news/7294/)
[Multi-agent systems are hitting a wall with coordination overhead 18d ago](/en/news/6556/)
Strands Agents and LeRobot make robotics deployment way easier 19d ago
Multi-agent systems are hitting a wall where simple prompting 21d ago Google engineers are admitting their own HR filters can't be 23d ago
[AI Agent Governance: A Deep Dive into Guardrail Management 28d ago](/en/news/5275/)
[Next ChatGPT, Grok & Claude: Triple AI Outage Across Platforms →](/en/news/8722/)
[an AI side-hustle playbook](https://tanyan888.com/), with plenty of directly applicable cases.