AI Agent Cloud: What the Term Means and Who Actually Has One

"AI agent cloud" started showing up in vendor copy sometime in 2026, and it now means whatever the vendor using it sells. For most of them it means a sandbox: a box you can drop untrusted code into. That is one layer of five, and the other four are where teams get stuck three months in.

I'm Ajay Kumar, an infrastructure engineer with 14 years in this. Disclosure up front: I built one of the platforms on this list — PandaStack, an Apache-2.0 Firecracker microVM cloud I wrote solo over about six months. I've tried to describe it the way I'd describe a competitor, and I'll tell you plainly where it loses — at minimum: Modal is a different class of product if GPUs are in scope and I have none, and Northflank's BYOC into your own cloud account beats "here is the Apache-2.0 source" for any team with a compliance function. It is not the answer to most of the scenarios at the end of this post, and it is the top pick in exactly one of them.

Everything I say about other vendors comes from their own docs, pricing pages and announcements, and I've attributed it. Where a source was secondary or I couldn't verify a claim, I say so rather than smoothing it over. Numbers about my own fleet are ones I measured.

The five layers an agent actually needs

Watch what an agent does over a week rather than over one request, and the sandbox stops looking like the product.

1. Compute isolation. Run code the model wrote without it reaching your other tenants. This is the layer everybody has and the one that gets benchmarked. It's also the one I'd worry about least, because the market has converged on three or four defensible answers — the trade-offs are in choosing agent isolation.

2. Persistent state that isn't a filesystem. Agents accumulate things: scraped rows, embeddings, task queues, the schema they designed for the app they're building. A sandbox filesystem plus a snapshot is a bad database — no concurrent access from outside the sandbox, no query interface, no point-in-time recovery. What agents keep wanting is Postgres, and a branchable one, because an agent exploring three approaches wants three copies of the data without paying for three copies.

3. Hosting for what the agent builds. If your agent writes an app, someone has to serve it. A preview URL that dies with the sandbox is a demo. A stable URL that survives redeploys is a product. This layer has the widest gap between "there's an API for it" and "you'd run a customer on it."

4. Scheduled and triggered execution. Almost no interesting agent is purely synchronous. It wakes on a cron, a webhook, a queue message. If your agent cloud only does "start a sandbox, run this, tear it down," you are going to build a scheduler, and then operate it.

5. Observability into what the agent did. Not CPU graphs. What commands ran, what it reached on the network, what it wrote, and which of those you'd have to disclose if a customer asked. This is the least-served layer in the category, mine included, and I'll come back to it.

Who covers what

Here's the researched picture. ✓ means I found a first-class product for that layer in the vendor's own materials; ~ means partial or platform-adjacent; — means I found nothing, which is not the same as "the vendor could never do it."

Platform	Isolation	Sandbox state	Managed DB	Hosts agent output	Triggers/cron	Self-host
E2B	microVM	✓ pause keeps fs+memory	—	—	—	✓ Apache-2.0
Modal	gVisor	✓ fs + memory snapshots	—	~ platform-level	~ serverless native	—
Daytona	container (VM class too)	✓ snapshots, fork, volumes	—	—	—	— closed 6/2026
Cloudflare Sandbox SDK	container	✓ disk snapshots, sleep/wake	~ bucket mounts	~ preview URLs	~ Workers platform	— (SDK is OSS)
Vercel Sandbox	microVM	✓ persistent by default	—	~ Vercel platform	—	—
AWS AgentCore	microVM	— session-scoped, ~8h	—	—	—	—
Google Agent Sandbox	gVisor / Kata	✓ Pod snapshots	—	—	—	✓ k8s-sigs
Blaxel	microVM	✓ indefinite standby	—	—	~ batch jobs	—
Runloop	microVM	✓ suspend + git-style snaps	—	—	—	— VPC option
Northflank	Kata or gVisor	✓ volumes, long-lived	✓	✓	~ jobs/CI	✓ BYOC
CodeSandbox / Together	microVM	✓ memory snaps, fork	—	—	—	—
Microsandbox	microVM (libkrun)	~ claimed, beta	—	—	—	✓ Apache-2.0
OpenSandbox	pluggable	~ volumes; checkpoint unverified	—	—	—	✓ Apache-2.0
Fly.io Machines	microVM	✓ suspend, volumes	~ platform-level	✓	—	—
PandaStack	microVM	✓ fork trees, hibernate	✓	✓	✓	✓ Apache-2.0 core

A few things I want to flag rather than bury.

Daytona went closed source. Their own June 2026 post says the production codebase moved closed and the public repo "will stay public" but is no longer maintained. Comparison articles published later in 2026 still list it as AGPL open source. That's stale, and if OSS is load-bearing for you, check the date on whatever you're reading.

