Overview
Human-in-the-loop (HITL) means requiring human approval before AI agents perform certain actions. This is critical for:- High-stakes operations: Deleting data, making purchases, sending communications
- Compliance requirements: Regulated industries requiring human oversight
- Safety guardrails: Preventing unintended consequences in production
- Gradual trust building: Starting with oversight, removing it as confidence grows
What’s in this guide:
- The Core Pattern — Basic HITL implementation (start here)
- Decision Types — Approve, edit, or reject with feedback
- Approval Mechanisms — CLI, web dashboard, Slack, conditional, and more
- Practical Examples — Real-world deployment, support, and data analysis use cases
- Advanced Patterns — Batch approvals, budgets, time-based rules, audit trails
- Best Practices — Production-ready tips for scaling HITL systems
The Core Pattern
Instead of passing a function directly to an agent, wrap it with approval logic:Decision Types
When reviewing an action, you have three typical options:| Decision | Description | When to Use | Agent Response |
|---|---|---|---|
| Approve | Execute the action exactly as proposed | Action is correct and safe | Proceeds with execution |
| Edit | Modify arguments before executing | Action is almost right but needs tweaking | Executes with your changes |
| Reject | Deny the action with feedback | Action is wrong or unsafe | Sees your feedback and adapts strategy |
Approve: Execute As-Is
Approve: Execute As-Is
Edit: Modify Before Executing
Edit: Modify Before Executing
Modify the agent’s proposed arguments before executing. This is useful when the action is almost right but needs adjustment:
Reject with Feedback
Reject with Feedback
Deny the action but provide feedback that helps the agent understand why and try a different approach:
When you raise an exception with a descriptive message, the agent sees that message and can adjust its strategy. For example, if you reject a query because “must use READ ONLY transaction,” the agent might then add that to its next attempt.
Approval Mechanisms
How you ask for approval depends on your application context. Here are practical patterns:Terminal/CLI Approval
Terminal/CLI Approval
Perfect for development, scripts, and command-line tools:
Browser Alert/Confirm
Browser Alert/Confirm
For web applications running in the browser:
Web Dashboard Approval
Web Dashboard Approval
For production systems with approval workflows, you may want approvals to go through a proper web interface where managers can review requests, see context, and make informed decisions. This is especially useful when:
- The person approving isn’t at their terminal
- You need a record of who approved what and when
- Multiple people might need to approve the same action
- You want to batch approval requests for review
Slack/Teams Approval
Slack/Teams Approval
Request approval via chat platforms where your team already is:
Conditional Approval
Conditional Approval
Only require approval for high-risk operations:
Practical Examples
Example: Deployment Pipeline with HITL
Example: Deployment Pipeline with HITL
An agent that can deploy code, but requires approval for production:
Example: Customer Support with Refund Approval
Example: Customer Support with Refund Approval
Agent handles support tickets but requires approval for refunds:
Example: Data Analysis with Destructive Action Gates
Example: Data Analysis with Destructive Action Gates
Agent can query data freely, but needs approval for modifications:
Advanced Patterns
Batch Approvals
Batch Approvals
When an agent wants to perform multiple actions at once, you can collect them all, review them together, then decide on each one.How it works:Example: Agent adapts based on approval results
- When the agent calls a wrapped function, instead of executing immediately, the call is queued and a placeholder like
"PENDING_APPROVAL_1"is returned to the agent - The agent continues executing and may queue multiple actions
- After the agent finishes, you call
review_and_execute()to see all pending actions at once - You can approve all, deny all, or handle each individually
- The actual functions execute based on your decisions
Key insight: By providing
wait_for_approvals() to the agent, the agent can:- Queue up actions (getting placeholders back like
"PENDING_APPROVAL_1") - Call
wait_for_approvals()to block until human review - Receive a dict mapping action IDs to actual results:
{1: "Deleted user 123", 2: "REJECTED: ..."} - Adapt based on what was approved vs rejected
if "REJECTED" in results[1] to handle denied actions differently.Alternative: If you don’t give the agent wait_for_approvals(), it will receive placeholders and complete without knowing the real outcomes. Useful when the agent doesn’t need to adapt based on approval decisions.You can customize this pattern however you want: web UI for review, role-based approvals, risk-level grouping, timeouts—just code it.Approval Budget
Approval Budget
Allow a certain number of operations without approval, then require oversight:
Time-Based Approval
Time-Based Approval
Require approval during business hours, allow automation off-hours:
Audit Trail
Audit Trail
Log all approval decisions for compliance:
Why This Approach Works
Key insight: Agentica agents call real functions, not schema definitions. This means HITL is just wrapping functions—no special framework features needed.
delete_file to an agent, the agent literally calls your delete_file function through RPC. There’s no schema layer, no tool registry, no execution middleware.
This means:
- You control execution — wrap functions however you want
- Use any approval mechanism — terminal, web, Slack, custom systems
- Standard programming patterns — decorators, higher-order functions, classes
- No framework lock-in — approval logic is in your code, not the framework
Best Practices
Make Denial Clear to the Agent
Make Denial Clear to the Agent
When denying an action, raise an exception with a clear message. The agent sees this and can adapt:The agent might then try an alternative approach based on the error message.
Different Approval Levels for Different Risks
Different Approval Levels for Different Risks
Not everything needs the same oversight:
- Low risk: Auto-approve, just log
- Medium risk: CLI approval for development
- High risk: Dashboard with multiple approvers
- Critical: Require manager approval + audit trail
Make Approval Optional per Environment
Make Approval Optional per Environment
Use environment variables to control approval requirements:
Timeout Approval Requests
Timeout Approval Requests
Don’t wait forever for approval: