Skip to content

Jump OS knowledge base · Interruption

Stopping an agent is a control-plane problem.

A system that can explain an action after the fact still needs a way to interrupt unsafe work while it is in progress. Jump OS separates pause, cancel, terminate, quarantine, and rollback so each action has a clear meaning.

Recovery and verification infographic for reliable agent operations
Jump OS public blueprint visual · Jumpstart Scaling / Christopher Amaya

Recovery visual

A stop needs proof

Pause, cancel, terminate, quarantine, and rollback are different controls. The operator still needs evidence that the request propagated and the affected work was verified.

Read the recovery guide →
Five different controls

“Stop” is not one operation.

Pause

Pause prevents new progress while preserving the possibility of resuming. It is useful when an operator needs to inspect a situation without destroying task context.

Cancel

Cancel requests cooperative termination. The worker may need to finish a safe boundary before acknowledging the request.

Terminate

Terminate attempts to stop active work forcefully where the implementation supports it. It does not guarantee that an external provider or already-completed mutation is reversed.

Quarantine

Quarantine isolates a worker, task, output, or partial result pending review. It is especially important when the system cannot yet establish whether a side effect completed safely.

Rollback

Rollback requests a compensating action. It has its own authority, evidence, verification, and failure state. A stop request is not a rollback.

The interruption lifecycle

A governed interruption should preserve a sequence such as requested, authorized, propagated, acknowledged, stopping, stopped, and verified. Requests can also be denied or become unreachable. Each state answers a different operational question.

An unreachable worker is not a stopped worker. If a worker cannot acknowledge the request, the system should preserve uncertainty and independently inspect the affected target before claiming that work stopped.

Why this matters in real workflows

Imagine an agent updating customer records while a policy changes, a research worker exporting an answer from stale material, or a financial workflow beginning a mutation that must no longer proceed. The emergency path must identify who is authorized to interrupt the work, how the signal reaches each worker or adapter, what happens to partial work, and what receipt proves the result.

The public Jump OS architecture intentionally does not promise universal interruption latency or automatic recovery of arbitrary side effects. An enterprise implementation must publish its own latency expectations, unreachable-worker behavior, admission controls, and verification rules.

Use the source as a design checklist

Read the public emergency-stop architecture and threat model before deciding how your own workers, tools, and business systems should respond.

Open Jump OS on GitHub →