AgentCore's row is the shape of a deliberate design, not a gap. AWS scoped the code interpreter to session-bounded execution and put state in separate components (S3, AgentCore Memory). My confidence on the specifics here is medium — I did not fetch an AWS-primary page, and the ~8-hour session cap and per-session microVM wording come from consistent secondary sources. Verify against AWS docs before you plan around it.

Broad coverage is not automatically better. Northflank and Fly arrived at it from the opposite direction — they were app platforms that added sandbox-shaped isolation. That order matters: their hosting and database layers have carried production traffic far longer than any sandbox-first vendor's equivalent, including mine.

The layer nobody has

You'll notice my table has no observability column. That's because there was nothing honest to put in it.

Of the fifteen platforms, the only first-class agent audit story I found is AWS's CloudTrail integration for AgentCore. Everyone else, me included, offers logs. Logs are what you have when you haven't built observability. When a customer asks "what did your agent do inside my account on Tuesday," a log tail is not an answer.

PandaStack does not solve this either. I have per-sandbox lifecycle events and egress controls, and I can tell you a sandbox reached a blocked host — I built that after a free-tier signup mined crypto on my fleet. What I cannot hand you is a coherent per-agent activity record. Whoever ships that well will make "agent cloud" mean something distinct from "sandbox API," and it won't be me who ships it first.

The cost question: idle, not runtime

Agent traffic is bursty and mostly idle. A coding agent thinks for forty seconds, runs a test for three, thinks again. A scheduled research agent runs two minutes an hour. Size your cost model on runtime and you'll be wrong by an order of magnitude, because the bill is dominated by the gaps.

Almost every platform here bills per second, which sounds like it settles the question. It doesn't. There are three states, treated differently:

Platform	Running	Idle but alive	Suspended
AWS AgentCore	vCPU-time + memory	memory billed every second alive	n/a — no suspend primitive
Cloudflare Sandbox	active CPU (10ms) + provisioned mem/disk	provisioned memory and disk	sleeps on idle; snapshot storage
Vercel Sandbox	active CPU + provisioned memory	provisioned memory	snapshot storage
Fly.io Machines	per second while started	per second while started	rootfs storage per GB-month
Blaxel	per second vCPU/RAM	per second	standby not billed as compute
E2B	per second vCPU/RAM/storage	per second while running	paused sandboxes kept; storage
Northflank	per second, pro-rated	per second	n/a for always-on services
PandaStack	active CPU + working-set memory	working-set memory	$0 compute

The trap: "active CPU billing" and "no idle bill" are different claims, and the first gets marketed as the second. AgentCore is the clearest illustration — CPU billed only for cycles actually burned, which is genuinely good, and memory billed for every second the session is alive, which is where a mostly-idle agent's money goes. Cloudflare and Vercel both bill CPU on activity and memory on provisioned size. Defensible — provisioned memory is real memory somebody is holding for you — but not zero.

So the question isn't "do you bill per second." It's: what does my bill look like for a sandbox that exists for one hour and burns CPU for ninety seconds of it?

The only way to reach zero is to stop holding the memory, which means suspending to disk and paying restore latency on the way back. I built that path and would caution against assuming it's free engineering: my hibernate took 50 seconds and my wake was 14 — not the 1.3 I had been reporting — and fixing it consumed a chunk of a quarter (the full accounting). Wake now sits near 1.2s, fine for a background agent and unacceptable for an interactive one. Mechanism and limits are in the scale-to-zero docs.

How to choose

Work in this order. It eliminates fastest.

Start with layers 2 through 5, not layer 1. Every platform on this list will run untrusted code acceptably for most threat models. Far fewer will still be a fit once your agent needs a database it can branch, a URL that outlives the sandbox, and a cron trigger. Choosing on boot latency and then discovering you need a scheduler is the common failure, and it's expensive because by then you've written SDK code against the sandbox API.

Then ask where it runs. If BYOC or self-hosting is a requirement — regulated data, a security team with opinions, an existing cloud commit — the field collapses to about five: E2B, Google's Agent Sandbox, Northflank, the two Apache-2.0 projects, and mine. Northflank is the strongest if you want BYOC into your own account with a vendor operating it, and it offers per-workload selectable Kata or gVisor, which nobody else here does.

Then check the state model against your actual access pattern. "Snapshots supported" covers wildly different semantics. E2B's docs state paused sandboxes are kept indefinitely until you kill them, but the default timeout will kill your work unless you explicitly set the pause-on-timeout behaviour. Cloudflare's disk resets to the image across a sleep unless you snapshot. Vercel made persistence the default. Those are three different contracts wearing one word, and the difference surfaces in production, not in the demo.

