The run pauses at the approval step, and the runtime holds its state while releasing the resources it was using. Crashes and deployments during the pause do not affect the held run.
When the decision arrives the run resumes at the step where it stopped. The work before the pause is not replayed and the tools called before it are not called again.
Holding a decision open by keeping a process alive works until something restarts it. A three-day wait spans several deployments in most organisations, and every one of them ends the process that was waiting.
Durable suspension records the pause as part of the run. The state sits in the journal, the compute is released, and the run reappears when the decision arrives. Duration stops being a design constraint.
The usual alternative writes the pending item to a database and ends the run. A second run starts when the approval arrives, and that run has to reconstruct the context the first one held. The two implementations drift apart as the system changes.
A held run has no second path. The approval resumes the original execution, so the evidence record shows one run with a pause in it.
The deadline set at the pause decides. The run escalates to a wider approver set, or it expires with a recorded outcome. A pending item with no clock becomes a backlog nobody owns.
The state persists and the compute is released, so holding thousands of paused runs costs storage instead of capacity.
The proposed action and the evidence behind it are part of the held state, so the approver reads what the agent was about to do. A summary written afterwards is not what appears.
The approver set resolved when the run paused is the one that applies. A run that has been waiting for two days is not silently re-scoped by a change made yesterday.
