# Runtime instances: persistent compute for production AI agents on Amazon Bedrock AgentCore

> Source: <https://aws.amazon.com/blogs/aws/runtime-instances-persistent-compute-for-production-ai-agents-on-amazon-bedrock-agentcore/>
> Published: 2026-08-06 22:58:00+00:00

[AWS News Blog](/blogs/aws/)

# Runtime instances: persistent compute for production AI agents on Amazon Bedrock AgentCore

|
|

When you move AI agents from prototype to production, the infrastructure challenges multiply. Your agents need to persist state across multi-step workflows that run for hours or days. They need to coordinate with other agents, share context, and sometimes access GPUs for specialized tasks. Amazon Bedrock AgentCore runtime microVMs provide a fully managed environment for invocations that can run for up to 8 hours and support stateful workflows through managed session storage. Some workloads also benefit from dedicated, larger-capacity environments — for example, when agents need to run continuously for multiple days, access GPUs or the underlying OS, or run multiple collaborating agents on the same host.

Today, I’m happy to announce runtime instances, a new complementary compute option in [Amazon Bedrock AgentCore Runtime](/bedrock/agentcore/) that gives your agents persistent, managed infrastructure purpose-built for complex agent workloads.

**What you get**

Runtime instances provides AWS-managed EC2 infrastructure where you deploy multiple agents in a single runtime, each with their own dependencies and artifact types. Your agents can collaborate on the same host within shared sessions that persist for up to 14 days. The service supports GPU acceleration for compute-intensive tasks, session stop/restart to save costs during idle periods, and containerized deployments for teams that want to ship independently. For knowledge that needs to survive beyond a session, runtime instances pairs naturally with [Amazon Elastic Block Store (Amazon EBS)](/ebs/) and AgentCore Memory, which gives your agents long-term recall across sessions and environments.

Before today, if you wanted to keep your agents running for days or they needed GPU access, or multi-agent coordination, you had to build and manage that infrastructure yourself. You provisioned EC2 instances, configured networking, set up session management, handled scaling, and stitched together monitoring. Runtime instances handles all of that for you while integrating with the same AgentCore APIs, identity controls, and observability you already use with AgentCore Runtime microVMs.

