AgentCore Runtime, the missing primitive.

AgentCore Runtime is the secure, serverless execution environment at the centre of Amazon Bedrock AgentCore. Bring an agent written in any framework — Strands, LangGraph, LlamaIndex, Google ADK, OpenAI Agents — pointed at any foundation model. AWS handles sessions, isolation, and the long timeout you actually need.

01Why AgentCore Runtime exists

Hosting an agent is not the same problem as hosting a web service. Agents hold conversation state, call tools, stream tokens for minutes at a time, and have to be isolated from each other so one user's session never sees another's. AWS Lambda is too short for long reasoning loops; ECS or EKS gives you a cluster to operate; rolling your own EC2 means rolling your own session manager and identity layer.

AgentCore Runtime removes that whole layer. You give it a container image (or let the CLI build one for you), and it runs your agent behind an HTTP endpoint with these guarantees baked in:

• True session isolation. Each invocation runs in its own session context; one user's conversation never crosses into another's.
• Fast cold starts for chat-style real-time interactions, plus extended runtime for asynchronous background agents — up to 8 hours per session, well past Lambda's 15-minute ceiling.
• Framework-neutral. Strands, LangChain/LangGraph, Google ADK, OpenAI Agents — Runtime doesn't care.
• Model-neutral. Anthropic Claude, Amazon Nova, OpenAI, Gemini, Meta Llama, Mistral — pick whichever your agent needs.
• Protocol-neutral. HTTP for chat, MCP for tool servers, A2A for agent-to-agent.

02The fastest path: the AgentCore CLI

The official path from "no code" to "deployed agent" is the AgentCore CLI — distributed as an npm package. It scaffolds a project, deploys via CDK, and invokes the running endpoint.

Reconstruction · not a recording of a real run

The agentcore create flags worth knowing:

• --framework — Strands, LangChain_LangGraph, GoogleADK, OpenAIAgents.
• --protocol — HTTP (default), MCP, A2A.
• --build — CodeZip (default) or Container. Use Container when you need extra system dependencies in the image.
• --model-provider — Bedrock, Anthropic, OpenAI, Gemini.
• --memory — none, shortTerm, longAndShortTerm. Wires up AgentCore Memory automatically.

The scaffold drops you into a project with three things that matter: agentcore/agentcore.json (project + agent config), app/MyAgent/main.py (your agent code), and aws-targets.json (account + region targets).

03The container contract

If you bring your own container (the "no CLI" path), Runtime expects a small contract from the image — and the failure modes when you get it wrong are obvious enough to be worth memorising.

The starter Dockerfile from the docs uses FROM public.ecr.aws/docker/library/python:3.12-slim with --platform=linux/arm64 on the build, then pip install for the agent framework plus FastAPI/Uvicorn for the HTTP layer. The CLI's --build Container mode generates this for you.

04Sessions, endpoints, versions

Three concepts you'll see repeatedly:

• Runtime — the deployed agent itself. Configuration is immutable per version; every time you push a change, AgentCore creates a new version automatically.
• Endpoint — a named, mutable pointer to a version. The DEFAULT endpoint advances to the newest version on every deploy. Create additional endpoints (e.g. production) and pin them to a specific version when you need stability.
• Session — an isolated execution context for one conversation. Identified by runtimeSessionId. A session can stay open for up to 8 hours; cold starts on a new session are designed for chat-level latency.

Together: Runtime → Version → Endpoint → Session. Endpoints decouple clients ("hit the production endpoint") from versions ("v17 is the build we shipped on Tuesday").

05How Runtime fits with the rest of AgentCore

Runtime is one of eleven AgentCore services. It's the host; the others plug in:

• Identity — handles agent-side OAuth and credential vending so your Runtime container never sees long-lived secrets.
• Memory — short-term and long-term memory stores Runtime sessions can read and write.
• Gateway — turns your existing APIs and Lambdas into MCP tools the Runtime agent can call.
• Observability — every Runtime invocation emits OpenTelemetry spans to CloudWatch Transaction Search; enable it once and the agent inspector lights up automatically.
• Code Interpreter / Browser — sandboxed tools the Runtime agent invokes when it needs to execute code or drive a webpage.

Runtime can run completely standalone — none of the others are required — but the value compounds quickly when you bring two or three of them in.

06Limits worth knowing on day one

• ARM64 only. No exceptions. Build with --platform=linux/arm64 or the image won't start.
• 8-hour session ceiling. Long, but not infinite. Plan checkpointing if your agent legitimately needs longer.
• /invocations and /ping are mandatory. Both must exist; both must return promptly. CloudWatch logs will tell you when /ping starts failing.
• boto3 service name is bedrock-agentcore. A common copy-paste trip is bedrock-agent-core with the hyphen — that one fails fast with "Unknown service".
• Observability is opt-in. Enable CloudWatch Transaction Search once per account/region or you'll see "spans are missing" in the agent inspector.

07Try it in five minutes

If you have Node 20+, Python 3.10+, the AWS CDK installed, and AWS credentials configured, the full happy path is four commands:

agentcore status shows the deployed endpoint URL; agentcore invoke "Hello" sends a prompt; agentcore logs --tail streams CloudWatch.

Tomorrow we'll look at the /invocations HTTP contract in detail — what the request and response actually look like on the wire when you bypass the CLI and call Runtime directly with boto3 or curl.