Approvals and autonomy
How Yodu's human-in-the-loop model works — what triggers an approval, the inline chat card and the queue, Allow once / This session / Deny, and how the gate composes with per-employee tool switches.
An AI employee prepares work freely; it does not release work freely. Anything external or irreversible pauses at the approval gate for a human decision. This page explains what triggers the gate, where the decision happens, what each decision means, and what the employee does afterward.
What triggers an approval
The gate keys on the action class, not on which tool is used or how the tool was configured:
| Action class | Examples |
|---|---|
| Send | An email to a customer, a Slack message outside the team |
| Post or publish | A blog article, a social post, a CMS change |
| Spend | A refund, a charge, a subscription change |
| Delete | Removing records, files, or resources in a connected system |
| Change external state | A CRM lifecycle update, a repository write, a production change |
Reading, researching, drafting, and producing files inside the workspace do not stop for approval — that is the work you hired the employee to do. The pause happens at the moment the work would leave the workspace or become hard to undo.
Where the decision appears
The same request surfaces in two places:
- The inline card in chat. If you are in the employee's channel, the request appears in the conversation with the prepared action and its context. Decide right there and the conversation continues.
- The Approvals queue. Every pending request also appears under Approvals, with the linked task and evidence. Use the queue when you were not watching the chat, or to review several requests in one sitting.
Either surface settles the request; you do not need to answer in both.
The three decisions
| Decision | Meaning | Use it when |
|---|---|---|
| Allow once | Run exactly this action, one time | The action is correct and one-off |
| This session | Allow this kind of action for a few hours | You are iterating with the employee and would approve each one |
| Deny | Do not run it; the employee keeps the context and can revise | The action is wrong, premature, or missing evidence |
This session is an allowance, not a policy change. It expires after a few hours, and it appears under remembered permissions in Approvals, where you can revoke it early. Settled decisions stay in the audit history.
After the decision
- On Allow once or This session, the employee resumes immediately: the action runs, the result lands in the channel or task, and work continues without a re-prompt.
- On Deny, the action does not run. The employee keeps its context — tell it what was wrong in the channel, or record the correction on the task, and it revises rather than starting over.
A deny is feedback, not a failure. Denying a premature send and correcting the draft is the loop working as designed.
How this composes with tool switches
Tool access and approvals answer different questions:
| Layer | Question it answers | Granularity |
|---|---|---|
| Tool switch | Should this employee see this tool at all? | Per employee, per tool, on or off |
| Approval gate | Should this specific action run right now? | Per action, decided by a human |
A disabled tool never reaches the gate — the employee cannot see it, so nothing is prepared. An enabled tool reaches the gate for every risky action class, no matter which employee holds it or how routine the work has become. There is no per-tool mode in between: no draft-only tier, no per-grant autonomy setting. Visibility is the switch; safety is the gate.
This is why enabling a tool is a low-stakes decision. You are deciding what the employee can work with, not what it may do to the outside world. See Tool access per employee for the switch model.
Review habits
- Check Approvals at least daily; a request waiting for days blocks the task behind it.
- Read the linked task and evidence before allowing — the card shows the prepared action, but the task shows why.
- Prefer Allow once until a workflow has produced several correct requests in a row; then use This session while actively iterating.
- Revoke session allowances you no longer need rather than letting them expire quietly.
- When you deny, say why in the channel — the correction is what improves the next request.
Continue with Task board and approvals for how approvals attach to the work lifecycle, and Security and trust for the layers around the gate.
Task board and approvals
Create, assign, move, review, and close AI employee work with a consistent task lifecycle and human approval queue.
Schedules and recurring work
Create, test, pause, edit, and review recurring AI employee jobs in Yodu with clear owners, timing, run history, and approval controls.