← Knowledge Base

Amazon Bedrock AgentCore Runtime: A Complete Guide

AWS Bedrock AgentCore Runtime is a serverless, secure runtime for deploying AI agents. Here is what the agent core runtime does, how its stateful sessions and memory work, and how to run agents on it.

Amazon Bedrock AgentCore Runtime architecture showing serverless agent sessions, memory and tool gateway in AWS

Amazon Bedrock AgentCore Runtime — addressed in the AWS SDKs and APIs as bedrock-agent-runtime — is AWS’s serverless runtime for deploying and operating AI agents. If you have searched for “agent core runtime,” “aws bedrock agent runtime” or a “stateful runtime environment for agents in Amazon Bedrock,” this is the service those terms point at. This guide explains what the AgentCore Runtime is, how its sessions and memory work, and how to deploy an agent onto it.

What is the Bedrock AgentCore Runtime?

The AgentCore Runtime is the execution layer of Amazon Bedrock AgentCore — the part that actually runs your agent in production. It is a fully managed, serverless AI agent runtime: you hand it your agent code and it provisions isolated compute, manages sessions and memory, brokers tool calls, and scales with demand. Crucially it is framework- and model-agnostic — you can run agents built with LangGraph, CrewAI, the Strands Agents SDK, the OpenAI Agents SDK or your own loop, using Bedrock models or models hosted elsewhere.

It is worth separating two related-sounding APIs. The older Bedrock Agents service (a fully AWS-managed agent abstraction) is also invoked through bedrock-agent-runtime calls such as InvokeAgent and RetrieveAndGenerate. The newer AgentCore Runtime is the bring-your-own-agent platform. Both live under the same runtime namespace, which is why the keyword cluster around “bedrock agent runtime” is so tangled.

The stateful runtime environment for agents

The phrase that best captures AgentCore Runtime is a stateful runtime environment. Three properties matter:

  • Session isolation. Each user session runs in its own isolated microVM. One session’s memory, state and code execution are fully separated from another’s — essential for multi-tenant agents and for safely running model-generated code.
  • Long-running execution. Sessions can run for extended periods (up to eight hours), so an agent can carry out long, multi-step tasks rather than being forced into short request/response windows.
  • Built-in memory. AgentCore provides short-term (within-session) and long-term (cross-session) memory, so agents remember context and learned facts without you standing up your own store.

What you get with AgentCore

The AgentCore family wraps the runtime with the services a production agent needs:

  • Runtime — the serverless, isolated execution environment described above.
  • Memory — managed short- and long-term memory.
  • Gateway — turns existing APIs and Lambda functions into agent tools, and connects to MCP servers.
  • Identity — scoped, delegated access so an agent acts with a known, least- privilege identity.
  • Observability — traces and metrics for each agent step, integrated with CloudWatch.
  • Code Interpreter & Browser — sandboxed tools that let agents run code and drive a browser safely.

How to deploy an agent on the AgentCore Runtime

  1. Build your agent with the framework of your choice, exposing the entrypoint AgentCore expects.
  2. Wrap and containerise it with the AgentCore starter toolkit, which packages the agent for the runtime.
  3. Deploy to the AgentCore Runtime — AWS provisions the isolated, serverless environment; there are no servers to manage.
  4. Invoke the agent through the runtime API, passing a session identifier so state and memory persist across turns.
  5. Operate it using AgentCore Observability, and lock it down with Identity, guardrails and a VPC interface endpoint for private connectivity.

Private and secure connectivity

Production deployments usually keep traffic off the public internet. AgentCore Runtime supports VPC interface endpoints for bedrock-agent-runtime (AWS PrivateLink), so agent invocations travel privately within your VPC. Pair that with AgentCore Identity and the broader practices in our agent runtime security guide for a defensible deployment.

Multi-agent and A2A

Few real systems are a single agent. AgentCore Runtime supports the Agent-to-Agent (A2A) protocol, letting agents hosted on the runtime discover and call one another in a standard way — the foundation for multi-agent systems on AWS.

Where Orchestra fits

AgentCore runs an agent reliably. Orchestra coordinates that agent with the data pipelines, model jobs and downstream tasks around it — scheduling them in the right order, passing the right data between them, tracking lineage end to end, and recovering when a step fails. The runtime is the engine; orchestration is what turns a fleet of agents and jobs into a dependable agentic pipeline.

Conclusion

Amazon Bedrock AgentCore Runtime is the serverless, stateful, framework-agnostic environment for running AI agents on AWS: isolated sessions, built-in memory, long-running executions, a tool gateway, scoped identity and observability. Deploy your agent onto it, connect privately over a VPC endpoint, govern it with Identity and guardrails, and orchestrate it into the wider stack to get reliable agentic systems in production.

FAQs

It is AWS’s serverless, fully managed runtime for deploying AI agents. The AgentCore Runtime provisions isolated compute, manages sessions and memory, brokers tool calls and scales automatically. It is framework- and model-agnostic, so you can run agents built with LangGraph, CrewAI, Strands or your own loop. In the AWS SDKs it is part of the bedrock-agent-runtime API surface.

Related articles