Then run the three-state cost model. Above. Do it with your own duty cycle, not the vendor's example.

Then, last, isolation. By this point you'll usually have one or two candidates left anyway.

A checklist for evaluating an agent cloud vendor

Print this and make them answer it.

• What is billed while a sandbox is idle but alive? Get CPU, memory and storage separately. Not a rate card — a worked example at your duty cycle.
• What survives a suspend, exactly? Filesystem only, or memory too? Do open sockets survive? Unflushed writes? I got this wrong in my own docs once and only found out from a smoke test.
• How long can a sandbox live? Session caps range from minutes to indefinite across this list. AgentCore is session-scoped; Northflank explicitly markets unlimited session length against competitors' 24-hour caps.
• Where does persistent structured state live? If the answer is "the sandbox filesystem," you are building a database.
• What happens to the URL when the sandbox is replaced? If it changes, you don't have hosting, you have previews.
• Can I trigger a run from a cron, a webhook and a queue, without operating a scheduler?
• Can I produce a per-agent activity record for a customer or an auditor? Expect a weak answer. Notice who admits it.
• If the vendor disappears or changes licence, what do I do on Monday? Daytona's June 2026 close is the live example. Check whether an OSS repo is maintained or merely public.
• Is the open-source version the same software as the hosted one? Ask me this one too — see below.
• Who operates it, and what's their incident history? Ask for postmortems. If they won't share any, that's information.

Where PandaStack loses

Since I'm on the list, here's the part I'd want if I were reading this.

No GPU story at all. If your agent does inference in the same place it runs code, Modal is a different class of product and I'm not a candidate.

One operator. I run this fleet alone. That has been survivable and I've written up the incidents honestly, but Google's launch post reports allocating 300 sandboxes per second, a rate I will never match, and AWS and Cloudflare have on-call rotations I do not have. If your risk model cares more about the operator than the architecture, buy from a hyperscaler.

The public repo is a curated cut, not the live history. pandastack-io/pandastack-ai is Apache-2.0 and real, but it's a squashed export — you can't judge development activity from its commit graph, and it excludes components the hosted product has. E2B's infra repo is a genuinely living Apache-2.0 codebase with self-host Terraform for GCP (stable) and AWS (beta), and if auditable, continuously-published open source is what you're buying, theirs is the stronger artifact today. That's a fair hit and I'd rather say it than have you find out.

Guest kernel constraints. I run a 5.10 guest kernel and it has blocked features I wanted to ship. Platforms built on containers or gVisor don't have that particular problem.

What I'd defend: create is a snapshot restore every time, p50 179ms and p99 203ms measured to a TCP probe on the guest (the full stage breakdown); same-host copy-on-write fork lands in 400–750ms; idle bills nothing; and layers 2 through 4 are actual products rather than roadmap — branchable Postgres with PITR and git-driven app hosting.

What I'd pick for what

• Code interpretation inside an existing agent, and you want to read and self-host the source today — E2B. The maintained-OSS argument is the strongest one in this category.
• Inference and agent code in one platform, GPUs involved — Modal. Nothing else here competes.
• You already live on Cloudflare Workers, or on Vercel — use their sandbox. The integration is worth more than any latency difference, and both bill CPU on activity.
• BYOC into your own cloud account, compliance team involved, selectable isolation — Northflank.
• Regulated AWS shop where the audit trail is the requirement — AgentCore, after you verify the session model against AWS's own docs.
• You're a Kubernetes platform team and sandboxes should be a CRD — Google's Agent Sandbox, or the upstream k8s-sigs project.
• Coding-agent evaluation harnesses and SWE-bench-style work — Runloop, which built for that specific shape.
• Your agent builds and ships an app with a database attached, cost at idle matters more than peak throughput, and you want the source — that's the narrow slot I built for, so PandaStack. If any of those three conditions is soft, pick something above.

The term "AI agent cloud" will mean something once one of these vendors makes the observability layer real. Until then it means sandbox, and you should evaluate it as one — while checking, carefully, what you'll have to build yourself for the other four layers.

For layer 1 on its own: what an agent sandbox actually is at the systems level, the six runtimes underneath the APIs, and a per-vendor roundup of the sandbox market.

---

Ajay Kumar is an infrastructure engineer with 14 years of experience and the creator of PandaStack, Riff and PandaFlow. He is available for infrastructure consulting — microVM platforms, Firecracker, multi-tenant isolation — at linkedin.com/in/ajay-kumar-devops.