Always On, Mostly Asleep

A Promise and a Property

Always-on is what the products promise. Durable is what the engineers build. They are not the same claim, and the gap between them is where the interesting decisions live.

Always-on describes an experience: you put your phone down and the work keeps moving. Every launch this autumn led with it. A dot, in the launch coverage, runs continuously on its own cloud computer. Anthropic says Duet “doesn’t require your laptop or phone to be on.” Meta says Muse keeps working even when its app is closed.

Durable describes a property of the system underneath: whether a run survives the things that end programs, like a crash, a deploy, a machine being reclaimed or a week of silence. Lee Robinson, who works on Grok Bot, gave a Stanford class the whole requirement in one breath: an agent that “can run on a server, it can run in the cloud, you can close your computer, it can restart, it can survive crashes.”

The two come apart in a particular way. None of these agents is literally running all the time. Grok Bot’s computer is put to sleep between jobs, because, Robinson says, “there’s not enough computers in the world” to keep one running for everyone. Duet looks at your accounts every few hours, not continuously. And a close reading of Pi Durable says it outright:

“Durable does not mean always running, and it does not mean indestructible storage.”

— on Pi Durable, stacktoheap.com, 5 Oct 2026

What feels like an agent that never stops is really an agent that can stop safely. It sleeps, it is woken by the right thing, and it picks up exactly where it left off. Always-on is the experience; durability is how it gets paid for.

The word is borrowed, not coined. Asked where it came from, Armin Ronacher of Earendil traced it to durable workflows: Cadence, which “later turned into Temporal,” and before that a .NET workflow engine, all built around one idea: “how do you express long-running computation where you can serialize out all the states in between so that you can continue off where you left off.” For years that meant jobs like a reminder scheduled fifteen days after someone signs up. What changed in 2026 is that the long-running computation became an agent.

Four Parts, in Every One of Them

Robinson’s lecture is the most detailed public account any maker has given of how one of these is built. Take the brand off and the same four parts show up in all six.

1. A trigger

   A message, a Slack ping, an email, a schedule, a meeting it was sent to. Something other than you typing has to be able to wake it, and a router decides whether the news is worth interrupting you for.

2. A loop with a memory

   The week-one harness, a model calling tools in a loop, moved onto a server with its state written down. Grok Bot keeps the loop off the VM on purpose: “you want to save everything on the server so you can always kind of rebuild that virtual machine.”

3. A borrowed computer

   A Linux machine with a browser, for the sites that have no API. Grok Bot’s is a Firecracker VM because it is “very easy then to essentially snapshot the state of the machine and shut it down and start it back up.”

4. A gate

   Before anything that cannot be undone, something checks: a second model reviewing each command, a permission service holding the real credentials, or you.

Durability lives in the second part. Robinson’s example is a task of three steps that crashes on the third. Choose how the run comes back:

Pi Durable has a name for what happens on step 3. Mario Zechner calls each step an effect sandwich: store the intent, do the thing, store the result. A crash in the middle leaves a record of what was about to happen but not whether it did. A read can simply run again. Bash, “the big bad monster in the room,” cannot, so it goes back to the model as interrupted, with the job of checking what actually happened.

That is also where Pi breaks with the tradition it borrowed the word from. Temporal re-runs your code to find its place again, which needs, in Ronacher’s words, a “100% level of determinism” and loses the thread whenever the code changes. Pi Durable writes the place down instead: “you don’t have a call stack, you have a linear transition from state to state.” The reason is the new reader. Models, Ronacher says, “prefer the explicit way.”

What Each One Has Told Us

Every field is the maker’s own description unless a card says otherwise. Where a maker hasn’t said, the card shows the gap instead of guessing, and the gaps are not evenly spread.

Read the cards across rather than down. Every consumer launch describes its gate in detail: Sentinel, Custom Rules, approval before payment. None describes what keeps a run alive. The only full accounts of durability come from an open-source framework and a lecture to students. The part users are asked to trust is documented, and the part that decides whether the agent is still there tomorrow mostly isn’t.

One Name, One Place, Its Own Memory

Six years before any of these launches, Cloudflare shipped a primitive whose name already held the answer.

