The Problem

There isn't enough compute in the world to give every agent its own container.

A container per agent does not scale to hundreds of millions, then billions, of concurrent agents. That shortfall is why the industry is scrambling for CPU compute, not just GPU compute.

1 : 1
Container per agent — today's default
109
Concurrent agents the default must survive
Seconds
Cold start paid before any real work begins
The insight
The Insight

Separate the hands from the brain.

The agent loop is the brain; the sandbox where work actually lands is the hands. Once they are separated, the hands no longer have to be a container — an isolate can hold the pen for most of the job.

“This separates the hands (the sandbox where work is done) from the brain (the agent loop).” Matt Carey & Aron Carroll · The Cloudflare Blog
The brain and the hands, separated An agent loop labelled "the brain" sends operations rightward into a workspace labelled "the hands". The workspace returns results back to the brain. The hands are backed by an isolate by default, and only escalate to a container when the task genuinely needs one. THE BRAIN agent loop · model decides what to do THE HANDS one durable workspace ISOLATE default CONTAINER only if needed operations → ← results the brain never changes — only which pair of hands picks up the task
Isolates are the hands. The container becomes an escalation, not a prerequisite.
Cloudflare's Bet

One workspace. Three engines.

@cloudflare/computer keeps a single durable workspace and swaps the engine underneath it per operation. Agents are surprisingly good at picking the right environment for the task, so the cheapest engine that can do the job is the one that runs.

Three pluggable engines behind one workspace A single workspace sits at the top. Below it, three interchangeable slots plug in: an isolate JavaScript engine, a just-bash worker engine, and a container engine. Every slot reads and writes the same files, and each operation is recorded in the Engine Ledger. ONE WORKSPACE durable filesystem · shared by every engine ISOLATE JS parse · diff · patch ~0 ms cold start JUST-BASH grep · find · git log shell, no VM CONTAINER npm install · test suite real Linux userland ENGINE LEDGER — every operation recorded with the engine that ran it
Three pluggable slots, one filesystem. The Engine Ledger records which slot handled each operation.
Isolate JS

Structured work

Parsing findings, indexing an OpenAPI schema, diffing observed fields against declared ones, writing the patch.

IsolateJavaScriptBackend
Just-bash

Repo archaeology

Locating the serializer and reading git history — shell ergonomics without booting a machine to get them.

WorkerBackend
Container

Real userland

Installing dependencies and running the test suite — the one job that genuinely needs a full Linux environment.

ContainerBackend
Live

Security Triage Agent Demo

API Shield flags GET /api/orders/{id} returning undeclared PII — email, phone and a partial card number absent from the OpenAPI schema. The SecurityTriageAgent works the finding across nine steps and stops at a commit for human review.

Eight of those steps never leave an isolate or a shell. Step 8 is the only one that reaches for a container.

idle
Workspace Files durable
  • Reading the workspace…
Step Timeline no steps
  1. No run yet. Press Live Run.
Isolate JS Just-bash Container The agent picks its own engine per step. Every badge below is read back from the Engine Ledger.

The goal

<10% of the work

“Our goal with @cloudflare/computer is to provide an agent with a runtime where a container is required for less than 10% of its work.”

Matt Carey & Aron Carroll · The Cloudflare Blog

The Engine Ledger computes container share as container operations over total operations, every time it is read. Whatever the number says on stage is the number the run actually produced.