What Is AgentCore?

Amazon Bedrock AgentCore is, in AWS's own words, "an agentic platform for building, deploying, and operating highly effective agents securely at scale using any framework and foundation model." It lets you enable agents to take actions across tools and data with the right permissions and governance, run agents securely at scale, and monitor agent performance and quality in production — all without any infrastructure management.

The critical mental shift: AgentCore is not a framework and not an agent. It is a set of managed, serverless production primitives — the operational plumbing that sits underneath whatever agent you already wrote. You keep your agent logic and your framework; AgentCore offloads the heavy operational lifting.

The naming trap. Two AWS products have confusingly similar names:

The brand is "Amazon Bedrock AgentCore"; the individual services are written "AgentCore Runtime," "AgentCore Memory," "AgentCore Gateway," and so on. Despite the "Bedrock" in the name, AgentCore is explicitly NOT limited to Bedrock models or to one framework. Treat it as a sibling platform under the Bedrock umbrella, distinct from classic Bedrock Agents — and note these two coexist; classic Bedrock Agents is not deprecated.

Here is the problem AgentCore exists to solve, stated plainly: building an agent demo on your laptop is easy; operating that agent in production is hard.

A LangGraph or Strands agent that answers questions on your machine looks finished. It is not. The moment real users hit it, you discover everything the demo glossed over:

• Session isolation — user A's reasoning context, files, and in-memory state must never leak into user B's session.
• Secure deployment — package, ship, version, and roll back the agent without standing up servers.
• Persistent memory — remember facts within a conversation and across sessions, not just inside one process.
• Identity / authorization — when the agent acts on a user's behalf (calling an API, hitting a database), it needs the right credentials with the right scopes, not a hard-coded key.
• Governed tools — a controlled, auditable way to connect tools and back-end APIs.
• Sandboxes — isolated environments to run model-generated code and drive a browser safely.
• Observability — end-to-end traces, metrics, and logs so you can debug a non-deterministic system in production.

Historically, teams hand-built all of this on EC2/EKS/Lambda: a per-user isolation scheme, a deploy pipeline, a memory store, a secrets/OAuth layer, an API gateway for tools, a code sandbox, and an OpenTelemetry stack. That is months of undifferentiated plumbing before your agent does anything novel.

AgentCore provides each of those as a managed, serverless service. The mapping is one-to-one:

These are the original 7 services — announced together at preview and, as of writing, all reached general availability (the preview was announced mid-2025 and GA followed later that year; treat any specific date as volatile and confirm it on the live AWS pages). The "Core services" table keeps growing — newer modules such as Harness, Policy, Evaluations, Registry, Payments, and Optimization have since appeared, several still in preview. The next lesson catalogs the full set; for now, anchor on these seven.

The first foundational property — and the conceptual backbone of the whole course — is that AgentCore is framework-agnostic.

The key idea: Runtime hosts a container that speaks a known protocol, not a framework. AWS never imports your framework or inspects your agent object. It runs a container, and that container exposes a small standardized HTTP contract (/invocations for work, /ping for health). Your framework lives inside the container, behind that contract.

The seam between AWS's managed HTTP server and your framework is a single decorator: @app.entrypoint. The Python SDK package bedrock-agentcore ships a thin ASGI wrapper, BedrockAgentCoreApp, that turns a plain function into the HTTP service contract — wiring /invocations, /ping, session headers, and streaming for you.

The "four lines to deploy" framing: (1) import, (2) app = BedrockAgentCoreApp(), (3) @app.entrypoint, (4) app.run():

from bedrock_agentcore.runtime import BedrockAgentCoreApp
from strands import Agent

app = BedrockAgentCoreApp()
agent = Agent()

@app.entrypoint
def invoke(payload):
    result = agent(payload.get("prompt", "Hello"))
    return {"result": result.message}

if __name__ == "__main__":
    app.run()   # local http://localhost:8080; in container binds 0.0.0.0:8080

The body inside @app.entrypoint is the only part that changes between frameworks. Everything around it — the decorator, payload.get("prompt"), the {"result": ...} shape, app.run(), the deploy flow — is invariant. Swap Strands for LangGraph, CrewAI, LlamaIndex, Google ADK, or the OpenAI Agents SDK and only the three lines that build and call the agent move:

AWS names Strands Agents (its open-source, Apache-2.0 SDK) as first-class/recommended, but the official samples repo carries folders for langchain, langgraph, crewai, llamaindex, adk, openai-agents, pydanticai-agents, and more — plus plain custom code. The framework is your choice; the protocol is the contract.

