When an agent needs to run continuously for days — maintaining state, watching for events, serving a single user — the compute requirements look nothing like a typical web service. But when that same agent needs to spin up for a single task and tear down afterward, or handle millions of lightweight requests at the edge, a different runtime model entirely becomes necessary. The agent infrastructure layer is splitting into five distinct execution philosophies, each reflecting a different bet on how autonomous systems should actually live.
Google Cloud Run: The Singleton Bet
Google’s approach is the most architecturally conservative. Cloud Run instances, in preview since August 2026, provide dedicated singleton compute with no autoscaling — one instance per agent, running continuously for up to seven days at $5.70 per month for 1 vCPU and 1 GiB of memory. The model is designed for personal agents like OpenClaw that expect exactly one copy running at all times. “We’re currently using Cloud Run instances as our primary infrastructure for our long-running agent,” said Luis Ruiz Morel, Member of Technical Staff at OffDeal. “It reduced cold starts by 88%.” The bet here is that agents are long-lived, stateful entities — more like persistent pets than ephemeral workloads — and the runtime should reflect that by providing predictable, always-on compute.
AWS AgentCore: Elastic MicroVMs
AgentCore Runtime V2, which reached general availability on September 18, makes a different bet: agents benefit from serverless efficiency with dedicated isolation per session. The V2 runtime introduces elastic memory reclamation — memory allocated during a session is reclaimed when no longer actively used, so developers pay for actual consumption rather than peak allocation. Snapshot-based cold starts bring P75 startup times to 1.9 to 2.0 seconds for container images from 200 MB to 2 GB, compared with 5.4 to 30 seconds under V1. Each session runs in a dedicated microVM with hardware-enforced isolation, supporting MCP, A2A, and HTTP protocols. For longer-lived workloads, AgentCore Runtime Instances (generally available since August) run on AWS-managed EC2 in the customer’s account with sessions up to 14 days and GPU acceleration. AWS is betting that the right unit of compute for agents is a disposable microVM — spin up fast, work hard, reclaim memory, tear down.
Cloudflare: The Edge-First Hybrid
@cloudflare/computer, an early preview launched August 3 during Agents Week, challenges the container-centric model entirely. The runtime dynamically selects between fast V8 isolates for lightweight tasks and full Linux containers only when needed — and Cloudflare says containers are required for less than 10% of agent work. The agent harness runs inside a Durable Object isolate, calling attached containers on-demand as tools. Both environments share a durable filesystem kept in sync. “Your agent needs a computer, not a container,” Cloudflare’s Matt Carey and Aron Carroll wrote, framing the approach around the argument that giving every agent a container will not scale to hundreds of millions of concurrent agents. Isolates spin up in under 1 millisecond across 300-plus global points of presence. The bet is that horizontal scale demands lightweight compute, and containers should be a tool the agent calls, not the house it lives in.
DigitalOcean: The Gateway-Centric Model
DigitalOcean launched Managed Agents into public preview on September 21 with a two-service architecture: Harness Runtime for execution and Action Gateway for tool access. Harness Runtime uses Firecracker microVMs with per-second CPU billing — sessions start in 886 milliseconds and resume from pause in 305 milliseconds, with charges dropping to zero during idle periods. Action Gateway is a managed MCP endpoint providing governed access to more than 16,000 tools across 500-plus providers, with credentials brokered at execution time so they never reach the model. DigitalOcean reports 99.3% tool-matching accuracy in internal testing. The bet here is that the bottleneck for agents is not compute but tool integration — managing authentication, permissions, retries, and monitoring across dozens of external systems. “It’s been a huge force-multiplier for our team,” said Murad Mordukhay, CEO and co-founder of Qencode. “It gets the right ticket to the right person without anyone having to watch every thread themselves.”
The Blueprint Alliance: Governance as Infrastructure
The Blueprint Alliance, announced at Oktane on September 22, is not a runtime. It is a governance layer designed for enterprises running agents across multiple runtime environments. Twelve vendors — Okta, AWS, CrowdStrike, Databricks, Docker, Google Cloud, Lovable, Proofpoint, Salesforce, ServiceNow, Wiz, and Zscaler — co-authored an open reference architecture supporting MCP, OCSF, SSF, and CAEP. “The risk of unsecured, ungoverned agents is fundamentally an industry problem, not a problem for one company,” said Eric Kelleher, Okta President and COO. The Alliance’s existence is itself evidence of fragmentation: if a single runtime model were winning, a cross-vendor governance coalition would be unnecessary.
What This Means for Builders
The five models force developers to align runtime selection with their agent’s lifecycle. A personal assistant that runs continuously and costs predictable monthly compute fits Google’s singleton model. A multi-agent system requiring elastic scale and hardware-isolated sessions points to AWS. Agents handling millions of lightweight, latency-sensitive edge tasks belong on Cloudflare. Tool-heavy workflows that need governed access to enterprise systems without credential exposure fit DigitalOcean’s gateway approach. And any enterprise deploying agents across multiple runtimes needs a governance layer — which is what the Blueprint Alliance is building.
The portability question is already pressing. An agent designed for Cloudflare’s isolate-first model cannot be trivially migrated to Google’s singleton runtime without rearchitecting its lifecycle. The protocol standardization happening around MCP addresses interoperability at the tool layer, but not at the runtime layer. Whether runtime portability will matter — or whether agents will simply be built for one model and stay there — is the open question that will shape the next phase of the agent infrastructure economy.