Skip to main content
This lesson demonstrates a common human-in-the-loop interruption pattern for workflows: instead of running end-to-end automatically, a workflow pauses at a breakpoint, waits for a human decision (review/approval), and then continues from the same logical point. The example below simulates this behavior with plain Python to keep it simple and portable. It mirrors how breakpoints and interrupts behave in workflow runtimes while remaining runtime-agnostic.
This example demonstrates the pattern and data flow used for breakpoints. In a real deployment the interrupt/continue primitives would be provided by the platform runtime.

Overview

The demo implements a lightweight pattern that:
  1. Generates content.
  2. Interrupts execution and returns an interrupt payload for human review.
  3. Resumes execution using the reviewer’s decision and updates the workflow state.
Key concepts used:
  • Breakpoint / Interrupt: the point where the workflow pauses and returns a payload for review.
  • Resume: receiving an external decision and continuing execution from the same logical point.
  • Workflow State: an object carrying the data that travels between nodes.

Setup and types

Begin with the necessary imports and the type that represents the workflow state. This ReviewState carries the generated content, the approval decision, and a status flag.
Define the workflow state type:
Next, define a simple InterruptRequest dataclass to represent a pause/interrupt. In a real runtime, invoking an interrupt would hand control back to the host with a payload describing what needs review.

Workflow nodes: generate, interrupt, resume

Below are the three main nodes in this simulated workflow: content generation, issuing an interrupt, and resuming based on a decision.

State and function summary

Use the following table to quickly understand the state fields and the purpose of each function in this demo.

Example run (end-to-end)

This block shows the full flow: initialize state, generate content, request review (interrupt), then resume after a simulated reviewer decision.

How this maps to workflow runtimes

  • The InterruptRequest models the runtime interrupt object you would encounter when a node pauses for external input in a workflow system.
  • The payload contains only the minimal necessary data for a human reviewer; in production this can be extended with metadata, links to artifacts, or audit IDs.
  • When the external decision returns, the workflow runtime or controller reconciles state and resumes processing from the same logical point, preserving idempotency and traceability.
  • This pattern enables manual checks, approvals, gated deployments, or other human approvals within otherwise automated processes.
In production systems, interrupts are typically implemented as runtime primitives that persist state, emit events/notifications, and secure the review channel. Use this pattern to model human review gates while keeping your core workflow logic deterministic and resumable.
This pattern is a practical approach to integrating manual approvals into automated workflows while maintaining clarity, auditability, and the ability to resume execution from a known state.

Watch Video

Practice Lab