How do we add human approval steps before an agent takes sensitive actions (refunds, account changes, sending emails)?

Most teams hit the same wall once agents move beyond read-only tasks: you need automation for speed, but you cannot let an LLM send refunds, change accounts, or fire off emails without a human sanity check. The answer is to put explicit approval steps into your agent workflow so sensitive actions pause, get reviewed, and only execute after someone signs off.

Quick Answer: Use tool-level approval requirements and human-in-the-loop workflows. Configure your agent so that whenever it wants to take a sensitive action—like issuing a refund, changing account data, or sending an email—it must create a pending action, route it to a reviewer, and wait for an explicit “approve” or “reject” before proceeding.

---

The Quick Overview

• What It Is: A human-approval layer that sits between your agent and sensitive tools (payments, CRMs, email, internal systems). Agents can propose actions, but humans must approve them before anything executes.
• Who It Is For: Product, CX, and engineering teams deploying agents into production who want automation on routine work, but require control and auditability for risky steps.
• Core Problem Solved: Prevents “quietly wrong” agent behavior—like over-refunding, mis-editing accounts, or emailing the wrong customer—by keeping humans in the loop where mistakes are expensive.

---

How It Works

At a high level, you mark specific tools or actions as sensitive, then build your agent so it pauses when it reaches those steps. Instead of calling the tool directly, it creates a structured action request (who, what, why, and context) that gets routed to a human inbox or workflow. The human can edit the action, approve it, or reject it with feedback. That decision flows back to the agent, which either executes the tool call or adjusts its plan based on the feedback.

Under the hood, the flow usually looks like this:

1. Detect & Flag Sensitive Intent:
   The agent decides it wants to do something sensitive—issue a refund, update a record, send an email. Instead of calling the underlying tool directly, it calls a “mediated” tool that knows this action requires approval.

2. Create a Pending Approval Request:
   The mediated tool:

   • Captures the proposed action (parameters, target user, amount, email body, etc.).
   • Bundles relevant trace data (conversation so far, agent reasoning, customer metadata).
   • Stores this as a pending approval object and routes it to a queue or inbox for reviewers.

3. Human Review, Decision & Execution:
   A human sees the queued action, in context:

   • Reviews the proposal.
   • Edits details as needed (refund amount, email copy, account fields).
   • Approves or rejects with comments. The system then either executes the action (if approved) or sends the rejection and feedback back into the agent trace so the agent can respond correctly to the user.

In LangChain / LangGraph + LangSmith terms:

• LangGraph defines the branching logic (normal path vs. “wait for approval” path).
• The “tool” for sensitive actions is actually a wrapper that emits “approval needed” events instead of running immediately.
• LangSmith gives you traces showing exactly when the agent requested approval, who approved, and what changed—so you can debug any incident end-to-end.

---

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Tool-level approval requirements	Lets you flag specific tools (refunds, account changes, email send) as requiring human approval.	Keeps agents from executing high-impact actions without review.
Centralized approval inbox / queue	Aggregates pending agent actions with full trace context for reviewers.	Gives ops and CX teams one place to review, edit, and approve.
Trace-linked audit trail	Links each approved/rejected action to the underlying trace and final tool call.	Makes compliance and incident review straightforward.

---

Ideal Use Cases

• Best for refunds and credits: Because it lets the agent draft the refund (amount, reason, customer context) while guaranteeing a human checks policy compliance and edge cases before money moves.
• Best for account changes and outbound emails: Because agents can prepare updates and emails in bulk, but actual write operations and sends get human approval, minimizing the risk of sending wrong info or corrupting records.

---

Limitations & Considerations

• More latency for sensitive flows:
  Any path that requires human approval will be slower than fully automated flows. In practice, most teams:

  • Auto-approve low-risk actions (small refunds, low-scope changes).
  • Require approvals only above thresholds (amount, scope, role).
  • Batch approvals for operational efficiency.

• Requires clear policies and reviewer training:
  Approval steps are only as strong as the guidelines behind them. You’ll need:

  • Refund, discount, and escalation policies.
  • Criteria for when to reject or modify agent proposals.
  • A feedback channel so agent behavior improves based on human corrections (e.g., via LangSmith datasets + evals or Agent Builder memory).

---

Pricing & Plans

LangChain’s human-in-the-loop approach comes from how you design your agents with LangGraph, trace them with LangSmith, and operationalize them with Fleet/Agent Builder. There isn’t a separate “approvals SKU”—you use the core platform primitives:

• LangSmith plans: Seat-based with usage-based pricing for traces and evals.
  • Lower tiers suit smaller teams instrumenting a few agents with basic tracing and evals.
  • Higher tiers (and enterprise) support high-traffic production agents, longer trace retention, and more advanced governance (SSO/SAML, SCIM, RBAC/ABAC, audit logs, US/EU data residency, hybrid/self-host).

