State lives in Cosmos DB. Service Bus carries pointers to work. The alternative — treating the queue as the state store, which is what a naive implementation drifts into — was rejected because you cannot query it, cannot audit it, cannot replay it, and cannot let an operator intervene in it.
Workers never write execution state. They emit a result and settle a message; the control plane decides what that result means. That single rule is why a worker can be killed at any instant without corrupting anything, and why view 24 can scale the fleet to zero.
The cost is honest: every task involves at least one queue hop and one database write more than a direct call would. That overhead buys recoverability, and at 900 tasks per second it is a Cosmos RU line item rather than an architectural problem.
What follows from it
Recovery after a total messaging outage is a replay from Cosmos of every task in SCHEDULED or RUNNING whose lease has expired. No message needs to survive (view 22).
Duplicate delivery becomes an expected event rather than a defect, because the state machine transition is idempotent under the ETag guard (views 16 and 17).
Orchestrator instances need no affinity to an execution. Any instance can advance any workflow, so the control plane scales and restarts freely (view 14).
Risks
Cosmos becomes the availability floor for the whole control plane. View 31 states the declared behaviour under throttling and regional loss, and view 22 prices the single-write-region choice.
The transport plane can drift into holding state if a future feature stores decisions in message properties. This is a design review checkpoint, not something a diagram prevents.
Per-task database round trips are the dominant RU cost. If the workload shifts to very short tasks, batching completions becomes necessary and is not designed for in V1.
