Multi Agent Collaboration Gets Persistent Compute in Bedrock AgentCore

Matt Saunders · rss · 2026-08-19 source ↗ Reader 🖥️

theoretical · expository — A news-analysis piece: it reports AWS's product announcement (runtime instances for Bedrock AgentCore) and then synthesizes third-party analyses (Enkompass's engineering guide, eCorpIT's cost analysis, Four Signals, daily.dev, LinkedIn commentary) plus a comparison to Microsoft's Azure Foundry hosted agents. It asserts what is true about the new capability and its trade-offs rather than arguing the reader should do anything specific, though it implicitly guides an infrastructure decision (when to choose instances vs. microVMs).

Structure

Key terms

• runtime instances
  A second AgentCore compute option: agents run on managed Amazon EC2 in the customer's own account, for up to fourteen days, with shared file systems and GPU-accelerated instance types, while still using the existing AgentCore APIs, identity and observability model.
• capacity provider
  A new primitive (per the Enkompass guide) that defines allowed instance families, OS, networking and storage, and acts as a contract between agents and the EC2 capacity AgentCore provisions, patches and scales on the team's behalf — including bounds like min/max instance counts and target utilization.
• microVM (as contrasted with runtime instances)
  AgentCore's original, default serverless compute model: fast-starting, per-session-isolated, billed per vCPU-hour and GB-hour, capped at eight hours of continuous runtime.
• agents call each other as tools
  Stormacq's description of the multi-agent pattern instances enable: several specialized agents on one runtime iterate autonomously within a shared session, invoking each other directly rather than each agent calling another agent's API for every handoff.

Propositions

• explicitRuntime instances give AgentCore 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, while keeping the existing AgentCore APIs, identity and observability model.conf: high
  extendsThe Production Gap: 5 Patterns for Building Long-Running AI Agents · p21 — Turing Post's claim that persistence duration (its example: seven days) is an infrastructure/runtime property, not a model property, is extended by a second concrete vendor data point: AWS's runtime instances offer up to fourteen days, reinforcing that these numbers are competitive runtime-layer specs, not model capabilities.
• explicitMultiple agents can be deployed into a single runtime and collaborate on the same host through a shared session directory, calling each other as tools, rather than calling each other's APIs for every handoff.conf: high
• explicitRuntime instances are complementary to microVMs, not a replacement — AWS explicitly recommends mixed topologies where a microVM-based orchestrator dispatches long-running work to instance-based workers.conf: high
• explicitdevelopedMicroVM-based AgentCore Runtime remains the better default for short, bursty, request-response agents because it starts quickly, isolates sessions, and bills per second on actual CPU and peak memory, capped at eight hours.conf: high
  extends ←Presentation: Fixing the AI Infra Scale Problem by Stuffing 1M Sandboxes in a Single Server · p6 — Bedrock AgentCore scopes microVMs as the better default specifically for short, bursty request-response agents; this talk's stateful snapshot-based scale-to-zero removes session length as the discriminator, since even long-idle sessions resume with full state in milliseconds.
• explicitRuntime instances become the economically better choice at roughly 24% sustained CPU utilization or higher (before Savings Plan discounts), because they are billed at standard EC2 rates plus a flat management fee rather than per-vCPU/GB-hour with idle-time exposure.conf: high
• explicitBecause runtime instances run in the customer's own EC2 account, standard EC2 commitment discounts (Savings Plans, Reserved Instances) apply to the compute portion of the bill but not to AgentCore's separate management fee — meaning the vendor-managed layer itself is the part of the cost that cannot be discounted away.conf: high
• explicitcontestedCo-locating several agents on a single runtime instance and explicitly stopping sessions once work completes are the main levers available to control instance-based costs.conf: high
  contradictsThe Production Gap: 5 Patterns for Building Long-Running AI Agents · p6 — Turing Post holds up 'zero compute while waiting, sub-second resumption' as the correctly designed pattern for long-running agent pauses. AgentCore runtime instances explicitly do not achieve this by default — they bill continuously at EC2 rates while a session is up, and this article's own cost analysis treats manually stopping sessions when idle as one of only two available cost levers, implying idle instances keep costing money unless a human or process intervenes.
• implicitAWS's decision to keep the same AgentCore APIs, identity and observability model across both compute options (microVMs and instances) is what makes the new tier low-friction to adopt for teams already using AgentCore.conf: medium
• implicitcorroboratedPersistent, EC2-backed compute for AI agents is not AWS-specific — Microsoft's Azure Foundry hosted agents solve essentially the same problem (per-session VM sandboxes with persistent home directories, state restored automatically after idle periods or restarts), suggesting this is converging as a standard capability tier across major agent platforms rather than a one-off AWS feature.conf: medium
  supports ←Google Open-Sources AX a Kubernetes Style Orchestrator for Autonomous AI Agents · p4 — Google's AX is a third data point (after AWS Bedrock AgentCore Runtime Instances and Azure Foundry hosted agents) that persistent/stateful agent compute is converging as a standard infrastructure capability tier — though AX's actor-suspend model differs architecturally from EC2-backed persistent instances.
