A human-in-the-loop workflow pauses an agent at a defined decision point, shows a person the proposed action and relevant evidence, and resumes only after an authorized decision. Separate approval of a finished deliverable from permission to send, publish, spend, delete or deploy.
Choose the decision boundary
Start with a specific action: sending a client report. The agent can research and draft within its permitted scope, but external delivery waits. Name who may approve it and what happens if that person rejects the request or does not respond. A chat notification after sending is an audit event, not a pre-action approval.
A review stage can also prevent a task from closing until its deliverable is accepted. That is useful, but it does not by itself prevent an email tool from sending the draft early. Choose the boundary at the operation you actually need to control.
Show an exact request a person can judge
For the report example, include the intended recipients, final subject and body, attachment version, client, source task and why delivery is requested. Link the evidence the reviewer needs. Avoid asking “may I email the client?” before the message exists.
| Approval field | Illustrative request |
|---|---|
| Action | Send the approved weekly report |
| Target | The named client contact, checked against the task |
| Content | Final message and linked report version |
| Scope | This client and reporting project |
| Decision | Approve this request once, or reject and explain |
If the recipient, message or attachment changes, treat it as a changed proposal. Do not silently reuse an approval for a different operation.
Put the check before the tool call
An approval workflow needs cooperation between the management layer and the executor. The runtime must stop before its external operation, ask through the approval mechanism, and perform only the approved action. Giving it unrestricted credentials while merely asking it to “be careful” leaves a different technical boundary.
In EmperorClaw, action settings offer Off, Ask first and Allowed, with company defaults and per-agent overrides. Governed Emperor API writes are checked by the server. For external email, shell and other runtime tools, the runtime must call check_action. Emperor cannot intercept arbitrary tool calls outside its API.
Sending email, posting, spending, deleting and deploying ask first by default. Browsing and shell commands are allowed by default. Review those defaults against the actual tool access and credentials of each worker.
Make rejection and waiting normal states
If the reviewer rejects the report, preserve the request and reason, update the task with the required changes and return it to its owner. The next proposed action must reflect the revised content. If approval is still pending, show the work as waiting rather than running an expensive loop asking the same question.
Decide how people cover absences and stalled decisions. Keep that operational process separate from giving every agent the right to approve its own work. A manager on an org chart does not automatically gain access to every client record.
Test the approval flow before using it with customers
- Propose a harmless test action with complete arguments.
- Confirm it has not happened while approval is pending.
- Reject it and confirm nothing was executed.
- Approve a fresh request and confirm it executes once.
- Change one argument and confirm the earlier decision is not reused.
- Restart or disconnect the runtime and inspect how pending work recovers.
Use a test destination and the smallest practical permissions. For uncertain delivery, investigate the external system before retrying. A clean approval record does not prove a third-party service completed the action.
Common questions
Should every agent action require approval?
Choose the decision points that need judgment or authority. Requiring review of every low-impact read can consume the attention needed for consequential actions. Match the policy to the workflow and runtime permissions.
Can an approval replace a sandbox?
No. Approval is a decision mechanism. Filesystem, network, credentials and tool restrictions determine what the runtime can technically reach.
Does turning off approval history disable approvals?
In EmperorClaw, disabling the Approval history module hides that history page. Action requests and project sign-off still reach Inbox.
Configure the first controlled handoff
Pick one agent and one external action. Review its Scope and Actions settings, draft a complete request and run the rejection test before granting an approval. Then add task completion review where the deliverable itself needs sign-off.
See action permissions in EmperorClaw and approval gates in recurring automations for setup details.