# Multi Agent Collaboration Gets Persistent Compute in Bedrock AgentCore > Source: > Published: 2026-08-19 08:00:00+00:00 Amazon Web Services has introduced runtime instances in [the Bedrock AgentCore news blog](https://aws.amazon.com/blogs/aws/runtime-instances-persistent-compute-for-production-ai-agents-on-amazon-bedrock-agentcore/), adding a second compute option that runs agents on managed Amazon EC2 in a customer account while keeping the existing AgentCore APIs, identity and observability model. The feature is aimed at teams whose agents no longer fit neatly into the eight hour microVM ceiling that AgentCore launched with, based on serverless microVM based sessions. In the announcement, principal developer advocate Sebastien Stormacq explains that runtime instances give agents persistent EC2-backed sessions that can run for up to fourteen days, with shared file systems, GPU accelerated instance types, and support for Python and container images. Multiple agents can be deployed into a single runtime and collaborate on the same host through a shared session directory, rather than calling each others APIs for every handoff. Stormacq notes that teams can bring frameworks such as CrewAI, LangGraph, LlamaIndex and Strands without changing their packaging model, using a simple `@app.entrypoint` decorator and either a zip file or container image. 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. - Sebastien Stormacq The blog post uses an example which illustrates the multi-agent collaboration pattern that runtime instances are designed to support, where several specialised agents operate over a common working directory for code, tests, documentation and security artefacts. AWS positions runtime instances as complementary to microVMs rather than a replacement, and encourages mixed topologies where an orchestrator agent on microVMs dispatches long running work to workers on instances. InfoQ has covered the progression of AWS's AgentCore functionality, from the original [AgentCore launch](https://www.infoq.com/news/2025/07/amazon-bedrock-agentcore-launch/), through [Agent-to-Agent protocol support](https://www.infoq.com/news/2025/11/a2a-amazon-bedrock-agentcore/) for interoperable multi-agent workflows, to the [Agent Registry](https://www.infoq.com/news/2026/04/aws-agent-registry-preview/) and the Loom reference platform for governed agent deployments. 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. Sebastien Stormacq An engineering guide from [Enkompass](https://enkompass.net/2026/08/13/bedrock-agentcore-runtime-instances-engineering-guide/) goes deeper into the new capacity provider primitive that underpins runtime instances. A capacity provider defines allowed instance families, operating system, networking and storage, and acts as a contract between agents and the EC2 capacity that AgentCore will provision, patch and scale on their behalf. Teams set bounds such as minimum and maximum instance counts and target utilisation, and then attach one or more agent runtimes to that provider with a session time to live of up to fourteen days, avoiding the need to manage Auto Scaling groups, launch templates or AMI pipelines directly. Enkompass also stresses that runtime instances are best suited to workloads that need longer than eight hours of continuous runtime, require GPUs or large memory footprints, or benefit from several agents co-located on the same host for tight collaboration. The microVM based runtime remains the default choice for short, bursty, request response style agents, because it starts quickly, isolates sessions and bills per second on actual CPU and peak memory up to eight hours. The guide expects most organisations to run both models side by side, placing high volume, short lived traffic on microVMs and reserving instances for a smaller set of long running, stateful or accelerator heavy workloads that previously forced teams to maintain separate EC2 fleets. A cost analysis from [eCorpIT](https://ecorpit.com/bedrock-agentcore-runtime-instances-ec2-cost-decision-2026/) focuses on the financial trade offs between runtime instances and microVMs. Runtime instances are billed at standard EC2 rates for the chosen instance type in the customers account, plus a management fee. In contrast, microVMs charge per vCPU hour and per GB hour with no separate management fee, and can be cheaper for agents with low sustained CPU utilisation and long idle gaps. The cost analysis suggests a break even at roughly 24% sustained CPU utilisation for runtime instances, before any Savings Plan discounts. Because runtime instances run in the customers account, EC2 commitment discounts such as Savings Plans and Reserved Instances apply to the compute portion but not to the management fee. The article argues that co-locating several agents on a single host and stopping sessions when work completes are the main levers for keeping instance based costs under control. Community reactions have highlighted these integration points. A short analysis on [Four Signals](https://foursignals.dev/wire/2026-08-07/runtime-instances-persistent-compute-for-production-ai-f99c48) describes runtime instances as a major infrastructure launch aligned with the rise of agent orchestration platforms and notes the hybrid pattern of microVM orchestrators dispatching work to instance based workers. A summary on [daily.dev](https://daily.dev/posts/runtime-instances-persistent-compute-for-production-ai-agents-on-amazon-bedrock-agentcore-ex8xt1xhg) emphasises the fourteen day session limit, shared file systems and support for popular agent frameworks as key practical benefits for development teams. On LinkedIn, engineer [Kosti Vasilakakis](https://www.linkedin.com/posts/kcvasilakakis_runtime-instances-persistent-compute-for-activity-7491525948748509184-IcPU) noted that runtime instances reuse the same AgentCore APIs and session pinning model that existing teams already use, reducing friction in adopting the new compute type. Microsoft has taken a similar approach through [Azure Foundry hosted agents](https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/hosted-agents). These provision per-session virtual machine sandboxes with persistent home directories and file storage, restoring state automatically when sessions resume after idle periods or restarts. [The documentation](https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/hosted-agents) describes how the service supports multi-agent runs with managed lifecycles across Teams and Microsoft 365 Copilot. AWS documentation is available at [the AgentCore runtime instance page](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-instances-how-it-works.html).