Resources · Durable execution

Work that outlives the model turn

A closed laptop is not a cancelled purchase, and a retried request is not a second domain.

The durable handle

Anything long-running or gated returns a task handle immediately rather than holding a connection open. The agent gets an identifier it can poll, hand to a human, or pick up in a later session.

working
Running. Should narrate a human-readable stage, so "what is it doing" has an answer.
input_required
Suspended at a human gate.
completed
Finished, with a receipt describing the verified end state.
failed
Finished without the effect, with compensations already run.

Tasks survive process restarts, and reads are tenant-isolated.

The failure this prevents

Infrastructure work is slow in ways a model turn is not built for: registrars take seconds to minutes, DNS propagates on its own schedule, and a human approval can take a day. Without a durable handle, every one of those waits becomes an opportunity to lose track of the job — and the usual recovery, "try again", is exactly the wrong move when the first attempt already bought something.

Because the task is server-owned, a timeout, a worker restart, a provider delay, or a human who approves the next morning all resolve into the same single job.

Partial success must not survive

Multi-step actions are sagas. Each step registers its compensation before it executes; if a later step fails, compensations run in reverse order and the budget reservation is released. Compensations are themselves idempotent.

The rule this enforces is blunt: a purchased domain with no working site gets parked and credited; a VM with no DNS gets destroyed. Where a compensation cannot be automated, the saga records the manual step needed rather than reporting success.

Honest limits. Automatic failover between providers and zero-downtime live migration are not promises SproutPad makes today. Durability here means the job is not lost and does not double — not that every provider outage is invisible.

Keep reading