The Work That Wakes Again

Say you ask an agent to make a mushroom texture. It takes the job, starts a tool call, and then the process just disappears before the result comes back.

You reopen the chat. Your request is still sitting there. Great, that tells you what you asked for. It doesn’t tell you whether the texture got made, whether asking again would make two, or whether anything happens at all if you close the tab.

Those are three different problems. Our first design mixed them up.

(The agent art tools themselves are in the game art note.)

Back in August we wrote down a list of the ways code can say something it doesn’t actually know. Not bugs in general. The specific tricks. Two of them stuck with us:

“Said no” and “couldn’t answer” are different facts. Collapse them and you convict live work off a glitch.

Timers schedule looks; they never convict.

When we rebuilt everything, we kept both. Our field guide still says: “Never turn timeout or unavailability into conviction that work, credentials, or a gate failed unless its owner can say so.”

Here’s why that rule keeps showing up in our code, and in how we work.

(The other half of keeping work alive, who wakes it back up, is in the restart note.)

First, what a Fungi Computer actually is, because it’s easy to get wrong. A Computer isn’t a machine. It’s a durable Workspace: one Durable Object (a small program on Cloudflare with its own database) that holds the agent’s files. That Workspace is the one true copy. Code runs against it through backends. Every Computer has a just-bash shell in a Dynamic Worker, which sends each file operation straight to the Workspace. No machine, nothing to keep awake. When an agent needs real processes, like npm install or a dev server, the Computer plugs in something heavier: a Cloudflare container, or a Firecracker microVM (a tiny, real virtual machine) on our own box.

This note is about that VM, and what “asleep” means for it. Fifteen minutes after the agent’s last turn, the VM is supposed to stop. The files are fine, because they never lived only in the VM. The processes stop. The next turn starts a fresh VM against the same Workspace.

Sleep sounds like the boring part. It’s actually the bill. A VM that’s up is using memory on a real box, and we meter a Computer’s heavy runtime from start to stop, per backing, into the Team’s ledger. A VM that can’t fall asleep would charge someone for doing nothing.

So before any Team got near the VM backing, we ran it end to end on the box, over and over, to prove it slept and woke properly. At first it didn’t sleep, for three different reasons, one after another. Finding those is exactly what the test runs were for.

(The other half of this, who wakes an agent back up, is in the restart note.)