On August 6, 2026, AWS announced Amazon Bedrock AgentCore Runtime Instances as a second production compute option alongside the existing microVM runtime. AWS manages the underlying EC2 infrastructure, allowing agents to keep sessions and compute resources in a more persistent environment instead of starting a short-lived sandbox for each request.
Runtime Instances can run multiple agents in one runtime and support shared sessions for up to 14 days. AWS also lists stop and restart, GPU, and container deployments. That model fits long-running tasks, workflows that keep a working directory, and agent-to-agent handoffs, but a longer session also makes permissions, cleanup, and isolation more important.
AWS says Runtime Instances can work with EBS and AgentCore Memory. EBS provides persistent storage, while Memory handles longer-term recall across sessions; they represent different kinds of state. Teams using both need explicit rules for what is a temporary work artifact, what can enter long-term memory, and how long each class of data should be retained.
The option continues to use AgentCore APIs, identity controls, and observability. AWS presents it as a compute choice within the same agent platform rather than a separate deployment model. Runtime Instances also support agent-to-agent communication: one agent can call another as a tool while sharing a filesystem and session context.
AWS says the environment is framework- and model-agnostic, with support for tools such as CrewAI, LangGraph, LlamaIndex, and Strands. The platform supports Linux ARM64 and x86_64, Python 3.11 through 3.14, containers, and GPU workloads. AWS lists launch regions including US East Ohio, Virginia, and Oregon, plus Mumbai, Singapore, Sydney, Tokyo, Frankfurt, and Ireland.
The cost model differs from a short-lived invocation. AWS says Runtime Instances use standard EC2 pricing plus an AgentCore management fee. Actual cost will depend on instance type, GPU, runtime, storage, traffic, and region. Those are AWS’s product and pricing statements; teams should check current regional documentation and model their own load instead of estimating from token cost alone.
For production agents, the value is a single managed compute boundary for sessions, tools, files, and agent-to-agent collaboration. The tradeoff is operational work around stale credentials in long sessions, cross-agent data permissions, idempotency after restart, GPU utilization, and tenant isolation. Persistent compute reduces startup friction; it does not automatically solve workflow reliability.
The update shows agent infrastructure moving from “one runtime per call” toward choosing persistent or ephemeral execution based on the job. Short tasks can stay in a lightweight sandbox, while long tasks or stateful workflows may fit Runtime Instances. The decision should still be driven by session lifetime, data governance, observability, recovery behavior, and total cost.
