The human-in-the-loop model
Human-in-the-loop AI agents require human approval before executing any write action. The agent proposes what to do, shows you exactly what will change, and waits for approval. Nothing writes to your tools without explicit sign-off.
This model is useful when teams want AI help without losing visibility or control. It keeps the person closest to the task in the loop while trust is still being built.
Agent proposes
The agent analyzes the task, determines what to do, and proposes an action for review.
Human reviews
You see what will change, in which system, and why. The agent shows the old value and the new value with context.
Human approves
Approve or reject. If approved, the agent executes the write and logs it. If rejected, the team can tighten instructions or keep approvals on longer.
The approval flow
The approval flow is designed to give you full visibility into what the agent wants to do before it executes. Every proposed write includes context, reasoning, and the exact values that will change.
What you see in the approval request:
- System and object: Which system the agent wants to write to (Salesforce, Zendesk, QuickBooks). Which object or record (a specific lead, ticket, or invoice).
- Field and values: Which field the agent wants to change. The old value and the new value, side by side.
- Context and reasoning: Why the agent is proposing this change. What triggered the task. What data the agent analyzed.
- Risk assessment: The platform flags high-value or high-risk changes (financial writes, customer-facing changes).
What happens after you approve or reject:
- Approve: The agent executes the write immediately. The action is logged in the audit trail with your approval timestamp.
- Reject: The agent does not execute. The rejection is logged. You can leave a note so the next version is clearer.
Approval patterns by task type
Different tasks need different approval patterns. Some can loosen sooner. Others should stay approval-first for much longer.
| Task type | Approval pattern | When to loosen approvals |
|---|---|---|
| Lead routing | Keep approvals on while the team checks source quality and assignment rules. | Loosen only once edge cases are boring and easy to spot. |
| Ticket triage | Start approval-first, especially with ambiguous or high-priority tickets. | Loosen for repetitive cases with clear rules. |
| Financial changes | Keep approvals on for any action that changes money, invoices, or refunds. | Usually keep approvals in place. |
| Customer-facing changes | Review anything that changes what a customer sees or receives. | Loosen only when the content is low-risk and tightly scoped. |
When to loosen approvals
Start by assuming approvals stay on. Only reduce review when the task is low-risk, the pattern is clear, and the team can explain why it trusts the agent.
- Mistakes are easy to reverse. If the worst case is small and obvious, the team can consider reducing review.
- The task repeats with clear inputs. A messy task with changing context usually needs approvals for longer.
- Reviewers rarely disagree on the right action. If people still debate decisions, the task is not ready for lighter review.
- The plan and cost are consistently clear. If reviewers still need to guess, keep approvals on.
Frequently asked questions
Do we have to approve every action manually forever?
No. Start with approvals on. Keep them in place until the team understands the pattern and the task feels predictable. High-risk actions may stay approval-first much longer.
What happens if we reject an agent's proposed action?
The action does not happen. The rejection is logged, and the team can tighten instructions or keep approvals on longer for similar cases.
Can we set different approval rules for different tasks?
Yes. A low-risk task like ticket tagging can loosen sooner than invoice updates or customer-facing changes. Approval rules should match the risk of the task, not a single company-wide rule.
Who reviews approvals when the technical owner is unavailable?
The person closest to the business task should review it. Sales ops handles sales records. Finance handles financial changes. The goal is domain judgment, not technical depth.