Interrupts and human review

Overview

• An interrupt pauses graph execution and exposes a payload for external input.
• Resumption supplies the requested value.
• The node containing the interrupt can run again from its beginning on resume, so code before the pause may repeat.

Why this matters

Approval and clarification should survive process restarts without keeping an HTTP request open.

An everyday example

Put a case in a “waiting for customer” tray, then retrieve it when the customer replies.

A technical example

Persist proposal → interrupt for decision → resume through an authenticated endpoint → execute approved operation in a separate idempotent node.

How it works

1. Prepare stable payload
2. Pause/checkpoint
3. End current request
4. Record reviewer decision
5. Resume same thread
6. Validate decision
7. Continue.

Architecture and flow

Graph pause → review record/UI → resume API → authorized decision → graph continuation.

The insurance assistant example

A draft's document list and accident facts are reviewed before submission.

When to use it

Missing data, consequential review, and exception escalation.

When to avoid it

Avoid sending emails or creating claims immediately before the interrupt, where replay could repeat them.

Interview answer

“Interrupts provide resumable human input. I keep pre-pause work free of irreversible side effects and authenticate and validate every resume.”

Benefits, trade-offs, and production considerations

• Do not swallow interrupt control flow in a broad catch.
• Keep interrupt order stable for pending runs, handle duplicate decisions, and prevent edited proposals from inheriting old approvals.