What Is Amazon Bedrock AgentCore? (And When to Use It)

Amazon Bedrock AgentCore is a managed platform for deploying and operating AI agents you’ve already built — in any framework, with any model — without managing the runtime, memory, identity, or observability infrastructure yourself. It’s important to understand that AgentCore is not “Bedrock Agents version 2.” It doesn’t define your agent for you, and it doesn’t lock you to Bedrock models. You bring a LangGraph, CrewAI, LlamaIndex, or Strands agent and AgentCore runs it.

First, What Kind of Workload Is an Agent?

As engineers we navigate AWS by workload shape. Say “frontend” and you already know the answer — static assets in S3 behind CloudFront, public internet access. Say “containerized service” and you reach for ECS or EKS, EC2 if you want to manage the nodes yourself. Each phrase maps to a known shape, and the shape tells you where it goes. Say “agent,” and most of us go blank. Agent doesn’t match any of the shapes we already have names for.

Traditional infra sorts workloads into roughly three buckets:

• Stateless request/response — a web API. Short, fast, remembers nothing between calls. Home: Lambda, or a container behind a load balancer.
• Always-on service — a daemon holding connections, running continuously. Home: ECS, EKS, EC2.
• Batch / async job — runs a defined sequence to completion, then exits. Home: AWS Batch, Step Functions, a queue worker.

An agent is none of these cleanly, because it has a combination of traits none of those buckets were built for:

• Long-lived but mostly idle. A single session can run for minutes to hours across a multi-turn conversation, but 30–70% of that wall-clock time is spent waiting — on an LLM streaming tokens, or a tool’s HTTP response. The CPU is near-zero between bursts.
• Stateful by nature. It has to remember the conversation so far, and ideally facts across sessions. A stateless service throws that away every call; you’d bolt on DynamoDB or Redis and rehydrate context on every turn.
• Non-deterministic control flow. The model decides what happens next — which tool to call, whether to loop again. You’re running code whose execution path is chosen at runtime by an LLM, often on untrusted user input, which makes per-session isolation a security concern, not a nicety.
• An outbound actor. It authenticates to and calls other systems on a user’s behalf. That’s an identity and credential problem a stateless API doesn’t have in the same shape.

So an agent is a genuinely new workload shape: a long-running, stateful, I/O-bound, model-driven loop that acts on a user’s behalf.

AgentCore Runtime is the home built for that shape — per-session microVM isolation, sessions up to 8 hours, and billing only for active compute so the idle waiting is free. That’s the mental slot to file it in: Runtime is to an agent what ECS is to a container. The rest of AgentCore fills the gaps the shape creates — memory for the state, Identity for the outbound auth, Gateway for the tools, Observability for the non-deterministic control flow.

A note on portability: EKS gives you Kubernetes, an open standard you can lift to GKE or AKS. AgentCore is not that — Runtime, Memory, Gateway, and the rest are proprietary AWS services with no equivalent on another cloud. What stays portable is your agent code: it’s a standard ARM64 container exposing two HTTP endpoints (/invocations and /ping), running your own framework and model. So the coupling is thin, but leaving AgentCore looks like leaving Lambda — re-host the container, replace the managed services — not the one-kubeconfig move off EKS.

The Problem AgentCore Solves

Building an agent that works in a notebook is the easy part. Taking it to production is where teams stall. A production agent needs a runtime that scales and isolates user sessions, persistent memory across conversations, secure access to tools and APIs, identity and credential management, and observability to debug what the agent actually did. Most teams end up assembling this from Lambda or Fargate, DynamoDB or Redis, Secrets Manager, and a tracing stack — and maintaining it.

AgentCore packages that platform as managed, modular services. AWS calls it “eliminating the undifferentiated heavy lifting of building specialized agent infrastructure.” You keep your agent’s logic; AWS runs everything underneath it.

The Core Services

AgentCore is composed of services you can use together or independently:

