Approvals that pause without holding compute

The approval that quietly costs a runner

Most workflow engines implement a human approval gate by keeping the job alive. The worker stays allocated, the container keeps running, and the workflow waits inside it. This works in a demo, where approvals take seconds. It behaves badly in production, where a release approval waits for the change advisory board on Tuesday and a hotfix waits for whoever is awake.

The cost is not the idle CPU. It is concurrency. A runner pool sized for ten parallel runs that has four runs parked on approvals is a pool sized for six. The failure is worst exactly when it hurts most: during an incident, when several runs are queued behind approvals that are themselves waiting on the people handling the incident.

Exit instead of wait

NopsAI treats an approval as a durable state transition rather than a blocking call. When the agent reaches an approval step, it archives the run workspace, sends that archive and the run's execution state to the control plane as a checkpoint, and then exits normally.

The agent container terminates with a success exit code. The runner decrements its active-job count and is immediately free to accept other work. On the Docker runner the shared run volume is removed as part of that teardown, which is precisely why the workspace has to be archived rather than left in place — nothing on the runner is assumed to survive.

No process, container, pod or volume is held anywhere while the approval waits. The only thing that persists is a row in the control plane's database.

What the checkpoint has to contain

Resuming in a different container means the checkpoint must carry everything the run would otherwise have kept in memory or on local disk. In NopsAI a checkpoint stores the workspace archive itself, the execution history accumulated so far, the list of completed tasks, the pipeline definition the run started from, and the run's variables.

Storing the pipeline definition with the checkpoint is a deliberate choice rather than an implementation detail. It means the resumed run continues under the definition it was approved against, not whatever the configuration repository happens to contain when the approver finally clicks. An approval that could be invalidated by an unrelated merge is not an approval.

The checkpoint is size-bounded. A workspace larger than the configured limit fails the pause rather than silently truncating, because a checkpoint that restored an incomplete workspace would be worse than one that never existed.

Resuming into a fresh agent

When a permitted approver decides, the control plane submits a new job carrying the checkpoint identifier and the run's variables. A fresh agent starts on whichever runner has capacity — not necessarily the one that ran the earlier half — fetches the checkpoint, restores the workspace archive, and continues the pipeline from the completed-task list.

The run identity does not change. The execution history, the approval decision, the approver and the timing all belong to the same run record, so the evidence trail crosses the pause without a seam. From the outside it is one run that took two days; from the runner's point of view it was two short jobs.

What this constrains

This design trades memory residency for serialization, and that trade has edges worth knowing before you build against it. Anything a step leaves outside the workspace directory does not survive the pause. Long-lived network connections, background processes and in-memory caches do not survive it either. A step that expects to resume mid-stream needs rethinking; a step that writes its state to the workspace resumes cleanly.

In exchange, approval duration stops being an infrastructure question. A gate can hold for an hour or a week at the same cost, which means approval timeouts can be set from the governance requirement rather than from what the runner pool can absorb.