How it works
An interrupt divides execution into a completed segment and a segment that has not yet been authorized to begin. When the workflow reaches an interrupt point, the harness stops scheduling new work and records enough state to resume unambiguously. That state usually includes the current step, completed effects, pending action, relevant inputs, permission context, and a stable run identifier.
A sound interrupt follows a small control sequence:
- Detect a declared interrupt condition, such as an approval requirement, missing decision, risk threshold, or operator stop request.
- Finish or cancel in-flight work according to an explicit policy.
- Persist authoritative workflow state and the reason for pausing.
- Emit a visible status that identifies what input or decision is required.
- Validate the response before restoring permissions and resuming execution.
The interrupt boundary must be defined before side effects become ambiguous. If a tool call may have succeeded but the harness records the pause as though it never ran, resumption can duplicate an email, payment, deployment, or file mutation. The resume path therefore needs idempotency, outcome reconciliation, or a compensating action for every effect that crosses the boundary.
Why it matters in an agent harness
An agent can generate another step whenever its loop continues. An interrupt gives the surrounding harness a deterministic way to withhold that continuation. This separates the model’s ability to propose work from the system’s authority to execute it.
That separation improves control. The harness can interrupt before a high-impact tool call, when a budget is exhausted, after a verifier rejects an artifact, or when required context is absent. The model does not decide whether the control applies. Code or an operator evaluates the declared condition and changes the workflow state.
Interrupts also make human involvement operationally precise. “Ask a person if uncertain” is not a control contract. A useful interrupt records the exact decision, the allowed responses, the evidence presented to the reviewer, and the consequences of each response. The operator should not need to reconstruct the run from a transcript before acting.
Reversibility depends on the placement of the interrupt. A pause before an irreversible effect preserves optionality. A pause after the effect may support inspection, but it cannot prevent the action. For consequential operations, I place the boundary before authority is expanded or an external system is mutated, then record the eventual decision in the execution journal.
Interrupts improve failure containment as well. A harness can suspend one run without stopping unrelated work, provided its state and resources are isolated. This matters in multi-agent systems, where a paused coordinator must not leave workers continuing under stale instructions or retained credentials.
Observability is part of the mechanism, not an accessory. A paused run should expose whether work is safely suspended, partially complete, still cancelling, or waiting on an unknown tool outcome. Treating all four states as “paused” conceals materially different recovery risks.
Interrupt vs approval gate
An interrupt is an execution-state transition. An approval gate is a policy decision that may cause that transition. Conflating them makes systems harder to resume and harder to test.
| Axis | Interrupt | Approval gate |
|---|---|---|
| Primary purpose | Suspend and preserve execution | Decide whether an action may proceed |
| Trigger | Policy, operator request, missing input, failure, or runtime condition | A declared authorization rule |
| Required state | Resumable workflow position and effect history | Decision context, approver authority, and allowed outcomes |
| Possible resolution | Resume, revise, cancel, time out, or compensate | Approve, reject, or request changes |
A workflow may interrupt without requiring approval, such as when it needs a missing parameter. It may also evaluate an approval gate without pausing if a deterministic policy can resolve the decision immediately. Model both concepts separately so changes to authorization policy do not corrupt execution semantics.
The Rifty take
We treat an interrupt as a durable control boundary, not a conversational request to stop. We optimize for unambiguous resumption and visible operator state, accepting the storage and coordination cost required to preserve them. If the harness cannot determine what happened before the pause, it should surface an unknown outcome rather than resume optimistically.
Implementation checks
- Declare interrupt points in workflow logic rather than relying on prompt compliance.
- Persist the pending step, completed effects, reason, and required response.
- Give every interruption a stable run and checkpoint identifier.
- Distinguish safely paused work from cancellation still in progress.
- Reconcile tool outcomes that may have crossed the interrupt boundary.
- Validate that the responder has authority for the requested decision.
- Recompute expired permissions and time-sensitive context before resuming.
- Make repeated resume requests idempotent.
- Propagate interruption or cancellation to dependent workers.
- Test interrupts before, during, and after external side effects.
Frequently asked questions
What state must an interrupt persist?
An interrupt must persist enough authoritative state to identify the completed work, pending step, known side effects, required response, and permissions in force at the boundary. A transcript alone is insufficient when it cannot prove which external actions completed or provide a stable position from which execution can safely resume.
Where should an interrupt be placed around a side effect?
Place the interrupt before the side effect when its purpose is to preserve operator choice or obtain authorization. If interruption can occur during the call, record an intermediate state and reconcile the external outcome before retrying. Never assume that a missing response means the action failed.
How is an interrupt different from cancelling a run?
An interrupt preserves a supported path back into the same workflow, while cancellation ends that execution path and may trigger cleanup or compensation. A paused run retains pending intent. A cancelled run should not resume unless the harness creates a new, explicitly authorized execution from recorded state.
Can the model decide when to interrupt itself?
The model can propose an interrupt or emit a condition the harness evaluates, but it should not be the only enforcement mechanism for consequential boundaries. Deterministic code should apply permission, budget, and side-effect rules so that a persuasive or malformed model output cannot silently bypass the pause.
What should happen when a paused run cannot determine a tool outcome?
The harness should mark the result as an unknown outcome and reconcile it against the external system before resuming or retrying. If reconciliation is impossible, require a bounded recovery decision. Optimistic retry is unsafe because it can repeat an effect that succeeded before communication failed.