A few things that should make agent developers smile: your agents can call each other as tools within a shared session, iterating autonomously until the job is done. You bring any framework ([CrewAI](https://crewai.com/), [LangGraph](https://www.langchain.com/langgraph), [LlamaIndex](https://www.llamaindex.ai/), Strands) and any model. Packaging is minimal, a `@app.entrypoint`

decorator and a zip file or container image. And if your workflow spans days, hibernate Monday night and resume Wednesday morning with everything intact.

Runtime microVMs and runtime instances are complementary compute options that you can use independently or together through the same AgentCore runtime APIs. A lightweight orchestrator agent on runtime microVM can coordinate and dispatch work to specialized worker agents running on instances. The orchestrator handles API calls, task routing, and result aggregation using runtime microVM’s fast scaling, while workers on Instances perform compute-intensive tasks like code compilation, security scanning, or GUI automation that require persistent state and direct OS access.

**Let me show you how it works
**I built two agents for this demo: a code writer agent that generates Python code from natural language descriptions, and a code reviewer agent that analyzes the generated code for bugs, security issues, and style improvements. Both agents share the same file system, so the reviewer can read whatever the writer produces without any data transfer or API calls between them.

Here is the code writer (simplified, no error handling):

```
writer = Agent(
    model="us.anthropic.claude-sonnet-4-5-20250929-v1:0",
    system_prompt=(
        "You are a senior Python engineer. "
        "Given a task, return ONLY a single Python code block — no prose."
    ),
)

@app.entrypoint
def handler(event, context):
    task = event.get("task") or event.get("prompt")
    session_id = getattr(context, "session_id", None) or event.get("session_id")
    session_dir = SHARED_DIR / session_id
    session_dir.mkdir(parents=True, exist_ok=True)

    code = str(writer(task))
    (session_dir / "code.py").write_text(code)

    return {"agent": "writer", "wrote": str(session_dir / "code.py"), "code": code}
```

Here is the code reviewer agent (simplified, no error handling):

```
reviewer = Agent(
    model="us.anthropic.claude-sonnet-4-5-20250929-v1:0",
    system_prompt=(
        "You are a strict Python code reviewer. "
        "Given code, return 3 bullet points: bugs, style, suggestions."
    ),
)

@app.entrypoint
def handler(event, context):
    session_id = getattr(context, "session_id", None) or event.get("session_id")
    code_path = SHARED_DIR / session_id / "code.py"
    code = code_path.read_text()
    review = str(reviewer(f"Review this code:\n\n{code}"))

    return {"agent": "reviewer", "read": str(code_path), "review": review}
```

Each agent is a Python application using [Strands Agents](https://strandsagents.com/) with an `@app.entrypoint`

decorator and a model of its choice. I package each one as a zip file. For this demo, I use the [AWS Management Console](https://console.aws.amazon.com). You can also use the [AgentCore CLI](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-get-started-cli.html), the [AWS Command Line Interface (AWS CLI)](/cli/) or infrastructure as code.

**Step 1: Create a capacity provider.**

A capacity provider defines the EC2 infrastructure your agents run on. In the AgentCore console, I select **Runtime** in the left navigation, then select the **Capacity providers** tab and **Create capacity provider**.

I give it a **Name**, select Linux (64-bit ARM) as the **Operating system**, and choose `c7g.2xlarge`

as the **Allowed instance types**. This gives me 8 vCPUs and 16 GiB of memory, enough for both agents to run comfortably side by side.

Further down, I configure the **VPC**, **subnets**, and **security groups** for network access. Under **Storage configuration**, I keep the default gp3 volume. Under **Service access**, I select **Create a new service role** and let the console create the infrastructure role that manages EC2 instances on my behalf.

I select **Create capacity** provider and wait a few seconds. The status moves to **Active**.

Note the capacity provider configuration summary: operating system, instance type, subnets, security group, instance profile, and infrastructure role. Once created, only the description can be edited, so verify your settings before you proceed.

**Step 2: Create a runtime and deploy the first agent.**

Back on the **Runtime** page, I select **Create runtime**. I give it a **Name**, select Instances as the **Compute type**, and choose the **Capacity provider** I created in the previous step.

Under **Agent source**, I select **S3 Source**, then **Upload to S3**. I choose my agent zip file (`ACIDemoWriter.zip`

), set the **Language runtime** to `Python 3.13,`

and specify `agent.py`

as the **Agent entry point**. This is the file that contains my `@app.entrypoint`

decorated function. Under **Permissions**, I select **Create default role** to let the console provision the IAM role my agent needs.

I select **Create runtime** and wait for the status to become **Ready**.

I repeat the same process for my code reviewer agent. I create a second runtime, select the same capacity provider, upload my reviewer agent zip file, and wait for it to become **Ready**. Both agents now share the same underlying EC2 infrastructure.

The console shows me a **View invocation code** section with ready-to-use Python, TypeScript, and JavaScript snippets to invoke my agent programmatically. But for this demo, I use the built-in test feature. I select **Test** on the writer agent’s page.

**Step 3: Invoke agents and observe collaboration.**

The **Runtime playground** opens. At the top, I see three fields: **Runtime agent**, **Endpoint**, and **Session ID**. The console generates a session ID automatically. I take note of it because I will reuse it with the reviewer agent.

In the **Input** field, I type a JSON payload asking the writer agent to generate code:

```
{"prompt": "write a fibonacci suite"}
```

I select **Run**. After a few seconds, the **Output** panel shows the agent’s response. The writer agent generated a Python module with two implementations of a Fibonacci sequence (a list-based function and a generator) and wrote it to `/tmp/agentcore-session/ca5ec24d-07f5-4eeb-add1-5ba416bf9eb2/code.py`

. Notice the session ID in the file path. That directory is the shared file system for this session.

**Step 4: Invoke the reviewer agent in the same session.**

Now I switch the **Runtime agent** dropdown to **ACIDemoReviewer**. The important part: I paste the same session ID (`ca5ec24d-07f5-4eeb-add1-5ba416bf9eb2)`

in the **Session ID** field. This is what connects the two agents.

I type a simple prompt:

```
{"prompt": "review the code"}
```

I select **Run**. The reviewer agent reads the file the writer produced from the shared session directory and returns a detailed code review. It finds no critical bugs but suggests adding type hints, input validation, and simplifying the edge case handling.

The two agents never exchanged messages or called each other’s APIs. They collaborated through the shared file system that runtime instances provide within a session. You can extend this pattern to any number of agents: a test agent that runs the code, a documentation agent that generates README files, a security agent that scans for vulnerabilities, all sharing the same working directory.

**Key details
**Here are a few things to know as you get started:

**Supported OS**: Linux (ARM64 and x86_64) at launch.** Session persistence**: Sessions persist for up to 14 days.** Runtimes**: Python 3.11-14 with native code support. Container images also supported.** GPU**: Support for GPU-accelerated instance types.** Integration**: Uses the same AgentCore APIs, identity, observability, and policy controls as AgentCore Runtime.** Pricing**: Standard EC2 pricing plus a management fee for AgentCore orchestration.** Regions**: US East (Ohio, N. Virginia), US West (Oregon), Asia Pacific (Mumbai, Singapore, Sydney, Tokyo), and Europe (Frankfurt, Ireland)

To get started, visit the runtime instance in [Amazon Bedrock AgentCore documentation](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-instances-how-it-works.html)** **and create your first capacity provider.

[— seb](https://linktr.ee/sebsto)