At a high level:

• Team / Growth-style plans: Best for product and eng teams needing:

  • Robust tracing and debugging for one or a few agents.
  • A place to route approval-related traces into annotation queues.
  • Offline/online evals to keep quality from regressing as they add more approval logic.

• Enterprise plans: Best for larger organizations needing:

  • Detailed governance: RBAC/ABAC to control who can approve what, and audit logs to show who approved which agent actions.
  • Hybrid or self-hosted options so sensitive data and approval workflows stay in your VPC.
  • Support for routing approval traces into external systems (ticketing, case management) via APIs and OpenTelemetry.

For current pricing and plan details, the most reliable path is to talk to the LangChain team directly so you can scope based on your traffic, retention needs, and deployment model.

---

Frequently Asked Questions

How do we technically add a human approval step in an agent workflow?

Short Answer: Wrap sensitive tools in an “approval-required” interface, have the agent call that instead of the raw tool, store the proposed action as a pending approval, and use a reviewer UI or workflow to approve/reject and then trigger the actual tool call.

Details: The implementation usually follows this pattern:

1. Define sensitive tools as mediated tools:

   • Instead of exposing issue_refund() or update_account() directly, create wrapped tools like request_refund_approval() that:
     • Accept the same parameters.
     • Do not execute the underlying write.
     • Save a structured “action request” with metadata (user, amount, reason, policy flags).

2. Pause the agent at the approval boundary:

   • In LangGraph, route the graph to a “await_approval” node when these tools are invoked.
   • That node:
     • Records a trace event like approval_required with a link to the pending action object.
     • Returns a “we’re processing your request” message to the end user, if appropriate.
   • The run then waits; it doesn’t advance to “execute refund” until an external signal arrives.

3. Provide a human approval surface:

   • Build or integrate an inbox where reviewers can:
     • See pending actions with full context (trace, user conversation, historical interactions).
     • Edit parameters (e.g., reduce refund amount, tweak email template).
     • Approve or reject with comments.
   • Use LangSmith traces as your context source so reviewers can see exactly why the agent proposed this action.

4. Feed the decision back into the graph:

   • When a reviewer decides:
     • If approved: emit an event or API callback that resumes the graph on the “execute_tool” path, now calling the underlying implementation (e.g., your payment/refund API).
     • If rejected: resume on an alternate path where the agent:
       • Updates its internal state (e.g., “cannot issue refund beyond policy limit”).
       • Crafts a response back to the user explaining the decision.

5. Close the loop for improvement:

   • Use rejected actions as labeled data:
     • Convert “agent proposal vs. human correction” into LangSmith datasets.
     • Use Align Evals or similar evals so your LLM-as-judge understands what counts as policy-compliant behavior.
     • Gradually reduce the volume of rework by making the agent better at staying within guidelines.

This approach keeps agents framework-agnostic: the approval logic lives in your orchestration (LangGraph) and runtime, not in any particular model.

---

What kinds of actions should always require human approval?

Short Answer: Anything that writes or sends externally and carries financial, legal, or reputational risk should require approval—or at least have thresholds that trigger approval.

Details: In practice, most teams draw the line at:

• Money-moving operations:

  • Refunds, credits, discounts, loyalty points.
  • Wire transfers, invoice adjustments.
  • Threshold patterns:
    • Under $X: auto-approve.
    • Between $X and $Y: agent drafts, human approves.
    • Above $Y: human handles directly.

• Account and permissions changes:

  • Changes to billing info, shipping address, or contact details.
  • Role and permission updates in B2B products.
  • Plan upgrades/downgrades that affect billing or SLAs.

• External communications:

  • Outbound emails and messages to customers, especially:
    • Legal or compliance-related topics.
    • Offers, promotions, and contract terms.
  • Bulk or high-impact sends (e.g., to many recipients) should almost always be approval-gated.

• Data writes in critical systems:

  • Edits in CRMs, ERPs, logistics or inventory systems.
  • Any operation that’s hard or expensive to roll back.

To operationalize this:

• Start with a conservative posture: treat most writes as requiring approval.
• Use your traces to see which categories are reliably low-risk (e.g., small, repeated, well-bounded actions).
• Gradually loosen constraints with clear thresholds and automated evals watching for regressions.

---

Summary

Adding human approval steps before agents process refunds, edit accounts, or send emails is less about a single “approve button” and more about how you structure your agent workflow:

• Sensitive actions are routed through mediated tools that don’t execute immediately.
• The agent pauses and emits a trace that includes a structured action proposal.
• Humans review, edit, and approve or reject from a centralized inbox, with full trace context.
• Approval decisions feed back into the agent graph, driving actual tool calls or alternative responses.
• Those traces become training and evaluation data to make the agent better over time.

You get the speed of agents for drafting, triage, and orchestration—but you keep humans in control of the steps that really matter.

---

Next Step

Get Started