Platform · Govern · Human-in-the-loop

Approvals

Autonomy that stops and asks. When policy holds an action, it lands in one queue with the reason attached, waits for a human — or their delegate — and releases exactly once. The decision, the decider and what executed become part of the same audit trail as the run itself.

See it live The governance layer
At a glance
  • Grantssingle-use, 24h expiry
  • Held itemspolicy shown, in plain language
  • Identical asksgrouped · bulk up to 50
  • Absencesdelegation, on-behalf-of stamped
  • Stale requestsauto-escalate to admins
  • Surfacesweb · mobile · desktop · extension
app.turtlecoworker.com/approvals
The approvals queue: pending requests with aging chips, grouped identical asks, the holding policy on each card, and bulk actions
Everything waiting on a human, in one place — each item with the rule that held it and how long it has waited.
Why it's built this way

An approval is an accountability
transfer, not a speed bump.

When an agent acts autonomously, the organization owns the outcome. When a human approves the action, a named person owns it — with the policy, the payload and the timestamp on record. That chain is what lets an enterprise say yes to autonomy at all.

So the queue is built like a control, not a chore: explained holds, grouped decisions, covered absences, hard expiry, and a record that writes itself. The gate is exactly as wide as your policy says, and never wider.

How it works

From held, to human, to on the record.

Six properties that make human-in-the-loop workable at enterprise volume — without softening the gate.

01 · Two floors

Plan approval and action approval are separate gates.

There are two different questions a human can be asked, and the platform keeps them apart. The autonomy floor asks: may this worker pursue this plan at all? The compliance floor asks, later and independently: may this specific tool call execute? Approving a plan never silently approves its writes — a policy-held action still stops and asks, even inside an approved plan.

  • Plan approval: the autonomy scope decides whether a plan needs sign-off
  • Action approval: the policy engine holds individual tool calls regardless
  • The two floors never collapse into one blanket 'yes'
shot: hitl-two-floorsA task showing plan-level approval status alongside a separately held tool call awaiting its own approval
One task, two gates: the plan cleared, one write still held
02 · Single-use grants

An approval releases one action. Then it's spent.

Every grant is consumed by the first matching call. Approve an email send and exactly one email sends; the next send creates a fresh request. Grants are scoped to the workspace, the worker and the tool, and expire on their own in 24 hours if unused. There is no 'approved forever' state quietly accumulating in the background.

  • Consumed on first use: the next identical action asks again
  • Scoped to workspace + worker + tool; expires in 24h unused
  • Standing permissions are policy changes — explicit, versioned, audited
An approval grant shown as consumed, with the follow-up action creating a new pending request
Spent on use: the second ask is a new ask
03 · The queue

One inbox, with the why attached.

Everything waiting on a human sits in one queue, not scattered across email threads. Each item carries the policy that held it — the rule, in plain language — the sanitized payload, and how long it has waited. Identical asks group into one card so a batch of fifty matching requests is one decision, not fifty. Aging is visible at a glance and escalates before it becomes a problem.

  • Policy explainability: every held item shows the rule that held it
  • Identical asks group; bulk approve or deny up to fifty in one move
  • Aging indicators, then auto-escalation to admins for stale requests
The approvals queue: grouped identical requests, aging chips, the holding policy on each card, bulk approve and deny controls
The queue: grouped, aged, explained
04 · Delegation

Approval authority has an out-of-office.

An approver going on leave delegates their authority for a window — one active delegation per person, org-scoped, revocable at any time. The delegate sees and decides the delegator's queue, and every decision made this way is stamped 'decided on behalf of' in the audit trail. Work doesn't pile up behind an empty chair, and accountability never blurs.

  • Out-of-office delegation windows, one active per approver
  • Delegates must hold standing to decide; delegation is revocable instantly
  • Every delegated decision stamped on-behalf-of in the trail
The delegation setup: choosing a delegate and a date window, with the active delegation shown on the approvals view
The chair is covered, and the record says by whom
05 · Anywhere

The gate travels with the approver.

A held action is only as good as the human's ability to reach it. The queue is on the web app, the mobile app, the desktop app and the browser extension, with the same policy context everywhere. Critical holds — a circuit breaker halt, a hard budget cap — push through quiet hours; routine ones respect them. A run blocked at 6pm doesn't wait for a laptop to open at 9.

  • Web, mobile, desktop and browser extension, one queue
  • Critical alerts override quiet hours; routine ones respect them
  • Approve, deny or delegate from wherever the notification lands
The mobile approvals view: aging chips, a grouped identical-ask card with approve-all and deny-all, and the policy detail sheet
The queue in a pocket: same context, same controls
06 · The record

Every decision becomes evidence.

Who approved what, when, under which policy, on whose behalf, and what executed as a result — all of it lands in the same audit trail as the runs themselves, pinned to the config version in force at the time. When someone asks 'who authorized this?', the answer is a row, not a reconstruction.

  • Decision, decider, timestamp, policy and on-behalf-of stamp, recorded
  • Joined to the run and tool call it released
  • Exportable with the rest of the audit trail
An audit trail entry for an approval decision: approver, timestamp, the policy, the delegation stamp and the released action
The decision as the auditor will see it
The payoff
1
action per grant: approvals release exactly one call, then the next one asks again.
50
identical requests cleared in one decision, grouped and bulk-approved from a single card.
24h
and an unused grant expires on its own — no permission quietly outliving its purpose.
4
surfaces carrying the queue: web, mobile, desktop and browser extension, one context.
Questions

The details, up front.

Doesn't human-in-the-loop defeat the point of automation?
Only if everything needs a human. The point of the policy engine is precision: routine reads and low-stakes writes flow untouched, while the actions you've defined as consequential — external writes, spend over a threshold, specific functions — stop and ask. Most runs never see a gate. The ones that do are exactly the ones your risk team wants a human on.
What keeps approvals from becoming a bottleneck?
Four things. Identical asks group into one decision, with bulk approve up to fifty. The queue travels — web, mobile, desktop, extension — so decisions happen where the approver is. Delegation covers absences without loosening the gate. And anything that still sits too long auto-escalates to org admins rather than silently aging.
Can an approval be scoped to 'always allow this from now on'?
Deliberately not from the queue. A grant releases one action and expires. If a class of action should stop asking, that's a policy change — made in the policy builder, versioned, visible to admins, and evaluated like every other rule. Broad permissions should look like policy, not like approval fatigue.
What happens if nobody approves in time?
The request escalates to org admins after a configurable threshold, and the run stays paused — the action does not execute by default. Unused grants and unanswered requests expire; expiry is recorded like any other outcome.
How do approvers know what they're approving?
Each card shows the action itself with its payload sanitized, the worker and run it came from, and the specific policy rule that held it, in plain language. On mobile, the same policy-explainability detail is one tap away. Nobody is asked to approve a mystery.
Is the mobile app required for this?
No. The queue is fully operable from the web app. The mobile app, desktop app and browser extension exist so that being away from the dashboard doesn't mean being away from the gate.
The other half

The rules that decide what gets held: the Governance layer.

Governance Apps & surfaces