• Runtime — a serverless, session-isolated environment that hosts your agent. Each session runs in its own microVM with isolated CPU, memory, and filesystem, and can persist for up to 8 hours. You deploy via the AgentCore CLI, the Python SDK, or AWS SDKs.
• Memory — managed short-term memory (raw events within a session) and long-term memory, so your agent stops treating every conversation as its first. Long-term knowledge is extracted by configurable strategies — semantic, summarization, user preference, episodic, or custom — and retrieved by semantic search in later sessions. The episodic strategy detects when an episode completes, consolidates it into a single record, then generates reflections: insights across episodes that turn past experience into guidance, rather than storing flat facts. Memory is scoped by actorId and sessionId, so each user’s memory is isolated — the detail that matters in multi-tenant agents.
• Gateway — turns existing APIs, Lambda functions, and services into Model Context Protocol (MCP)-compatible tools, with a single secure endpoint and semantic tool discovery. It supports OpenAPI and Lambda inputs and includes 1-click integrations for tools like Salesforce, Slack, and Jira.
• Identity — assigns agents verifiable identities and manages credentials, handling both inbound auth (who can invoke the agent) and outbound auth (how the agent authenticates to other services), with a KMS-encrypted token vault for OAuth tokens and API keys.
• Built-in tools — a managed Browser Tool for web interaction and a Code Interpreter for sandboxed code execution.
• Observability — traces, logs, and metrics powered by CloudWatch and OpenTelemetry, so you can visualize the agent’s full execution path.

AWS has continued to expand the platform — Policy (authorization on tool calls, authored in natural language and compiled to Cedar, so security and compliance reviewers can read the rules as well as developers) and Evaluations (built-in evaluators for agent quality, plus custom model-based scoring) arrived as previews in late 2025, and Payments for agent microtransactions followed in 2026.

When to Use AgentCore

AgentCore is the right call when all of these are true:

• You already have an agent built in an open-source or custom framework and you want it in production fast, without building the surrounding platform.
• You want to keep your framework and model. AgentCore is framework- and model-agnostic by design — including models outside Bedrock. If you’re committed to LangGraph or CrewAI, you don’t give that up.
• You need session isolation and managed state. Multi-tenant agents handling untrusted input benefit from per-session microVM isolation that’s painful to build yourself.
• You’ve outgrown DIY plumbing. If you’re maintaining your own checkpointing, credential vault, and tracing stack and it’s becoming a second product, AgentCore absorbs that.

It’s less compelling when your agent is a simple, stateless request/response chain with no tools — a plain Lambda may be cheaper and simpler — or when AWS’s Bedrock Agents already fits your use case and you’re happy letting AWS define the orchestration. That trade-off deserves its own breakdown: see AgentCore vs Bedrock Agents vs Roll-Your-Own on Fargate.

How the Pieces Fit Together

A typical production agent on AgentCore looks like this: your framework code runs in Runtime, calls Memory to recall context, reaches tools through Gateway, authenticates via Identity, and emits traces to Observability. Because the services are independent, you can adopt them one at a time — start with Runtime to get deployed, then add Memory and Gateway as the agent grows.

The pricing model reinforces this. AgentCore is consumption-based with no upfront commitment, and Runtime only charges for active resource consumption — during the 30–70% of agent time spent waiting on LLM responses or tool calls, you pay no CPU charge. That’s a genuine difference from always-on Fargate.

Evaluations are a cost lever, not just a quality one

Worth drawing out, because it connects two things teams usually run separately. The highest-leverage cost control in any LLM workload is model right-sizing — running a cheaper model wherever it still clears the quality bar. But “use a cheaper model” is advice without a mechanism unless you can prove the cheaper model is good enough on your actual task.

That proof is an eval. AgentCore Evaluations is a native place to run it against live agent traffic, which makes the same machinery serve quality regression alarms and cost decisions at once. The workflow itself is in Model Evals: How to Know If You Can Use a Cheaper Model.

If you’re coming at this from the coding-agent side — agents that consume AWS rather than run on it — see Connect Claude Code to Live AWS Tools with the Agent Toolkit.

Key Takeaways

• AgentCore runs agents you’ve already built; it doesn’t define them for you, and it’s framework- and model-agnostic.
• It’s a set of modular, managed services — Runtime, Memory, Gateway, Identity, built-in tools, Observability — usable together or independently.
• Reach for it when you have a working agent and want production-grade runtime, memory, and identity without building that platform yourself.
• Pricing is consumption-based, and Runtime charges only for active compute — a real cost edge over always-on infrastructure for I/O-heavy agents.

Related

• AgentCore vs Bedrock Agents vs Roll-Your-Own on Fargate