Interrupt and Resume

What it is

Stopping an agent part-way through — because a person asked, because a policy requires approval before the next action, because a dependency is unavailable, or because an allowance ran out — and later continuing from where it stopped rather than from the beginning. It requires a defined point at which stopping is safe, a serialised record of everything the continuation needs, and a resumption path that reconciles whatever changed while it was stopped.

Why it matters

Pausing is most valuable exactly where it is hardest: long runs that touch the world. Requiring a person to approve a consequential action is the central mechanism of supervised automation, and it is only usable if waiting is cheap. An implementation that holds a process, a connection, and a context in memory for four hours has not made the run pausable, it has made it expensive. Resumption is also what stops a routine deployment from being an outage for everything currently in flight.

More than a state with a name

Adding a suspended value to a state model is easy; making it true is not. Suspension demands that everything required to continue lives outside the process — the position in the work, the accumulated record, the consumed allowance, the identity of effects already applied — and that the code which resumes can reconstruct a working context from it. The runtime states are the vocabulary; this capability is the machinery that makes two of those states mean something.

Key decisions

• Where stopping is permitted: anywhere, which requires capturing an arbitrary continuation, or only at declared boundaries between steps, which is far cheaper and slightly less responsive.
• What the snapshot contains, specifically whether it records which external effects have already been applied, as distinct from which steps were attempted.
• The maximum time a run may stay suspended, and what expires meanwhile: credentials, prices, quotes, inventory, the user's willingness to care.
• Whether the world is revalidated on resumption or assumed unchanged since the pause.
• What happens to calls already in flight at the moment of interruption — cancelled, awaited, or orphaned to complete into a run that is no longer listening.
• Who may interrupt, and whether a stop initiated by a person is distinguishable afterwards from one caused by an exhausted budget.

Failure modes

• A run resumes with expired credentials, the first call fails on authorisation, and the agent interprets it as a permissions question to put to the user.
• The snapshot captures the conversation but not the fact that an earlier step already sent the email, so resumption sends it again.
• Interruption is implemented as termination plus a fresh start, which users experience as an assistant that forgets everything it was told.
• Suspended runs awaiting approval are held in process memory and a rolling deployment discards every one of them.
• The resumption path is exercised only by the approval flow and is broken for every other cause; the first budget-triggered pause in production discovers this.
• The prompt is reconstructed differently from the original run, and the continuation behaves like a noticeably different agent mid-task.
• Nothing expires suspended runs, so approvals requested months ago are still pending, still holding claims, and still counted as active.
• A call issued just before the interrupt completes afterwards and writes into a run that has since been resumed elsewhere, producing two divergent continuations.

Related capabilities

• Agent Lifecycle — defines the states this machinery moves an instance between
• Shared State Management — holds what a snapshot refers to rather than copies
• Execution Loop — its iteration boundaries are the natural stopping points
• Autonomy Levels — decides which actions must pause for approval
• Termination Conditions — distinguishes a pause from an ending

Applies: Production readiness · Design questions