A human approval workflow for AI agents works best when reviewers receive a clear operational proposal, not an unexplained request to trust a model. Before an agent performs a consequential tool call, it should create a decision packet that states the intended outcome, affected records, proposed action, available evidence, expected impact, rollback position, and accountable decision owner.
This makes review faster and more accountable. The reviewer can assess the action that will actually occur instead of reconstructing context from model output, logs, and chat history. It also helps separate two responsibilities: the agent can propose an action, while a person or deterministic policy decides whether that action is authorized.
This distinction matters for internal agents that can change records, communicate externally, alter access, export information, or trigger other side effects. OWASP identifies excessive agency as a risk in LLM applications and recommends limiting tool authority, applying least privilege, and introducing human approval for actions with meaningful consequences. OWASP Top 10 for Large Language Model Applications
The goal is not to make every automated task manual. A useful queue lets narrowly scoped, low-risk actions proceed under policy while routing ambiguous, sensitive, high-impact, or difficult-to-reverse actions to the right person with enough context to decide quickly.
Build a decision packet before the tool call
An approval button alone creates work for the reviewer. A message such as “Approve customer update?” leaves unanswered questions: Which customer? What is changing? What system will receive the change? What evidence led the agent to propose it? Can the action be corrected afterward?
A decision packet answers those questions in a durable format. It is the record of one proposed action before execution, and it should remain available after a reviewer responds. The packet should describe the action in business terms while retaining the concrete execution details needed by operators and auditors.
Fields that make a packet reviewable
- Intent: A short description of the requested business outcome, such as updating a support case or granting temporary access.
- Affected records: Stable identifiers plus readable labels for the tickets, users, accounts, documents, or other entities involved.
- Proposed tool call: The tool name, normalized arguments, target system, and requested permission scope.
- Evidence: The relevant records, policy references, or inputs that informed the proposal. This should be more useful than raw model reasoning.
- Confidence: A team-defined signal that can help prioritize review, but does not itself authorize an action.
- Impact: The expected change, affected systems, and whether the action has an external effect.
- Rollback position: A compensation action, recovery owner, or explicit statement that the action cannot be reversed.
- Decision owner: The individual, role, or approval group responsible for approving, editing, rejecting, or escalating the request.
Packet detail should match the risk. A proposed customer email may need recipient details, a subject, a body preview, and a link to the related record. A proposed deletion may require the exact selection criteria, the retention basis used by the workflow, and an explicit indication that recovery is unavailable or requires a separate operational process.
Keep the primary view concise. Put supporting records, argument details, and related history behind links or expandable sections so a reviewer can move from a fast decision to deeper inspection when needed.
Route actions with deterministic policy
Approval queues need an explicit routing policy. The policy can consider the action’s scope, reversibility, data sensitivity, external communication, and whether its evidence is incomplete or conflicting. These are operational criteria, so the final routing decision should live in code or workflow configuration rather than in the model prompt.
| Action type | Typical handling | Packet focus |
|---|---|---|
| Narrow and reversible | Allow automatic execution under constrained permissions and retain an audit record. | Applied policy and result reference. |
| Ambiguous but reversible | Require one accountable owner to approve or edit before execution. | Evidence, proposed field changes, and rollback path. |
| External or sensitive | Require approval before the tool call. | Audience, data scope, requested permissions, and expiry. |
| High-impact or irreversible | Require a named owner and, where policy requires it, sequential or multi-person review. | Scope, impact, recovery position, and governing policy. |
A model may recommend a route, but it should not determine its own authority. This is especially important when an agent processes untrusted content or interacts with broad tool permissions. A deterministic gate can decide that a proposal must be reviewed, requires a particular role, or cannot execute at all.
Confidence is useful as queue context, not as a substitute for policy. A high-confidence proposal can still be inappropriate because it affects the wrong customer, changes a sensitive permission, or creates an irreversible outcome. Conversely, a low-confidence proposal may be harmless when constrained to a reversible internal task.
Make approval a durable workflow state
An approval request can remain open beyond the lifetime of a browser session, model call, notification, or service process. Treat it as durable workflow state with a packet ID, status, assigned owner, timestamps, decision history, and the exact payload that is eligible for execution.
LangGraph documents a human-in-the-loop pattern based on interrupts: an execution pauses before a tool invocation, persists its state through a checkpointer, presents structured data to an external client, and later resumes with a decision or edited input. LangGraph interrupts documentation The important design principle applies beyond LangGraph: approval is a workflow transition, not merely a modal dialog displayed during a request.
For Java services, durable orchestration can keep an approval workflow waiting without treating the review period as an open application request. Temporal documents workflows that wait on conditions, receive asynchronous Signals, expose state through Queries, and coordinate compensating activities. Temporal workflow message passing documentation A Java implementation can use this shape to persist the packet, notify the reviewer, receive the decision event, and then either execute the approved action or follow the appropriate rejection or recovery path.
Prevent stale or duplicate decisions
Version each packet. If the proposed arguments, affected records, impact, or policy result changes, the prior approval should no longer be sufficient. Create a new packet version and require a decision on that specific version.
For example, approval to grant one person a limited permission should not remain valid if a later proposal changes the recipient list or expands the permission scope. The execution layer should use only the packet version that the reviewer approved.
Decision actions also need idempotent handling. Once a valid approve, reject, edit, or escalation decision is accepted, later submissions should return the current state rather than produce another execution. This is important for chat notifications that may be opened from more than one device or by more than one reviewer.
Give reviewers useful choices
Approve and reject are necessary, but many operational workflows also need constrained edits and escalation. Each action should create a recorded state transition tied to an authenticated reviewer and the current packet version.
- Approve: Execute the exact approved packet after server-side authorization checks.
- Edit and approve: Permit changes to predefined business fields, validate them, and create a revised packet version before execution.
- Reject: Stop the proposal. Capture a structured reason where that feedback is useful for later policy or workflow improvements.
- Escalate: Route the packet to an owner with the required authority or domain knowledge.
Avoid exposing unrestricted tool-call JSON to general reviewers. A better interface lets them change business-level values that are explicitly allowed by policy, such as a recipient, record scope, access duration, effective date, or approved amount. The backend then reconstructs and validates the actual tool call.
Expiry is part of the workflow as well. Requests involving changing records, temporary permissions, or time-sensitive operations should expire according to the relevant business process. When the packet is no longer current, re-evaluate the relevant state and issue a fresh proposal rather than executing an old approval.
Deliver decisions in existing work surfaces
n8n supports human review of AI-agent tool calls by pausing before a sensitive operation and exposing the proposed tool name and parameters for review. Its documentation describes routing review interactions through workplace channels including Microsoft Teams, Outlook, and Google Chat. n8n human-in-the-loop tools documentation This can provide an implementation path for teams that want workflow-level approvals without first building a dedicated approval application.
For Microsoft 365, Adaptive Cards can place a compact packet summary inside Teams and Outlook. Microsoft documents Universal Actions using Action.Execute, including card refresh behavior and support for sequential approval experiences. Microsoft Teams Universal Actions documentation The interaction should send the packet ID, packet version, reviewer identity, and selected action to the service that owns the workflow state.
For Google Workspace, Google Chat dialogs and cards can collect structured input and return action callbacks to an application. Google Chat interactive dialogs documentation Dialogs fit edit-and-approve flows where the reviewer must choose among constrained options or supply a rejection reason. The canonical packet should remain in the workflow service rather than in chat-message content.
Microsoft’s agent APIs illustrate another useful interception pattern: sensitive functions can be wrapped so a proposed invocation creates an approval request and execution resumes only after an approval response. Microsoft ApprovalRequiredAIFunction documentation The same architecture can be applied in Java: place an approval gate between agent planning and any side-effecting capability.
Operate the queue after execution
The queue should provide a durable record after a decision. A completed request can show the approved packet version, reviewer, decision time, executed tool call, result, and any recovery status. This supports incident analysis because teams can distinguish among an unsuitable proposal, missing packet context, an authorization-policy gap, a review decision, and a downstream execution failure.
Use the same packet format in the active queue, audit view, and incident review. That consistency gives teams a shared artifact instead of requiring them to reconstruct a narrative after an error.
Operational metrics can help improve the workflow over time. Review queue age, rejection reasons, edit frequency, expired packets, and execution failures. These signals can reveal where an agent lacks reliable evidence, where policies are too broad, and where packet design is not giving reviewers the information they need.
FAQ
When should an AI agent require human approval?
Require approval before actions with external effects, sensitive-data exposure, permission changes, broad record changes, financial impact, or difficult rollback. Review is also appropriate when evidence is incomplete or conflicting.
Can confidence scores replace human review?
No. Confidence can help prioritize a queue, but it does not establish authorization, business context, scope, or acceptable impact. Use deterministic policy to decide when review is required.
What should happen when a reviewer edits an agent proposal?
Create a new packet version, validate the permitted changes against policy, and execute only that approved version. Do not mutate an already approved payload in place.
How long should approval requests remain open?
Set an expiry that matches the business process and the volatility of the underlying records. When relevant information may have changed, generate a fresh packet before execution.
Sources
- OWASP Top 10 for Large Language Model Applications
- LangGraph Interrupts Documentation
- Temporal Workflow Message Passing Documentation
- n8n Human-in-the-Loop for Tools
- Microsoft Teams Universal Actions for Cards
- Google Chat Interactive Dialogs
- Microsoft ApprovalRequiredAIFunction
Editorial note: AI assisted with research and drafting. Sources were selected for verification.
Full-Stack Developer & Solutions Architect · Casablanca, Morocco
7+ years building Java/Spring Boot/Angular enterprise solutions. Former Senior Software Engineer at NTT Data and Satec. Authorized Google Workspace and Microsoft 365 Partner for Morocco.
September 4, 2026
