You hand an agent a job that ends in someone’s approval. It pulls the invoices, checks them against the ledger, drafts the payment, and posts a message asking a human to confirm before the money moves. Then it waits. The person who can confirm is in meetings until four. The run stays up the whole time: polling, re-reading what it already knows, writing its own waiting into its own transcript. At four the approval arrives and the job finishes in seconds. Then you look at what the afternoon cost, and almost none of it bought work.

Hanging up costs less than staying on hold

Think of phoning a service line about a claim that somebody has to look at. You can stay on the line. The connection is open, the music plays, your afternoon goes, and if the call drops you begin again at the greeting. Or the person who picks up takes a reference, hangs up, and rings you back when there is an answer.

The second way only works because of what went into the file before the hang-up. What you asked for. Which account. What had already been checked. What you agreed to while you were on the phone. If the file holds all of that, hanging up is free and the wait can last a week. If what got written down is only that a customer rang about a claim, the callback begins at the greeting anyway, and you tell the whole story twice.

A durable suspend is that file. When the run reaches a point where a human has to answer, the runtime serializes state, task and the context that matters into storage, and lets the process go. The approval request can stay open indefinitely. When the answer comes back, the runtime reloads the checkpoint and carries on from the node that stopped. The invoices are not pulled again. The ledger is not checked again.

What gets written down decides what resumes

Two prices are hiding in that afternoon. The first is plain: an idle run bills for every token it spends re-reading itself, and it drags a second cost behind it. If the approval has to land before the session ends, the gate is now on a clock. People get chased. Someone widens the rule so routine cases pass unattended. The human check you designed quietly becomes a formality, not because anyone decided that, but because the runtime could not wait as long as a person needs.

The second price is what you chose to keep. The usual mistake is persisting the approval alone: a stored yes, and nothing else. Coming back properly needs the state, the identity of the work so it cannot be done twice, and the meaning of the node being re-entered. Otherwise the resumed run pays the same invoice a second time, or picks up a result that belongs to some other job entirely. The same holds when the wait is a machine’s. An agent that starts a training run lasting six hours should not sit in a polling loop for six hours. It hibernates, and the finished job wakes it with metrics in hand, plan and budget and earlier results reloaded, ready to compare the outcome against what was approved and choose the next experiment.

A crash and a signature are one interruption

None of this is machinery you build for approvals and then set aside. A harness that takes a business objective and compiles it into a graph of roles and tasks has to persist progress regardless: when a worker dies mid-analysis, the run resumes from the checkpoint instead of collecting every document again. Cost ceilings need the same durable record to count against. So does an audit trail worth reading. A human gate and a crashed process are the same event seen twice — an interruption that must not cost you the work already done — and they are answered by the same state you can point at rather than held in a living process.

A demo never has to wait, so it never has to learn how. The difference between a demo and a service is what happens while nothing is happening.