Reviewing an Interrupt
Reading an interrupt, deciding its action requests, and triaging it to the right person.
Select an interrupt in the rail and its detail fills the right-hand pane. This page walks through what you'll see and everything you can do from it.
Reading the interrupt
The header shows the case id, a status badge - Open or Closed - and Escalated if it has been raised to manager review. Below it come the interrupt's title and the agent's description of why it stopped, then two panels:
- Tools Awaiting Decision - the interrupt's action requests, one card per request. When there are several, a counter tracks how many have been decided.
- Contextual Messages & Thought Process - the conversation that led up to the interrupt, if the agent sent one. Each message shows who sent it (Human or Agent), when, its content, and any tool calls it made. Invalid tool calls, extra keyword arguments and response metadata are tucked into collapsible sections so they don't get in the way.
The sidebar on the right carries the metadata (the agent's external id, created and updated times), the triage controls, the Argus panel and the audit log.
Deciding action requests
Every interrupt has at least one action request - the thing the agent wants to do and is waiting on. Each request card shows the request's name, the agent's description of it, the arguments it wants to use, and the decision buttons. The first undecided request is expanded by default.
Which buttons appear depends on the decisions the agent allowed for that request:
| Decision | What happens |
|---|---|
| Approve | The agent proceeds with the action as proposed. The button acts immediately - there is no confirmation step, so the a shortcut only focuses it and Enter confirms. |
| Edit | Opens the arguments as editable JSON. Change what you need and press Approve with edits - the agent proceeds with your arguments in place of its own. The text must be valid JSON and must be an object. |
| Reject | Opens an optional reason box ("Why is this rejected? (optional - the agent sees it)"). Press Confirm reject - the agent does not proceed, and receives your reason if you gave one. |
| Respond | Opens a free-text box and Send response returns your answer to the agent. |
Questions, not actions
When an agent just needs a human's answer, it sends an action request whose name is the question and which allows only Respond. The inbox recognises this and opens the response box straight away, with no other buttons.
Once a request is decided its card shows who decided it, how, and when - along with the response or reason text and, for edits, the arguments that were substituted.
A few rules to keep in mind:
- Decisions are per request. An interrupt with three action requests needs three decisions. It becomes Closed (answered) only when the last one is made - that's the moment the agent is told the outcome, and the
interrupt.answeredwebhook fires. - Decisions are final. There is no undo and no reopen. If two reviewers decide the same request at the same time, the first decision stands and the second is silently ignored rather than raising an error.
- Deciding needs the
inbox.approvepermission. Members without it see the requests and their arguments but no buttons.
Triaging
The sidebar controls let anyone who can see the inbox route the interrupt to the right person:
Assignee. The Assigned to: control opens a searchable list of the organisation's members; pick one to assign, or Unassign to hand the interrupt back to the queue. A newly assigned interrupt counts as unread for its new assignee, so it shows up in their sidebar badge. Most interrupts arrive already assigned by workload management - reassigning by hand always overrides it.
Classification. The Classification: control applies one of your organisation's classifications, which sets the badge, the priority, and - if routing is on - which team the interrupt belongs to. A classification can be changed but not removed.
Escalate for review. Raises the interrupt to the manager review queue. Escalation is one-way and unassigns the interrupt, so it waits for a reviewer rather than sitting in someone's personal queue. Needs the inbox.escalate permission.
Triage changes apply instantly and are visible to everyone watching the inbox. If the server rejects one, the change is rolled back and the error is shown above the detail pane.
Argus
If your organisation has Argus enabled, an Argus panel appears in the sidebar once it has finished reading the interrupt:
- Summary - a one- or two-sentence précis of what the interrupt is about.
- Suggested response - a short draft with an Approve or Reject badge for Argus's recommended decision.
The panel is advisory: nothing in it is applied automatically, and a reviewer still presses the buttons. Argus's third feature, auto-classify, doesn't appear in the panel - it simply sets the classification on arrival, and shows up in the audit log as Classified as … by Argus.
Audit log
Every interrupt keeps a trail of everything that happened to it, oldest first:
| Entry | Recorded when |
|---|---|
| Interrupt opened via the API | Always the first entry - when the agent opened it. |
| Assigned to … / Unassigned | Assignment changes, whether by a member, workload management, coverage or escalation. |
| Classified as … | A classification was applied - by a member, by Argus, or on arrival. |
| Escalated for review | The interrupt was raised to manager review. |
Approved / Edited / Rejected / Responded request | An action request was decided. |
Each entry names who did it, or reads via the API when it was the agent or an automatic process rather than a member.