We moved a LangGraph‑based customer‑support agent from a self‑hosted container to Amazon Bedrock AgentCore services. The change replaces the custom compute, web server, and in‑process state handling with Bedrock AgentCore Runtime, Gateway, and Memory while keeping the original graph logic intact.
What Changed
The migration consists of three defined stages. Stage 1 swaps the container and web server for a BedrockAgentCoreApp running on a microVM per session, registers tool functions as Model Context Protocol (MCP) tools via an AWS Lambda target (Gateway), and stores conversation state in AgentCore Memory keyed by actor_id. The LangGraph graph itself is unchanged. Stage 2 rewrites the control flow to use model‑driven planning on Strands Agents, replacing the explicit conditional edge logic. Stage 3 hands the execution loop to an AgentCore harness, a built‑in capability that abstracts the loop entirely.
Why It Matters to Practitioners
For AI engineers and platform teams the shift removes the need to patch operating systems, manage auto‑scaling policies, and isolate user sessions manually. DevOps and SRE staff gain a managed compute surface that scales per session and runs on AWS‑managed infrastructure. Security engineers see tool authentication moved into Gateway, where IAM execution roles control each tool call, and they can optionally add Bedrock Guardrails for content filtering, grounding validation, and prompt‑injection protection.
Architecture and Implementation Implications
- Runtime: Deploy the agent as a
BedrockAgentCoreAppwith an@app.entrypointfunction. Each session runs on its own microVM, eliminating shared OS concerns. - Gateway: Convert each
@toolfunction into an MCP‑named Lambda (e.g.,supportTools___lookupOrder). The agent signs calls with Signature V4; the Lambda executes under its own role, enforcing per‑tool IAM policies. - Memory: Replace
MemorySaver()withAgentCoreMemorySessionManagerconfigured viaAgentCoreMemoryConfig. State persists across turns, processes, and days without custom storage. - Guardrails: Optional layer that can be attached at any stage to filter harmful output, verify grounding against source documents, and block prompt‑injection attempts.
Operational and Security Considerations
While Bedrock AgentCore assumes responsibility for compute, patching, and session isolation, several responsibilities remain with the operator:
- IAM policy design for the Gateway Lambda and for any downstream services the agent calls.
- VPC design and any required private connectivity if the Lambda must reach internal resources.
- Web Application Firewall (WAF) rules and edge protection for the entry point.
- Secrets rotation for any credentials the agent uses beyond the built‑in IAM role.
- Dependency updates, which only become relevant at Stage 3 when the harness abstracts the loop.
Observability is automatically routed to Amazon CloudWatch; no additional configuration is required to collect logs, metrics, or traces.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Adopting Bedrock AgentCore at Stage 1 gives immediate relief from infrastructure maintenance while preserving existing business logic. Teams should prototype the Runtime, Gateway, and Memory components, validate IAM boundaries for each tool, and enable Guardrails to address content‑related risks. After confirming stability, evaluate Stage 2 to simplify control flow with model‑driven planning, and consider Stage 3 only when the harness’s abstraction aligns with long‑term roadmap goals.
