> ## Documentation Index > Fetch the complete documentation index at: https://docs.duvo.ai/llms.txt > Use this file to discover all available pages before exploring further. # When the Agent Should Ask, Not Act > Approval gates fire only where the AOP asks for them, the request goes to one specific person, and there is no timeout — a well-designed gate names the action, reaches the right inbox, and is worth waiting for. Human-in-the-loop has two failure modes, and they cost you in opposite currencies. Gate too little and one bad Run sends the wrong email or pays the wrong invoice. Gate too much and your team spends its day approving routine work — while Runs sit paused, waiting. This page is the decision framework: when a gate earns its place, how to phrase it so it actually fires, and how to design around the platform's real semantics. For the mechanics of requests and responses, see [Human-in-the-Loop](/user-guide/assignment-features/human-in-the-loop). ## The Contract: Gates Live in the AOP, Nowhere Else The Agent is explicitly instructed **not** to ask for approval on its own judgment. It pauses only where the AOP tells it to — and when the AOP is silent, it proceeds and reports what it did. Two consequences: * **An ungated risky step will run.** "It's obviously dangerous, surely it will check first" is not how it works. If sending, paying, deleting, or posting needs a human, the AOP must say so. * **Any clear phrasing works.** "Get my go-ahead before sending", "confirm with me first", "don't submit without approval" — all of these arm the gate. You don't need to name a tool or say "HITL". What doesn't work is hoping the Agent infers it. One more contract detail that surprises people: text the Agent writes in the Run is a record, not a message. It notifies nobody and gets no answer. Only an actual approval request pauses the Run and reaches a human — which is exactly why the AOP phrasing matters. ## Which Actions Earn a Gate Score the action, not the Agent. The [risk-tier framework](/user-guide/assignment-features/hitl-design) does this in detail; the short version is two questions: * **Can it be undone?** Drafting, reading, computing, writing to an internal staging sheet — reversible, no gate. Sending, posting publicly, paying, deleting — irreversible, gate candidates. * **How wide is the blast radius?** One internal record vs. a customer, money, or your brand. Then gate the **branch**, not the Run. "Request approval before any action" turns a colleague into the Agent's babysitter. "Request approval before sending if the refund exceeds €200, otherwise proceed" pauses only the Runs that need a human — most Runs complete untouched, and the approvals that do arrive are worth reading. Make the request self-contained. The approver sees a title and a description — write the AOP so they carry the decision: what will be done, to whom, the amount, and why the Agent believes it's right. An approval that requires opening the Run to understand it wastes the reviewer's time twice. ## Know Whose Inbox It Lands In An approval request always goes to the **Run's author** — and for unattended Runs, that resolves to a specific person you chose earlier, perhaps without noticing: * A **scheduled** Run belongs to whoever created the schedule. * A **Case-triggered** Run belongs to the owner of the previous Run on that Case, falling back to whoever created the Case. The request appears on that person's [Requests](/user-guide/assignment-features/requests) page (the inbox is per-user, not team-wide), and — on by default, per-user in **Settings → Notifications** — as an interactive card in Slack or Microsoft Teams where they can approve without opening Duvo. There is **no email per request**; the only email surface is the opt-in daily summary of pending requests ("Daily email summary of requests", with a "Send at" hour). So before enabling a schedule with approval gates, ask: is its creator the right approver, are their Slack notifications on, and who covers their Requests page when they're on leave? An approval sitting in an absent person's inbox is the most common cause of "the Agent is stuck". ## Design for the Wait: There Is No Timeout When a gate fires, the Run's status becomes **Needs Input** and it waits — indefinitely. There is no platform timeout, no automatic escalation, and no fallback recipient. Don't write time-based escalation into the AOP ("if not approved within 4 hours, ask the account manager") — a paused Agent cannot act, so instructions like that are dead letters. Design with the real semantics instead: * **Gate only where an indefinite wait is acceptable.** If the action is time-critical and the approver might be away, an approval gate is the wrong tool — default to the safe action (skip, log, escalate the Case) and report, rather than pausing. * **A waiting Run occupies a Queue concurrency slot.** On a Queue running at its concurrency limit, unanswered approvals throttle everything behind them. High-volume Queues with approval gates need approvers who clear Requests daily — or a triage design where exceptions land in a review Queue instead of pausing Runs, as described in [Designing Human-in-the-Loop Workflows](/user-guide/assignment-features/hitl-design). * **Answer speed changes the resume, not the answer.** A response within hours resumes the Run in place. After long waits the Run continues in a fresh session with your answer in hand — it still continues correctly, but anything the Agent had "on screen" is re-derived, so very stale approvals cost more time. ## Rejection Is an Instruction, Not an Ending The approver's options are **Approve**, **Decline**, and free text — and free text is treated as a decline *with guidance*, which is often the most useful response ("not to this customer — send to the account on the parent order instead"). Write the AOP to make rejection productive: say what the Agent should do on a decline (fix and re-request once, or fail the Case with the reason), and stop after repeated rejection — being declined twice on the same action means the Agent has misunderstood the requirement, and the loop should end in a failed Case with a note, not a third request. ## Related Request types, AOP gate patterns, and response surfaces. Risk tiers, approval shapes, and exception-Queue patterns at scale. The per-user inbox where approvals and questions land. Hard caps, allow-lists, and shadow mode around the gates.