Interrupts

How agents pause, ask a human for a decision, and resume.

An interrupt is the moment an agent stops and hands control to a human. The agent opens an interrupt through the API, the interrupt lands in the inbox, a human reviews it and decides, and the agent resumes with the outcome. It is the core primitive of Vigilator - everything else (classification, routing, escalation, Argus) exists to get each interrupt in front of the right person quickly.

Lifecycle

The expected round trip, from the agent pausing to the agent resuming:

The agent's run stays paused for the whole exchange - Vigilator holds the decision, and the externalId supplied when the interrupt was opened is what routes the outcome back to the right run.

Anatomy of an interrupt

An interrupt carries:

  • Title and description - what the agent is trying to do and why it stopped.
  • Action requests - the actions awaiting review (for example the tool calls the agent wants to run). Every interrupt has at least one: the action requests are its decision surface, and the interrupt is only answered once each one is decided.
  • Messages (optional) - the conversation context leading up to the interrupt, shown to the reviewer alongside the request.
  • Classification (optional) - a classification tag giving the interrupt a category and priority. Interrupts opened without one arrive unclassified and are triaged later, by a human or by Argus.
  • External id (optional) - your correlation id, typically the paused run's id in your agent framework, so the outcome can be routed back to the right run.

To ask a human a plain question rather than review an action, send an action request whose name is the question and allow only the respond decision.

Decisions

Each action request declares which decisions it allows, and the reviewer picks one:

DecisionMeaning
ApproveProceed with the action as proposed.
EditProceed, but with the reviewer's replacement arguments.
RejectDo not proceed - optionally with a reason.
RespondA free-text answer, for interrupts that ask a question.

Decisions are final: the first reviewer to decide an action request wins, and a second decision on the same request is simply ignored rather than treated as an error. Once every action request on an interrupt is decided, the interrupt flips to answered - your agent learns the outcome by polling the interrupt or, better, through the interrupt.answered webhook event, and resumes accordingly.

Routing and triage

When an interrupt arrives, Vigilator picks an assignee automatically based on its classification and your organisation's workload management rules; interrupts that can't be routed stay unassigned for manual triage. Operators with the inbox permission can re-assign and re-classify at any time.

An interrupt that needs more senior eyes can be escalated to the manager review queue - a separate queue worked by members holding the review permission. Escalation is one-way: once raised, an interrupt stays in the queue until it is answered.

Every step leaves an audit trail on the interrupt - who assigned, classified, escalated, and decided what, and when - including the automatic classification and assignment applied on arrival.

Permissions

Interrupt work is gated through access control:

PermissionWhat it allows
inbox.viewSee interrupts in the inbox
inbox.createOpen an interrupt (this is what agent API keys use)
inbox.approveDecide action requests
inbox.escalateRaise an interrupt to the manager review queue
review.viewSee the manager review queue
review.approveDecide escalated interrupts

Usage

Each opened interrupt counts as an inbox message. Free organisations have an included monthly allowance - once it's spent, new interrupts are rejected until it resets - while on Pro, usage beyond the included amount is billed as overage.

On this page