The second backbone property: AgentCore is model-agnostic. The model is just a config value inside your agent code — Bedrock, OpenAI, Gemini, Anthropic's direct API, a local Ollama model — and AgentCore never inspects it. This is the direct consequence of property #1: AWS runs a container over HTTP, so it has no opinion about which model the code inside calls.

With Strands, you select a Bedrock model by configuring a BedrockModel:

from strands import Agent
from strands.models.bedrock import BedrockModel

model = BedrockModel(
    model_id="amazon.nova-pro-v1:0",   # or a Claude model, or a us./global. cross-region inference profile
    region_name="us-west-2",
    temperature=0.3,
)
agent = Agent(model=model)

Switching to a non-Bedrock provider is purely a code change — a different provider class, same agent:

This is exactly why the "Bedrock" in the product name is misleading: you can deploy an OpenAI- or Gemini-backed agent onto AgentCore Runtime and AWS is none the wiser.

A note on model IDs (VOLATILE). Exact model IDs change between releases. As of writing, the default Strands model is reported as global.anthropic.claude-sonnet-4-5-20250929-v1:0, and claude-sonnet-4-20250514 is now legacy — but treat any specific ID as something to verify against the live catalog, not a timeless fact. Pin a current ID and confirm it on https://docs.aws.amazon.com/bedrock/latest/userguide/models-supported.html

AgentCore's services are modular — they "work together or independently." You do not have to adopt the whole platform.

Concretely, you can:

• Use only AgentCore Gateway to expose your existing APIs and Lambda functions as MCP tools, while your agent runs on EKS, ECS, or Lambda.
• Use only AgentCore Code Interpreter as a managed sandbox for model-generated code, calling it from an agent hosted anywhere.
• Use only AgentCore Memory as a managed store, bolted onto a framework agent you run yourself.

Each service has its own SDK / API surface (its own boto3 client, its own control and data planes) and is independently billable — pricing is consumption-based, per service, with no upfront commitment. There is no monolithic "turn on AgentCore" switch; you compose the pieces you need.

This is what makes the platform incrementally adoptable. A team with an existing agent on Lambda can start by routing its tool calls through Gateway for governance, add Memory later for persistence, and only move hosting onto Runtime when session isolation becomes a requirement — each step a separate, independently-paid decision.

        ┌────────────────────────────────────────────┐
        │   Your agent (any framework, any model)      │
        └────────────────────────────────────────────┘
             │            │            │           │
        ┌────▼───┐   ┌────▼────┐  ┌────▼────┐  ┌────▼─────────┐
        │Runtime │   │ Memory  │  │ Gateway │  │ Code Interp. │  ...pick any subset
        └────────┘   └─────────┘  └─────────┘  └──────────────┘
          each: own SDK/API surface · independently billable

Pricing is consumption-based — "flexible, consumption-based pricing with no upfront commitments or minimum fees," spread across roughly a dozen independently billable components. Because every concrete rate is volatile, the rule for this course is: learn the billing dimension (per active vCPU-hour, per request, per record, etc.) and verify the number on the live page.

AWS frames AgentCore around three use cases. Knowing which one your project maps to tells you which services you'll lean on first.

1. Agents — autonomous applications. Apps that reason, use tools, and keep context. They run serverless with isolated sessions, persistent memory, and built-in observability. This is the default mental model: you wrote an agent, you want it operated in production. Primary services: Runtime + Memory + Observability (+ Identity for actions).

2. Tools / MCP servers — turn what you already have into agent-callable tools. Convert existing APIs, databases, Lambda functions, or services into Model Context Protocol (MCP) tools that any agent can call — without rewriting your backends. Primary service: Gateway. This is how an organization makes its existing systems consumable by agents en masse.

3. Agent platforms — the paved path. Give internal teams a governed environment: approved tools, shared memory, governed access, and centralized observability, auth, and compliance. Instead of every team standing up its own plumbing, the platform team operates one and hands out a paved path. Primary services: essentially the whole platform working together — Gateway (approved tools) + Identity (governed access) + Memory (shared) + Observability (centralized) + Runtime.

  Agents            →  build & operate ONE autonomous app   (Runtime, Memory, Observability)
  Tools / MCP       →  expose existing systems to agents     (Gateway)
  Agent platforms   →  a governed paved path for many teams  (everything, together)

Notice the progression: the first use case is one team operating one agent; the third is one platform team operating capabilities for the whole org. The modularity from the previous section is what makes that span possible with the same building blocks.