On 28 September 2020, Kenton Varda introduced Durable Objects. The name makes three claims. An object is code with private state. It is unique: “each object has a globally-unique identifier,” and the object “exists in only one location in the whole world at a time.” And it is durable: its storage is private to it, and “always co-located with the object.”

What made it a home for agents came later. Alarms let an object wake without anyone calling it. WebSocket hibernation let it leave memory while its connections stay open. In September 2024 each object got its own SQLite database. When Cloudflare built its Agents SDK, every agent simply became one of these, and in April 2026 Sunil Pai put the economics plainly: an agent “consumes zero compute when hibernated.” His example is below.

Pi Durable already runs inside one. Through Cloudflare’s PiHarness, Pi keeps its transcripts, inbox and tasks in the object’s own SQLite. While a run is in progress, a heartbeat goes out every 30 seconds. If the object is evicted mid-run, an alarm brings it back and the run carries on. It has to: each alarm gets at most 15 minutes, which the Pi team describe as the object being “killed hard,” and an agent that needed a human to type “continue” after every one would not be an always-on agent at all.

Here is why it is the more interesting tool. The consumer products give an agent a computer: a body it borrows in order to act. A Durable Object gives an agent an address: a name that always leads to the same place and the same memory, whether or not anything is running there. Those are two answers to what it means for an agent to persist. The second is closer to what we mean when we say a person is around: not awake every moment, but reachable, and still themselves when reached.

Two limits keep this honest. None of the six consumer products says it runs on Durable Objects; this section is about a shape, not their stacks. And Cloudflare’s own documentation is clear that anything held only in memory is gone when an object is evicted. Durability covers what you write down, nothing more.

Surviving Is Not the Same as Being Right

Durability makes an agent harder to lose. It does nothing to make it easier to trust, and in one way it makes trust harder: a mistake that survives a crash survives everything else too.

The same review of Pi Durable lists what checkpoints do not promise. They do not guarantee “exactly-once external effects.” Saving an approval does not prove the approved action ran. And “cancelling a wait does not cancel the work”: closing the window you were watching from stops nothing.

Robinson ended his lecture on a problem no maker has solved. If an agent runs for a month and a new model ships every month, its behaviour can never be fully evaluated before the model under it changes: “You either have to figure out how to do a better eval or not ship models as fast.” He was just as candid about a quieter problem, the line between proactive and annoying: “I don’t think that we have it perfect yet.”

Harness², released on 9 October by researchers at Google Cloud AI Research and Northwestern University, comes at that problem from the other side: keep the model still, and let what surrounds it learn. Pi Durable is for agents that keep running; Harness² is for agents whose harness gets better while they run. It can rewrite eight parts of the system around the model (the system prompt, guardrails, memory, tool guidance, subagents, skills, scripts and plugins) and never touches the weights.

It works at two levels. Within a task, it proposes edits to the harness, probes them by running the same task again, and composes a better harness from how those runs behaved differently, with no answer key to check against. Across tasks, it keeps the harnesses it adopted, and the lessons the evidence supports, in a persistent “improvement harness” that guides the next one. In the paper, a single step lifted GLM-5 and Gemini 3.5 Flash by up to 11.5 points on WorkBuddy-Bench, 4.5 on JobBench and 11.8 percentage points on LAB’s partial pass rate, and a bigger budget gained more. It is a research release, “not an officially supported Google product,” and it inherits this section’s warning. A harness judged only against its own runs can learn the wrong lesson, and a lesson kept in the improvement harness is durable too.

This summer’s other moments show what persistence looks like when nobody built it on purpose. The agents in the OpenAI–Hugging Face incident had no durable state of their own, and each collective was wiped. What survived was a message board they improvised in a shared package manager, which the next generation found again. Durability, left unbuilt, was what they reached for.

Asleep, Addressable, Remembering

Six products, one shape. What they promise is an agent that never leaves. What they build is an agent that can leave and come back unchanged.

The second description is the more honest one. Duet’s “every few hours” is the only launch that admits it, and it makes always-on mean what it means for a colleague: not a sensor that never blinks, but someone who is around, who remembers where things stood, and who checks with you before doing anything that cannot be undone.

The question was never whether the agent stays awake. It is who it is when it wakes, and who decided what it may do before you were there to ask.