• implicitcorroboratedSupport for existing open frameworks (CrewAI, LangGraph, LlamaIndex, Strands) without a change to their packaging model means runtime instances add persistence and multi-agent co-location as an infrastructure layer without imposing framework lock-in.conf: medium
  extendsPodcast: Strands Agents with Clare Liguori · p11 — Liguori described the Strands harness's focus shifting toward 'sustaining long-running, resumable, self-tracking agentic work.' This article shows the concrete infrastructure (AgentCore runtime instances, explicitly naming Strands as a supported framework) that makes that shift operational without requiring Strands itself to change its packaging model.
  supports ←Google Open-Sources AX a Kubernetes Style Orchestrator for Autonomous AI Agents · p9 — Both AX and Bedrock AgentCore Runtime Instances position themselves as an infrastructure layer underneath app-level agent frameworks (LangGraph, CrewAI) rather than replacing them.

Arguments

Narratives

• The AWS blog's worked example: several specialized agents (implicitly for code, tests, documentation and security) operating over a common working directory on a single runtime instance.
  → Illustrates concretely what 'agents call each other as tools within a shared session' means in practice, and implicitly supports the proposition that co-location on shared storage is a materially different collaboration pattern from agents calling each other's APIs.

Questions addressed

• ✅ How should AgentCore support agent workloads that exceed the eight-hour microVM session ceiling, need GPUs/large memory, or benefit from multiple agents working together on the same files?
  By adding runtime instances as a second, complementary compute tier on managed EC2, governed by a new 'capacity provider' primitive, while keeping microVMs as the default for short bursty work.
• ✅ When is runtime-instance compute cheaper than microVM compute, and what specifically drives the difference?
  Roughly at 24% sustained CPU utilization and above, because instances are billed at flat EC2 rates plus a fixed management fee (with EC2-side, but not management-fee-side, commitment discounts) versus microVMs' per-vCPU/GB-hour metering that penalizes idle time less severely at low utilization.
• ⭕ Does adopting the vendor-managed runtime-instance layer create new lock-in, beyond the compute/framework portability AWS advertises?

Gaps

• incompleteThe article never explains how the promised 'shared session directory' and multi-agent co-location interacts with security and blast-radius concerns — if several specialized agents (code, tests, docs, security) share one host and one file system with no API boundary between them, what stops one compromised or misbehaving agent from reading or corrupting another's work? AgentCore's identity and observability model is asserted to carry over unchanged, but identity-per-agent doesn't obviously constrain what agents can do to shared files on the same instance.
  Read next: AWS's AgentCore runtime instance documentation on the shared-session-directory security model; the corpus's existing agent-security material (prompt injection, tool-chaining attacks, blast radius) applied to co-located same-host multi-agent architectures rather than networked agent-to-agent calls.
• incompleteeCorpIT's ~24% sustained-utilization break-even is reported as a bare number with no stated methodology — what instance family, what management-fee rate, what microVM comparison baseline, and how sensitive the figure is to workload shape (e.g., bursty-but-frequent vs. genuinely idle) are all unstated. The article treats a single third party's estimate as if it generalizes across AgentCore workloads.
  Read next: eCorpIT's original cost-analysis article for its underlying assumptions and instance-type-by-instance-type breakdown; any AWS-published cost calculator or case study for runtime instances once available.
• incompleteThe article frames the new pattern ('agents call each other as tools within a shared session') as a smile-inducing convenience, but doesn't address how it relates to — or competes with — AgentCore's own Agent-to-Agent (A2A) protocol support, which InfoQ's own earlier coverage (cited in this same article) established as AgentCore's interoperable multi-agent mechanism. Are these two different multi-agent patterns meant for different scopes (same-host co-location vs. cross-network agent discovery), or does the shared-session pattern quietly sideline A2A for same-vendor multi-agent work?
  Read next: AWS's Agent-to-Agent protocol support documentation for AgentCore (the InfoQ article on A2A support for Bedrock AgentCore cited here) and the corpus's broader agent-to-agent-protocols material, to see whether AWS itself distinguishes when to use shared-session co-location versus A2A calls between AgentCore agents.

Related documents

• Podcast: Strands Agents with Clare Liguori
• Google Open-Sources AX a Kubernetes Style Orchestrator for Autonomous AI Agents
  AI Unit Economics Long-Running & Managed Agents Sandboxing
• The new GPT-5.6 family: Luna, Terra, Sol
  AI Unit Economics Long-Running & Managed Agents Multi-Agent Orchestration
• 10 Things Developers Want from their Agentic IDEs in 2025
  AI Unit Economics Long-Running & Managed Agents Multi-Agent Orchestration
• The Production Gap: 5 Patterns for Building Long-Running AI Agents
  Agent-to-Agent Protocols Long-Running & Managed Agents Multi-Agent Orchestration
• The Agentic P&L: Beyond the Empire of Headcount
  Agent-to-Agent Protocols AI Unit Economics
• AI Sovereignty: Bargaining with Big Tech and the Promise of Full Stack Open Source AI
  Agent-to-Agent Protocols Compute & Energy Infrastructure
• Developer Newsletter: higher usage limits, dreaming for Claude Managed Agents, and Claude Security
  Long-Running & Managed Agents Sandboxing
• Harness design for long-running application development
  Long-Running & Managed Agents Multi-Agent Orchestration
• Anthropic's Designs Three-Agent Harness Supports Long-Running Full-Stack AI Development
  Long-Running & Managed Agents Multi-Agent Orchestration