Get started

HITL · the inbox between AIs and humans

Every AI. One inbox. Your call.

The bridge between your agents and anything irreversible is an inbox with a human on the far shore.

Included in QuoxCOREFree, self-hosted, nothing to buy.
The human-in-the-loop inbox with TRIAGE-Q beside it: approvals, questions and escalations waiting on a person
Item kinds6Connectors wired3 of 16Auto-approve by defaultnever

In plain words

What it is, where it lives, when to reach for it

What is it
An approval inbox inside QuoxCORE where risky agent actions wait for a human decision.
Where do I use it
On the dashboard's Inbox page, and through the quox inbox commands in your terminal.
When would I use it
When you want agents doing the work but not taking sensitive actions without your yes.
How do I use it
You do not invoke it; sensitive actions create inbox items. Run quox inbox list to see yours.

QuoxCORE is the free, self-hosted platform underneath this. What is QuoxCORE

How it works

Sensitive actions wait for you.

01 · heldThe run parks mid-flight

A workflow gate, an objective checkpoint or a policy marks the action sensitive. The run pauses with its state intact and an approval item lands in the inbox.

approval:gate · human:task · checkpoint

02 · decidedA human decides

Approve, deny, or request changes and send the work back for another pass. The paused run resumes exactly where it stopped.

approve · deny · request changes

03 · recordedThe decision becomes evidence

Who decided, what and when is written server-side to the run’s event record and the audit trail, and the approval envelope joins the conversation’s chain.

run_events · audit_events · AEE

Try it

The gate, in your hands.

A mock approval, wired to nothing. Approve it, or reject it with a reason and watch the run come back for another pass.

This card is a demo, wired to nothing. Focus it, then press A to approve or D to reject with a reason.
from WARDEN

Restart production container web-01: memory leak suspected

TRIAGE-Q: low blast radius, snapshot exists, recommend approve.

The inbox

One queue, keyboard first.

Approvals, questions, tasks, incidents, info and overrides: six item kinds, six states, four priorities, all enforced at the database, all in one queue with search, assignee tabs and bulk actions. Move like you would in your mail: j and k to move, a to approve, d to deny, e to archive, h to snooze. TRIAGE-Q sits beside the queue, summarising what needs attention first. This is the permission check step in the agent loop; see where it sits before execution in agentic AI.

Sensitive work crosses, waits at the gate, and comes back approved, denied or improved: on your tempo, not the machines'. The scene behind this page is the whole idea: their side teems, your side breathes, and one bridge joins them.

quoxcore · hitl inbox
The HITL inbox: a type rail for Approvals, Questions, Tasks and Results, state counters for open, in progress, waiting and total, queued items with org and severity chips, the TRIAGE-Q panel with suggestion chips, and a keyboard shortcut legend.
  1. 1Filter the queue by typeApprovals, Questions, Tasks and Results each carry their own live count in the rail.
  2. 2Read the state at a glanceOpen, in progress, waiting and total counts sit as clickable filters above the list.
  3. 3Spot the org and severity per itemEach row carries its own org and severity chips, so priority never needs a click to see.
  4. 4Ask TRIAGE-Q for the shortlistSuggestion chips let you ask what needs attention first without typing a question.
  5. 5Work the inbox from the keyboardj and k navigate, a approves, d denies and e archives, all without touching the mouse.

Captured from the real HITL inbox, not a mockup. 6 kinds · 6 states · 4 priorities

Escalation

Deadlines that refuse to guess.

Every item can carry an escalation ladder: notify, escalate, reassign, expire or auto-deny when the clock runs out. The one thing the runner will not do by default is auto-approve. Silence never becomes consent.

sla runner · 60s poll · auto-approve off by default

Where gates appear

Anywhere the work gets serious.

Workflows

An approval gate node holds the flow; a human task node hands a step to a person with a response form.

Objectives

Long-running goals can require approval before start, and checkpoint after every task.

Credential leases

An agent asking to borrow a credential files an approval; grant or deny it from the same inbox.

Agent tools

High-risk infrastructure tools can be wrapped in the same gate, so a container restart or a VM action waits for a yes.

opt-in per deployment

Any channel

The approval finds you.

The inbox is the channel that is confirmed working. Three delivery connectors are wired on top of it, Telegram, Slack and email, and they are wired rather than verified live, as the honest band above this section says.

Thirteen more are declared targets, not delivered ones: Discord, Microsoft Teams, Google Chat, Mattermost, Rocket.Chat, PagerDuty, Opsgenie, Pushover, ntfy, Gotify, LINE, SMS and webhooks.

You decide from the dashboard, from the terminal, or from your Claude connected over MCP, and your resolution relays back into the Telegram or Slack thread.

channels notify and relay today; deciding happens on the three surfaces

Approving from inside the Telegram thread itself arrives with Quox Telegram Pro. coming · quox telegram pro

quox inbox
$ quox inbox list
ID      KIND      PRIORITY  TITLE
i_42    approval  urgent    roll back the release

$ quox inbox respond i_42 --action approve
approved · run resumed

$ quox inbox stats
open 3 · resolved this week 41

dashboard · quox inbox CLI · MCP approve_request

The third answer

Not yes. Not no. Try again.

Send work back with notes and the run loops to the same gate with an iteration counter, as many rounds as it takes. Approval is a conversation, not a rubber stamp.

request_changes · iteration · return_to_node

Where it stands

What's proven, what's still beta.

Live and proven
  • Approve, deny or send an item back for another pass, with the decision written to the run record and the audit trail
  • Escalation deadlines run on a live SLA runner in the deployed auth service; auto-approve stays blocked unless a deployment explicitly turns it on
  • The request-changes loop returns an item to the same gate with an iteration counter, as many rounds as it takes
Beta and partial
  • Server-side witnessing of every decision now ships with a durable retry queue, but has not yet been verified live against the deployed services
  • Slack, Telegram and email delivery are wired but unverified live; the inbox channel itself is confirmed working
  • Approval policies at the governance layer remain experimental
Planned, not shipped
  • TRIAGE-Q cannot yet read or act on inbox items itself, only summarise from memory
  • Routing email straight into the inbox is drafted, not implemented
  • Approving from inside the Telegram thread itself arrives with Quox Telegram Pro

Ready when you are

Put a human where it matters.

HITL ships in the box with QuoxCORE: no extra licence, no extra install.