Amazon Web Services has introduced runtime instances in Amazon Bedrock AgentCore, providing a managed EC2-backed compute option that enables complex AI agents to execute stateful workflows for up to 14 days, utilize GPU acceleration, and coordinate via shared file systems without requiring manual infrastructure management, according to developer documentation released on August 6, 2026.
When engineering teams push autonomous multi-step systems from local prototypes into enterprise production environments, the infrastructure cracks begin to show. Traditional serverless setups hit hard walls. State evaporates, execution windows time out, and passing context between distinct models demands an endless pipeline of custom API glue. AWS is attempting to solve this architectural bottleneck by expanding its agentic orchestration layer.
Bridging the MicroVM Gap with Persistent EC2 Infrastructure
At launch, Amazon Bedrock AgentCore relied primarily on lightweight runtime microVMs designed for rapid, short-lived, request-response execution cycles. While optimal for snappy stateless interactions, those microVM environments carry a strict eight-hour execution ceiling. For deep code compilation, extensive document parsing, or multi-day autonomous research, that ceiling forces developers to provision, patch, and scale their own raw Amazon EC2 fleets.
Runtime instances change that calculus by injecting AWS-managed EC2 infrastructure directly into the AgentCore control plane. According to principal developer advocate Sebastien Stormacq, teams can now deploy multiple agents into a single runtime where each agent maintains distinct dependencies and artifact types while collaborating on the same host. Sessions persist for up to 14 days, surviving overnight pauses through native session stop and restart capabilities that optimize cloud spend during idle windows.
Underpinning this capability is a new capacity provider primitive. Developers avoid the operational overhead of maintaining Auto Scaling groups, launch templates, or custom AMI pipelines.
Architecting Multi-Agent Collaboration via Shared File Systems
One of the most consequential architectural shifts introduced by runtime instances is the elimination of API-heavy handoffs between collaborating agents. In a standard microVM setup, separate worker agents must serialize data and fire network requests back and forth across APIs to exchange context.
Runtime instances allow co-located agents to operate within a shared session directory mapped directly to the local file system. To illustrate this pattern, consider a dual-agent software pipeline combining a code generation agent and a strict code review agent. Both agents utilize the underlying infrastructure without explicit inter-agent API calls:
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, exceed_ok=True) if hasattr(Path, 'exceed_ok') else 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}
The companion code reviewer agent intercepts the task in the exact same session, reading the generated artifact directly from disk:

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:nn{code}"))
return {"agent": "reviewer", "read": str(code_path), "review": review}
Packaging these agents requires minimal friction. Developers bring their preferred orchestration frameworks—including CrewAI, LangGraph, LlamaIndex, or Strands—along with any model of choice. By applying a simple @app.entrypoint decorator and packaging the application into a standard zip file or container image, the code is ready for deployment through the AWS Management Console, the AgentCore CLI, or infrastructure-as-code tooling.
Hybrid Topologies: Balancing MicroVMs and Runtime Instances
AWS designed runtime microVMs and runtime instances as complementary compute options rather than competing alternatives. Production architectures can seamlessly blend both paradigms through unified AgentCore runtime APIs.
Under a hybrid topology, a lightweight orchestrator agent running on a fast-scaling microVM handles incoming API routing, task dispatching, and result aggregation. When that orchestrator encounters compute-intensive tasks requiring persistent state, direct operating system access, or GPU acceleration—such as automated security scanning, heavy code compilation, or GUI automation—it offloads the workload to specialized worker agents residing on persistent runtime instances.
This tiered approach addresses financial optimization trade-offs.
Deployment Parameters and Infrastructure Specifications
For engineering teams preparing production rollouts, understanding the underlying boundaries of the release ensures predictable scaling. Supported configurations at launch include:

- Operating Systems: Linux distributions across ARM64 (such as AWS Graviton-based instances like c7g.2xlarge) and x86_64 architectures.
- Session Durations: Stateful sessions persist for up to 14 days, supported by Amazon EBS storage and AgentCore Memory for long-term recall across environments.
- Runtime Environments: Native support for Python versions 3.11 through 3.14 alongside flexible container image deployments.
- Geographic Availability: Deployed across major global hubs including US East (Ohio, N. Virginia), US West (Oregon), Asia Pacific (Mumbai, Singapore, Sydney, Tokyo), and Europe (Frankfurt, Ireland).
By absorbing the operational complexity of network provisioning, IAM role management, and session monitoring into a managed framework, runtime instances clear a major adoption hurdle for enterprise AI teams looking to move past the limitations of transient prototypes.