Summary
Three things go wrong at once: the purchase order is missing so the case must wait overnight for a reviewer, the finance API is briefly failing so an integration must retry, and the arithmetic check is ready to run immediately. Holding all three situations correctly is the durable-execution problem, and the article’s real question is not whether Opus needed durable execution but why the team built the executor rather than adopting one.
The design separates dependencies from resources: the graph decides which nodes are ready, and the execution manager plans, dispatches and records without running tasks itself, sending each ready node to a queue and worker pool for its type so agent, code, integration and human work scale independently. The overnight wait is handled by hibernation — the case’s state is persisted and the worker released, resuming on an event from the human-review gateway — described precisely as “preserved with no active worker” rather than the overclaim of “zero resources”.
A set of operational controls (retries, priority, failure behaviour, type checks, scoped caching, loop mode, multi-route flow, change history) each answer a named problem, with a careful caveat that matching cache fingerprints makes reuse a candidate, not a validated choice. The ownership decision is justified by the seams: node types map to worker pools, authorization checks sit at manager and workers, human review is a first-class node type, and traces feed the learning subsystems — each of which would otherwise be an adapter maintained at a seam.
The costs are stated plainly: owning reliability, recovery, replay and tooling, and the fact that durable state does not by itself make a repeated write to the finance system safe.