4.4.5. Deploying Agents with Amazon Bedrock AgentCore
💡 First Principle: An agent is an application that loops: reason, call a tool, observe, repeat. Deploying one means solving four problems that a model endpoint never had: isolating each user's session, connecting to tools securely, remembering context across turns and sessions, and releasing new agent code without breaking live conversations.
Amazon Bedrock AgentCore provides those pieces as modular services that work with any framework (Strands Agents, LangGraph, CrewAI, LlamaIndex and others) and any model, inside or outside Bedrock.
| Service | Solves |
|---|---|
| Runtime | Serverless hosting; each session runs in its own microVM with isolated CPU, memory and filesystem |
| Gateway | Turns APIs, Lambda functions and existing services into MCP tools; fronts other agents and model providers |
| Memory | Short-term (turn-by-turn events) and long-term (extracted insights) memory |
| Identity | Inbound auth for callers (IdP or SigV4) and outbound OAuth or API-key access to third-party tools |
| Code Interpreter / Browser | Sandboxed code execution and managed web browsing |
| Observability / Evaluations | OpenTelemetry-compatible traces in CloudWatch; automated quality scoring of agent sessions |
| Policy | Deterministic Cedar rules that Gateway checks before every tool call |
Runtime facts that shape designs. Agents are packaged as ARM64 container images in Amazon ECR or as a .zip direct code deployment. A microVM session idles out after idleRuntimeSessionTimeout (default 900 seconds) and ends at maxLifetime (default and maximum 28,800 seconds, 8 hours); runtimes on the Instances compute type allow up to 14 days and GPU workloads. CPU billing tracks active processing, so time spent waiting on LLM responses is typically not charged. Payloads up to 100 MB are accepted, and networkMode can be PUBLIC or VPC to reach private resources.
Agent communication protocols. Runtime hosts servers for four protocols, each with its own port and path:
| Protocol | Purpose | Port / path | Discovery |
|---|---|---|---|
| HTTP | Direct request/response or WebSocket streaming | 8080, /invocations, /ws | None |
| MCP (Model Context Protocol) | Agent-to-tool: expose tools to agents | 8000, /mcp | Tool listing |
| A2A (Agent-to-Agent) | Agent-to-agent collaboration | 9000, / | Agent Cards |
| AG-UI | Agent-to-user-interface event streams | 8080, /invocations, /ws | None |
Agent state management. State lives at three levels and each belongs somewhere different:
- Within a turn and session: the Runtime microVM holds in-process state for the life of the session; a new
runtimeSessionIdgets a fresh microVM, so never rely on process memory across sessions. - Conversation history: AgentCore Memory short-term events are written with
CreateEvent, keyed byactorIdandsessionId.eventExpiryDuration(3 to 365 days) controls how long raw events are kept. - Knowledge about the user: long-term memory records are extracted asynchronously by strategies. Built-in strategies are semantic, user preference, summary and episodic; built-in overrides let you customise prompts; self-managed strategies let you run your own pipeline. No strategy means no long-term records.
Amazon Bedrock Agents Classic. The original Bedrock Agents (action groups, aliases, sessionAttributes that last for a session and promptSessionAttributes that last for one turn) entered maintenance mode on 30 July 2026. Accounts without prior usage cannot create new agents; AWS recommends AgentCore for new development and migration.
⚠️ Exam Trap: MCP and A2A are not interchangeable. MCP connects an agent to tools; A2A lets independently deployed agents discover (through Agent Cards) and delegate to each other. If a scenario asks how a supervisor agent built in one framework calls a specialist agent owned by another team, the answer is A2A; if it asks how to expose an internal REST API to agents, the answer is Gateway turning the API into MCP tools.
