Cloud Agents Are Earlier Than They Look. The Machine Was Never the Point.

A disclaimer first: I do not build cloud infrastructure. I read these two posts from the outside, as someone who uses agents all day and keeps wondering what happens when everyone else does too.

What I am seeing

More and more of the agent's work is moving off the laptop and into the cloud. Manus allocates a full cloud VM per task. Grok Bot, which xAI launched in August, goes further: every account gets a persistent cloud computer with a browser, a filesystem, and a terminal, and your bots live on it. The official docs put the pitch in one line: "Context compounds instead of resetting to a fresh environment on every task." The bot finishes the job and only comes back when it needs your approval.

As an experience, I think that is exactly right. What I keep wondering is how many people it can carry.

Cloudflare: the machine is the bottleneck

In early August, Cloudflare published a post introducing @cloudflare/computer, and one line stuck with me. Across every cloud provider and hyperscaler, they write, there is nowhere near enough compute in the world for every company to give every user's agent its own container. That model, in their words, cannot scale to hundreds of millions or billions of concurrent agents.

Their answer is to split the agent in two. The brain, the agent loop, runs in an isolate, the lightweight primitive behind Workers and Durable Objects that starts and stops in milliseconds and hibernates when idle. The hands, meaning anything that truly needs Linux, npm, or a native binary, get a container only when a task calls for one. The filesystem lives outside the container entirely: a SQLite-backed virtual filesystem in the Durable Object, mounted into the container over FUSE when needed and synced back. The model picks the backend per command, and they say frontier models are good at only falling back to the container when they must. Their stated goal is for containers to show up in under 10% of workloads.

Cloudflare sells isolates, so this post has a position. But the underlying complaint is not only theirs. In E2B's 2025 case study, the Manus team said their first attempt used Docker, which took 10 to 20 seconds to spawn and was not a full operating system, before they moved to Firecracker microVMs. One agent, one machine has been a known problem for a while.

Maka: the state was never in the machine

The second post is a design doc from Apache Maka called "Log Is the Runtime." It is more engineering than manifesto, and I think it supplies the half Cloudflare's post leaves implicit.

It borrows an old idea from databases: the log is the database, and tables are just projections computed from it. Applied to agents, the argument goes like this. Language models are stateless across calls. Every step, the runtime has to rebuild the context from scratch anyway. So the agent's state is not something that lives in a process. It is a projection over the history of events: user messages, tool calls, tool results, permission grants, in strict order.

Maka stores that history as typed events in an append-only log, and derives everything else from it. The same log projects into four different things: the chat UI a user sees, the context the model sees on the next turn, whether a run ended in success or failure, and where a new process should pick up after a crash. Compaction never rewrites the log; it only changes how later reads summarize the older prefix. Oversized tool outputs get archived and replaced by a placeholder the model can query on demand. Because the facts are preserved, you can later re-read the same history with a better model.

The line I keep coming back to: the model decides what to do next, and the log guarantees the runtime can always reconstruct what already happened.

Putting the two together

My reading, and it is only a reading, is that these two posts describe the same shape from opposite ends.

An agent's state is two things: an event log and a filesystem. Put both in cheap storage. The compute then becomes a disposable tool. When the agent needs to run npm, spin up a container, mount the filesystem, run it, tear it down. There is nothing to snapshot, because nothing was ever inside the container to begin with. Cloudflare solves the hands: where the files live and when a real Linux box is worth paying for. Maka solves the brain: where the history lives and how each consumer reads it. Resume, crash recovery, audit, and history that survives the process all fall out for free.

Manus is the interesting contrast. Their state lives inside the VM, so the sandbox has to sleep and wake, and when it is recycled after 7 or 21 days of inactivity, only artifacts and uploads come back; intermediate files are gone. That is the "put it in the machine, then figure out how to save it" path. Cloudflare's design is the "never put it in the machine" path.

Why /new should disappear

This also explains something that has bothered me for a while. On a persistent agent like Grok Bot, having to hit /new and wipe the conversation would feel backwards. The whole pitch is that context accumulates.

I think /new exists because today's tools treat the context window and the history as the same object. When they are one thing, the only fix for a full or noisy context is to throw it away. Once the log is the history and the context is a projection, how much history to show becomes the runtime's decision, not a button the user presses. The storage side is the easy part; a year of text events is nothing next to compute. The hard part is projecting it well, because even an infinite context window does not make re-reading ten million tokens per turn affordable. My guess is that as memory systems get better at exactly that, /new fades out on its own.

What is still open

A few things neither post settles, and I do not have a good answer for either.

The third kind of state. Logs cover history and the external filesystem covers files, but a browser session that is halfway through a login, or a test suite twenty minutes in, lives in neither. Grok Bot's answer is to keep the machine on, which I assume is part of why it launched on the top-tier plans only. Whether that layer should be designed away with short, retryable tool calls, or checkpointed, I do not know.

Replay is not re-execution. The log can rebuild the model's context, but the email that was sent and the PR that was opened do not un-happen. Maka is explicit that if a crash lands between a tool being dispatched and its result being recorded, and safety cannot be proven, the runtime blocks rather than retrying blind. That seems right, and also hard.

And log growth is real. Maka says so itself: the trade is a log that never stops growing, versioned projections, and lifecycle management for everything archived.

Where I think this goes

Cloud agents are going to be big, and I think they are earlier than they look. Not because the models are not ready, but because the shape of the agent runtime is only now being defined. Grok Bot has the right experience with an implementation that cannot carry everyone. Cloudflare and Maka, from opposite ends, sketch how you might get the same experience out of a log and cheap storage.

Whoever ships that combination, a persistent teammate that never resets and does not need a machine kept warm for it, is probably building the next layer of the cloud.