Bedrock AgentCore: agents in production on AWS

The AgentCore Runtime is the agent's execution environment — serverless, isolated per session. Each session gets its own sandbox: no shared state between users, no containers to manage or manual scaling. You bring your agent code (any framework: LangGraph, Strands Agents, plain code) and the Runtime handles the lifecycle.

The AgentCore Gateway is what connects the model to the outside world using the MCP protocol from lesson 14. Instead of building an MCP server from scratch, the Gateway exposes your tools as managed MCP endpoints. The model calls a tool, the Gateway routes to the correct implementation, returns the result — and the ReAct loop from lesson 11 continues.

The separation between Runtime and Gateway is intentional: Runtime thinks, Gateway acts. This means you can swap the agent framework without touching the tools, and you can add tools without redeploying the agent. It's the same decoupling principle we apply in event-driven architecture — just applied to the agent's cognitive loop.

In lesson 12 we saw that agents need two types of memory: short-term (what happened in this conversation) and long-term (what the agent should remember across sessions). AgentCore Memory implements exactly that. Short-term memory is the current session's message history, managed automatically. Long-term memory is a persistent store the agent can query and update — useful for user preferences, past decisions, or ongoing project context.

AgentCore Identity solves a problem every architect faces: how does the agent authenticate to the tools it calls? Without a dedicated block, you end up with hardcoded credentials, overly permissive IAM roles, or a homegrown secrets management system. Identity centralizes this: each tool call passes through an authorization layer that validates whether that agent, in that session, has permission to call that resource. It's the least-privilege principle from lesson 10 applied at runtime.

The Memory + Identity combination is what separates a production agent from a prototype. A prototype forgets everything and has unrestricted access. A production agent remembers what matters and only accesses what it needs.

AgentCore Observability delivers what lesson 9 asked for: visibility into what the agent is doing. Each step of the ReAct loop — which tool was called, what the response was, how long it took, what the model's reasoning was — becomes a structured trace. You can answer questions like: why did the agent make that decision? At which step did it hallucinate? Which tool is the latency bottleneck? Without this, debugging an agent in production means working in the dark.

The managed tools close the loop. The Browser Tool gives the agent the ability to browse the web in an isolated, auditable way — without you provisioning browser instances, dealing with Playwright in production, or exposing your network. The Code Interpreter does the same for code execution: the model generates Python, the Code Interpreter runs it in a sandbox, returns the result. Both arrive via the Gateway like any other MCP tool.

The architectural point here is consistency: all capabilities — external tools, browser, code, RAG — reach the model through the same protocol. The agent doesn't know whether it's calling your Lambda or the managed Browser Tool. This simplifies design and makes it easy to swap implementations without rewriting the agent.