16 — Task Interruption & Resumption

Concept overview

Interruption and resumption allow an agent run to wait for a person, missing evidence, a business event, or an operational repair without occupying a worker indefinitely. A durable interrupt records why the run stopped, what input can resume it, and which execution version is waiting. Suspension is a workflow state, not a blocked thread.

Resumption must account for time. Permissions may expire, records may change, and a pending tool call may finish while the run is paused. Validate the resume token and new input, reload current policy, and reconcile outstanding operations before continuing. Do not assume that replaying a paused node is side-effect free.

Why it matters in production

Proof of concept

A prototype can pause before a read-only step and manually supply a resume value. Test what code executes again when the runtime restarts that boundary.

Production

Production persists interrupt metadata, authenticates responders, and defines expiry, cancellation, and stale-input behavior. Place irreversible actions after validated resume boundaries or protect them with idempotency.

Enterprise scale

At scale, waiting runs should consume storage rather than active worker slots. Build queues for expired interrupts and maintain compatibility for executions paused across several deployments.

Architecture components

Interrupt controller

Creates a durable waiting state with reason, required input, deadline, and execution version.

Checkpoint store

Saves accepted progress and pending operation identities at the suspension boundary.

Resume gateway

Authenticates the responder and validates resume identity, input schema, and authority.

Reconciliation service

Checks changed business records and uncertain external operations before continuation.

Expiry scheduler

Cancels or escalates abandoned waits according to explicit business policy.

The architecture, mapped

sequenceDiagram
 participant W as Agent worker
 participant C as Checkpoint store
 participant H as Review queue
 participant G as Resume gateway
 participant R as Replacement worker
 W->>C: Persist waiting state and resume contract
 W->>H: Publish review task
 H->>G: Authorized decision with state version
 G->>C: Validate and commit resume input
 G->>R: Schedule continuation
 R->>C: Load checkpoint and pending operations
 R->>R: Refresh policy and reconcile effects
 R->>C: Commit next execution state

flowchart LR
 I["Resume submission"] --> A["Authenticate responder"]
 A --> V["Match interrupt and state version"]
 V --> P["Recheck current authority"]
 P --> B["Recheck business assumptions"]
 B --> R["Schedule continuation"]
 V --> S["Stale decision record"]
 P --> D["Denied resume"]
 B --> N["Renewed review required"]

Runtime flow

1. 1

   Reach safe boundary

   Complete or checkpoint preceding work and identify any outstanding side effects.

2. 2

   Persist interrupt

   Record the expected resume input and state version before releasing the worker.

3. 3

   Notify owner

   Expose the pending action through a durable work queue or authenticated interface.

4. 4

   Validate response

   Reject stale, duplicate, unauthorized, or malformed resume attempts.

5. 5

   Refresh assumptions

   Recheck permissions, source versions, deadlines, and previously uncertain tool outcomes.

6. 6

   Continue execution

   Claim fresh ownership and resume from the documented replay boundary with the accepted input.

Pausing a purchase request for engineering evidence

Construction · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

A construction procurement team requests specialized equipment, but engineering certification arrives after the initial assessment.

The problem

Keeping the agent session open wastes capacity, while restarting from scratch repeats supplier checks and loses review context.

Agent requirement

The assistant must pause with a precise evidence request and resume when the authorized engineer supplies the certificate.

Architecture

A durable interrupt stores the missing certification requirement, approved supplier evidence, and the current purchase-request version.

Runtime

• The agent finishes available checks and publishes an engineering task with a resume identifier.
• On submission, the gateway verifies the engineer's authority, validates the certificate, and confirms that equipment specifications have not changed.

Failure scenario

If the purchase request changed during the wait, the old resume input is retained as evidence but affected checks run again before approval.

Operational impact

Measure waiting age, stale-resume rejection, resumed-run success, and repeated work to distinguish business delay from runtime inefficiency.

Architecture tradeoffs

Failure scenarios & recovery

Common architecture mistakes

Pausing after an unrecorded command

Persist operation identity and reconcile the outcome before suspension.

Trusting any bearer of a resume link

Authenticate the actor and recheck decision authority.

Assuming local variables survive deployment

Persist every value required for continuation.

When to choose this pattern

Choose it when

• Tasks wait for people or external evidence.
• Long pauses should survive process replacement.
• Resume input can be validated against a defined contract.

Avoid it when

• The task can complete within one short stateless request.
• Continuation would rely on unrecoverable process-local resources.
• No owner or expiry policy exists for waiting work.

Architecture checklist

• Document the exact replay boundary.
• Persist interrupt reason and expected input.
• Authenticate and version resume attempts.
• Recheck authority after long waits.
• Reconcile pending external operations.
• Expire or escalate abandoned interrupts.

Related concepts

• 3 — Agentic State Machines
• 6 — Asynchronous Agent Execution
• 12 — State Persistence
• 44 — Human-in-the-Loop (HITL)
• 57 — Crash-Safe Memory

Primary references

• LangGraph: interrupts
• LangGraph: persistence