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 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) 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 , LangGraph , LlamaIndex , 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 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 .
You can also use the AgentCore CLI , the AWS Command Line Interface (AWS 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 .
Originally published at aws.amazon.com
