How it works
Put a human in the loop — without stopping the line.
LoopQuest plugs a real human decision into your automation in one of two ways. Some decisions must be approved before they happen; others just need checking afterwards. You choose per task, and the same API serves both, with fail-closed timeouts so nothing ever hangs.
The two modes
Gate, or monitor.
Set mode on each task. That single field decides whether your automation waits.
Gate
Blocks until a human approves
The automation pauses, and the downstream action only fires on an approve. Use it for the decisions a person has to be answerable for: payments, clinical sign-off, sanctions disposition, content takedowns.
- Waits via webhook callback or polling
- Fail-closed timeout (escalate by default)
- Optional consensus — N reviewers must agree
Monitor
Reviews quality in the background
The flow proceeds immediately, and LoopQuest reviews a copy out of band. You get an auditable measure of quality, accuracy and drift, plus decoys that prove reviewers stay sharp, without slowing throughput.
- Nothing waits — verdicts logged, scored, trended
- Sample a fraction for QA, or review everything
- Drift & accuracy you can put in front of an auditor
The lifecycle
Request, review, return.
You POST the output; a human reviews it through the fitting game; the verdict comes back. For a gate you either get a webhook the moment it resolves, or poll until it does.
Ingest a gate
POST the output with a mode of "gate". You get back the task id and its expiry time.
A human decides
It routes to the right review game. They approve, flag, or correct it, with consensus if you require it.
Act on the verdict
Resume on the webhook, or poll the task. Branch on the verdict; if it times out, it fails closed.
1. Ingest a gate
POST /api/v1/tasks
Authorization: Bearer $LOOPQUEST_KEY
{
"module": "swiper",
"mode": "gate",
"timeout_seconds": 1800,
"on_timeout": "escalate",
"payload": { "refund": 240, "reason": "late" },
"callback_url": "https://you/verdict"
}2. Poll, or receive the webhook
GET /api/v1/tasks/{id}
{
"id": "…",
"status": "reviewed",
"mode": "gate",
"verdict": true,
"timed_out": false,
"reviewed_at": "…"
}3. The verdict webhook
POST https://you/verdict
X-LoopQuest-Signature: sha256=…
{
"task_id": "…",
"verdict": true,
"resolved": true,
"timed_out": false
}Every webhook is HMAC-signed, so you can verify it with your LOOPQUEST_WEBHOOK_SECRET. Monitor tasks use the exact same call with mode: "monitor", you simply don't wait on the result.
Never hangs
Fail-closed timeouts & SLAs.
A blocking gate is only safe if it can't wait forever. Give a gate a timeout_seconds and an on_timeout policy. If no human rules in time, LoopQuest applies the default automatically and tells your webhook it timed out.
Enforcement doesn't depend on any one server. A minute-level sweep resolves expired gates, and any poll resolves its own. The default is fail-closed, so silence never becomes a silent yes.
on_timeout: escalateThe default. Hands it to senior reviewers and notifies managers, and the automation stays blocked until a human rules. Safest for regulated gates.
on_timeout: rejectReturns a reject verdict, so the downstream action is refused outright. Strict, and best when the cost of a wrong yes dwarfs a missed item.
on_timeout: approveAuto-approves to keep throughput moving. Only for low-risk gates, never for compliance-critical decisions.
Across every integration
How the gate wires into your stack.
Monitor mode is fire-and-forget everywhere. A blocking gate depends on whether the tool can pause. Here is how each one does it; open any integration for a full recipe and flow diagram.
Native pause & resume
The run suspends after ingest and resumes the instant the verdict callback arrives — the cleanest true gate.
Full control (code & visual builders)
Await the verdict by polling GET /tasks/{id} or your own callback. Your rules, your branch on approve / reject.
Human surface
Surfaces reviews and verdicts to people — pair it with any of the above as the place humans actually decide.
Questions
Common questions
What is a human in the loop?
A human in the loop is a person who reviews or approves what an automated system does, so a model is not the sole decision-maker. LoopQuest is the layer that inserts that human step into your AI workflow and records it.
Can LoopQuest block an automation until a human approves?
Yes. Send a task in gate mode and the automation waits: the downstream action only fires when a reviewer approves. You receive the verdict by webhook or by polling, and a fail-closed timeout means a missing decision never hangs the pipeline forever.
What is the difference between gate and monitor mode?
Gate mode is blocking — the automation pauses until a human approves, for decisions that must have a person answerable. Monitor mode is non-blocking — the flow proceeds immediately and LoopQuest reviews a copy for quality, drift and accuracy. You choose per task with the mode field.
When does the law require a human in the loop?
Across regulated domains a person, not just a model, often has to be answerable for consequential decisions. Examples include GDPR Article 22 on solely automated decisions, EU AI Act Article 14 on human oversight of high-risk systems, and sector rules in healthcare, financial services and online platforms. This is context, not legal advice — confirm your obligations with qualified counsel.
Which tools does LoopQuest integrate with?
LoopQuest works with n8n, MCP agents (Claude, Cursor), Zapier, Make, Dify, Pipedream, Activepieces, Power Automate, LangChain, LlamaIndex, the Vercel AI SDK and any custom code via the REST API. Each integration page has a gate and monitor recipe with a flow diagram.
What happens if no one reviews a gated task in time?
Every gate can carry a timeout and an on_timeout policy. The default is fail-closed: it escalates to senior reviewers rather than silently approving. You can also choose reject, or approve for low-risk gates. Enforcement runs every minute, independent of any one server.
How does LoopQuest keep reviewers from rubber-stamping?
The Decoy Matrix seeds a mathematically generated decoy error every 50 to 100 tasks. Catching it is rewarded; missing it triggers an alert and is logged. That gives you a measurable, auditable signal that reviewers are genuinely engaged rather than approving on autopilot.