Approval gates put humans in control of consequential agent actions—allowing agents to propose while requiring confirmation before execution. See approval gates in action →
Agents become useful when they can take action. They become dangerous when they take the wrong action. Approval gates are the mechanism that puts humans in control of consequential actions - allowing agents to propose actions while requiring human confirmation before execution. This balance preserves the automation benefits of agents while preventing the disasters that unchecked automation can cause.
The Control Problem
As agents gain more capabilities, the scope for damage grows. An agent limited to answering questions can give wrong answers, but the damage is limited. An agent that can send emails, delete data, make purchases, or post publicly can cause irreversible harm in seconds.
The straightforward response is limiting what agents can do. Restrict them to safe operations. But this undermines their value - agents that cannot take action are just expensive chatbots.
A better approach is selective control. Let agents perform routine operations automatically while requiring approval for operations with significant consequences. This preserves automation benefits for low-risk actions while maintaining human oversight for high-risk ones.
Approval gates implement this selective control at the tool level. Certain tools - the ones that take consequential actions - are marked as requiring approval. When an agent wants to use such a tool, execution pauses, the proposed action is presented to a human, and the human decides whether to proceed.
How Approval Gates Work
The flow is straightforward. An agent decides to call a tool marked as requiring approval. Instead of executing immediately, the system pauses and surfaces the proposed action. The human sees exactly what the agent wants to do - the specific tool, the specific parameters, the context of why.
The human has three options. Approve allows the action to proceed as proposed. Reject blocks the action and informs the agent. Modify allows changing parameters before approval.
After approval or rejection, the agent continues. On approval, the tool executes and the agent proceeds with the result. On rejection, the agent receives feedback that the action was not permitted and can adjust its approach - perhaps asking clarifying questions, suggesting alternatives, or proceeding without that particular action.
This flow happens automatically for any tool marked as requiring approval. No custom code needed for each tool. No building approval interfaces from scratch. The marking is the configuration; the infrastructure handles the rest.
inference.sh makes approval gates one flag. Mark any tool as requiring approval and the runtime handles the rest: pausing, presenting, collecting decisions, resuming. Learn more →
Deciding What Needs Approval
Not every action warrants human review. Requiring approval for everything creates approval fatigue where humans rubber-stamp without reviewing, defeating the purpose.
Read-only operations rarely need approval. Searching the web, reading files, querying databases for information - these have no lasting effects. Even incorrect results do not cause direct harm.
Reversible operations fall in a gray area. Creating a draft, staging a change, adding an item to a queue - these can be undone. Whether they need approval depends on the cost of the undo operation and the visibility of the intermediate state.
Irreversible operations almost always warrant approval. Sending an email cannot be unsent. Deleting data may be unrecoverable. Publishing content is immediately visible. These actions have permanent consequences.
External communications deserve special scrutiny. Messages to customers, posts on social media, responses in support tickets - these represent your organization to outsiders. Even if technically reversible, the impression is permanent.
Financial operations require approval almost universally. Real money is at stake. Even small amounts matter; larger amounts matter more.
A useful heuristic: if you would want this action in an audit log with a record of who approved it, then require approval before it happens.
The Approval Experience
What users see during approval significantly affects whether they make good decisions.
Effective approval requests show the complete proposed action. For an email, show the recipient, subject, and full body text. For a database operation, show the exact query or records affected. For a financial transaction, show all the details that a human would want to verify.
Context helps. Why is the agent proposing this action? What was it trying to accomplish? What conversation led to this point? Approval requests that explain the reasoning help humans evaluate whether the proposed action makes sense.
Time pressure is manageable when the system is designed for asynchronous approval. Not every approval needs to happen in seconds. Some agents can continue other work while waiting. Some tasks can tolerate delay. Design for realistic human response times rather than assuming instant decisions.
Audit and Accountability
Every approval decision creates a record. This audit trail serves multiple purposes.
For debugging, when something goes wrong, the audit trail shows exactly what was proposed, who approved it, and when. The problem might be in what the agent proposed or in what the human approved - the record distinguishes these.
For compliance, many contexts require documentation of who authorized what actions. Agent-initiated actions are no different. The audit trail provides evidence that appropriate oversight occurred.
For analysis, patterns in approvals reveal opportunities. High rejection rates for certain action types suggest the agent should not be proposing them. Consistent modifications to parameters suggest the agent should learn those preferences.
The audit trail should capture the complete context: what was proposed, what was approved (which might differ after modification), who approved, when, and what conversation context led to the proposal. Complete records enable complete analysis.
Advanced Patterns
Beyond simple approve/reject, several patterns extend approval gates for specific needs.
Conditional approval makes approval depend on parameters. A purchase under $50 might proceed automatically while larger purchases require review. An email to internal addresses might proceed while external emails need approval. The condition captures the risk distinction within a single tool.
Delegation routes approvals to appropriate people. Financial actions might go to finance. Technical actions might go to engineering. Different actions have different appropriate approvers based on expertise and authority.
Escalation handles unanswered approvals. If the primary approver does not respond within a time limit, the request might escalate to a secondary approver, or to a broader pool, or might default to rejection.
Batching handles multiple similar actions. If an agent wants to send fifty similar notifications, reviewing each individually is tedious. Batch approval lets the human review the pattern and approve all at once, or reject all, or review individually.
These patterns adapt the basic approval flow to practical organizational needs. Not every deployment needs all patterns, but having them available enables appropriate configuration for different use cases.
Integration with Agent Design
Approval gates affect how agents should be designed.
Agents should be prepared for rejections. When an action is rejected, the agent should handle this gracefully - not error out, but adjust. The agent might ask for clarification, propose an alternative, or explain why it cannot complete the task without that action.
Agents should provide good context. The information shown during approval often comes from the agent's explanation of what it is doing. Agents that explain their reasoning clearly produce better approval experiences.
Agents should not assume approval. Long sequences of approval-required actions can create poor experiences. Agents should consider batching related actions or confirming the general plan before attempting each detailed action.
Prompts should acknowledge approval gates exist. System prompts can explain which actions require approval, helping agents understand that certain operations will not execute immediately and might be rejected.
For teams building agents with consequential capabilities, inference.sh provides approval gates as a native runtime feature. Tools marked as requiring approval automatically pause for human review. The infrastructure handles the approval flow, audit trail, and agent notification. You focus on deciding what needs approval and designing agents that work well within that model.
Approval gates are not a limitation on agent capability. They are what makes powerful capabilities safe to deploy. The combination of automation for routine actions and oversight for consequential ones gives you the benefits of both without the risks of either alone.
FAQ
How do I prevent approval fatigue from undermining the purpose of gates?
Approval fatigue occurs when humans approve everything without real review, usually because too many low-value approval requests train them to ignore the process. Prevention starts with being selective - only require approval for genuinely consequential actions. If everything requires approval, nothing gets real review. Monitor approval patterns: if approval rates are near 100% with very short decision times, humans may be rubber-stamping. Consider whether some approved categories could be automatic. Provide good context so reviews are quick for appropriate approvals and slower for questionable ones. The goal is few enough approvals that each gets genuine attention.
What happens to the agent while waiting for approval?
Well-designed approval systems checkpoint the agent's state when waiting begins. The agent is not actively running and consuming resources during the wait. When approval arrives - whether seconds or hours later - execution resumes from the checkpoint. Some architectures allow the agent to continue other work while specific actions await approval. The user experience during the wait depends on the interface, but typically shows that action is pending. If approvals systematically take too long, consider whether the approval routing is appropriate or whether some actions could be automatically approved based on refined conditions.
Can approval patterns change over time as trust develops?
Yes, approval requirements can evolve. An agent that consistently makes good proposals for a certain action type might graduate to automatic execution after demonstrating reliability. This should be an explicit decision based on review of the approval history, not automatic trust escalation. Moving from approval-required to automatic is a significant change that should be deliberate. The reverse is also possible: if an automatic action causes problems, it can be moved to require approval. Treat approval requirements as configuration that can be tuned based on experience, with changes documented and reviewed.