21 — LangGraph Human-in-the-Loop¶

Understand how Human-in-the-Loop (HITL) patterns are implemented in LangGraph to introduce human oversight, approval, intervention, and decision-making into AI Agent workflows.

📖 Overview¶

AI Agents can reason, plan, retrieve information, call tools, and execute multi-step tasks autonomously.

However, enterprise systems cannot allow unrestricted autonomy for every operation.

Some actions require:

Human Approval
Human Review
Human Intervention
Human Correction
Human Decision

Human-in-the-Loop introduces a controlled boundary between autonomous agent execution and human decision-making.

A typical enterprise pattern is:

Agent
 ↓
Analyze
 ↓
Prepare Action
 ↓
Risk Assessment
 ↓
Human Review
 ↓
Approve / Reject / Modify
 ↓
Resume Agent
 ↓
Execute

LangGraph is particularly well suited to these workflows because graph execution can be paused, state can be persisted, and execution can later resume from the appropriate point.

The objective is not to remove autonomy.

The objective is:

Controlled Autonomy
+
Human Oversight
+
Durable Execution
=
Enterprise Agent Workflow

🎯 Learning Objectives¶

After completing this chapter, you will be able to:

Understand Human-in-the-Loop AI Agent architecture
Understand when human intervention is necessary
Design approval workflows
Pause and resume graph execution
Use checkpoints for human approval workflows
Design interrupt-driven agent workflows
Capture human decisions
Handle approve, reject, and modify outcomes
Implement risk-based human escalation
Design human review queues
Secure human approval workflows
Maintain auditability
Handle approval timeouts
Handle rejected actions
Design resumable human workflows
Test HITL agent systems
Apply production best practices

1. What Is Human-in-the-Loop?¶

Human-in-the-Loop means a human participates in the AI system's execution at a defined decision point.

Instead of:

Agent
 ↓
Action

we introduce:

Agent
 ↓
Human Review
 ↓
Action

The human may:

Approve
Reject
Modify
Request More Information
Escalate

2. Why Enterprise Agents Need HITL¶

Not every AI decision should be fully autonomous.

Examples:

Low Risk
 ├── Search Knowledge
 ├── Summarize Document
 └── Create Draft

High Risk
 ├── Refund Money
 ├── Delete Data
 ├── Change Account
 ├── Approve Loan
 └── Execute Financial Transaction

The higher the potential impact, the stronger the human oversight requirement may be.

3. Human-in-the-Loop Architecture¶

flowchart TD

    A[User Request] --> B[Agent]

    B --> C[Reason]

    C --> D[Prepare Action]

    D --> E[Risk Assessment]

    E --> F{Human Review Required?}

    F -->|No| G[Execute]

    F -->|Yes| H[Human Review]

    H --> I{Decision}

    I -->|Approve| G

    I -->|Reject| J[Reject]

    I -->|Modify| K[Update Action]

    K --> H

    G --> L[Validate Result]

    J --> L

    L --> M[END]

4. HITL Is a Control Boundary¶

The human approval point should be treated as a control boundary.

Agent Intelligence
        ↓
       HITL
        ↓
Enterprise Action

The LLM should not be able to bypass:

Authorization
Risk Policy
Human Approval

when those controls are required.

5. Human vs AI Responsibility¶

A good architecture explicitly defines responsibility.

AI¶

Analyze
Retrieve
Reason
Recommend
Prepare
Summarize

Human¶

Approve
Reject
Override
Confirm
Make High-Impact Decision

Deterministic System¶

Authorization
Validation
Policy
Audit
Execution

This creates:

AI
+
Human
+
Deterministic Controls

6. Human-in-the-Loop Patterns¶

Common patterns include:

Approval
Review
Correction
Escalation
Confirmation
Intervention
Exception Handling

7. Approval Pattern¶

The simplest pattern:

Agent
 ↓
Prepare
 ↓
Approval
 ↓
Execute

Example:

Customer Refund Request
 ↓
Agent analyzes request
 ↓
Agent prepares refund
 ↓
Human approves
 ↓
Refund API

8. Approval Architecture¶

flowchart TD

    A[Agent] --> B[Prepare Action]

    B --> C[Checkpoint]

    C --> D[Human Approval]

    D --> E{Approved?}

    E -->|Yes| F[Execute]

    E -->|No| G[Reject]

    F --> H[END]

    G --> H

9. Rejection Pattern¶

A human may reject the proposed action.

Agent
 ↓
Proposal
 ↓
Human
 ↓
Reject
 ↓
Agent / Fallback

The system should explicitly define what happens after rejection.

Possible outcomes:

Terminate
Retry With Modified Plan
Ask User
Escalate

10. Modification Pattern¶

A human may modify the proposed action.

Example:

Agent proposes:

Refund = ₹10,000

Human changes:

Refund = ₹7,500

Then:

Human Modification
 ↓
Validation
 ↓
Authorization
 ↓
Execute

Never assume human input is automatically valid.

11. Human Decision Lifecycle¶

Agent Proposal
 ↓
Review Request
 ↓
Human Decision
 ↓
Validate Decision
 ↓
Update State
 ↓
Resume Graph

12. Human Review States¶

A useful state model:

PENDING_REVIEW
       ↓
   ┌───┼────┐
   ↓   ↓    ↓
APPROVED REJECTED MODIFIED
   │     │      │
   └─────┼──────┘
         ↓
      Continue

13. State Model¶

Example:

from typing import TypedDict


class AgentState(TypedDict):
    request: str
    proposed_action: dict
    risk_level: str
    approval_status: str
    reviewer_id: str
    reviewer_comment: str
    final_action: dict

The actual state schema should contain only the fields required by the application.

14. Approval State¶

Example:

approval_status:

pending
approved
rejected
modified
expired

Keep state values controlled and explicit.

15. Human Review Queue¶

Enterprise systems often need a review queue.

Agent
 ↓
Approval Request
 ↓
Review Queue
 ↓
Human Reviewer
 ↓
Decision
 ↓
Agent

16. Review Queue Architecture¶

flowchart LR

    A[Agent] --> B[Approval Request]

    B --> C[(Review Queue)]

    C --> D[Reviewer]

    D --> E[Decision]

    E --> F[Agent Resume]

The review queue may be implemented using:

Database
Message Queue
Workflow Platform
Enterprise Task System
Custom Review Application

The appropriate technology depends on the organization's architecture.

17. Reviewer Assignment¶

A production system may route reviews based on:

Department
Role
Risk
Region
Customer
Transaction Value
Skill
Availability

Example:

Refund > Threshold
 ↓
Finance Reviewer

18. Risk-Based Human Review¶

Not every action needs human approval.

Use a risk policy:

Action
 ↓
Risk Classification
 ↓
Policy
 ↓
Human Required?

Example:

Read Customer
 → Low

Update Address
 → Medium

Refund Money
 → High

19. Risk Router¶

flowchart TD

    A[Agent Action] --> B[Risk Engine]

    B --> C{Risk}

    C -->|Low| D[Automatic]

    C -->|Medium| E[Additional Validation]

    C -->|High| F[Human Approval]

    D --> G[Execute]

    E --> H[Policy Check]

    H --> G

    F --> I[Review]

    I --> G

20. Approval Thresholds¶

Organizations may define thresholds.

Example:

Refund < ₹1,000
 → Automatic

Refund ₹1,000–₹10,000
 → Manager Approval

Refund > ₹10,000
 → Finance Approval

These values are illustrative.

The actual thresholds should come from business policy.

21. Human-in-the-Loop with LangGraph¶

LangGraph can model human intervention as part of graph execution.

Conceptually:

Node
 ↓
Interrupt
 ↓
Persist State
 ↓
Human
 ↓
Resume
 ↓
Next Node

The exact LangGraph APIs for interrupts, persistence, and resume behavior should be verified against the version used in the project.

22. Interrupt Concept¶

An interrupt pauses graph execution at a defined point.

Conceptually:

def approval_node(state):
    decision = interrupt({
        "action": state["proposed_action"],
        "reason": "Human approval required"
    })

    return {
        "approval_status": decision
    }

The important architecture is:

Interrupt
 ↓
Persist
 ↓
Wait
 ↓
Resume

23. Why Persistence Is Important¶

An interrupt without durable state is insufficient for production.

Consider:

Agent
 ↓
Approval
 ↓
Process Restart

Without persistence:

Execution Lost

With checkpointing:

Agent
 ↓
Checkpoint
 ↓
Approval
 ↓
Process Restart
 ↓
Restore
 ↓
Resume

24. HITL + Checkpointing¶

flowchart TD

    A[Agent] --> B[Prepare Action]

    B --> C[Checkpoint]

    C --> D[Interrupt]

    D --> E[Human]

    E --> F[Decision]

    F --> G[Persist Decision]

    G --> H[Resume Graph]

    H --> I[Execute]

    I --> J[END]

25. Resume Execution¶

After the human decision:

Human Decision
 ↓
Resume Graph
 ↓
State Updated
 ↓
Next Node

The graph should continue from the correct execution point rather than restarting the entire workflow unnecessarily.

26. Resume Data¶

A human decision may contain:

decision
comment
modified_action
reviewer_id
timestamp

Example:

{
  "decision": "approved",
  "reviewer_id": "reviewer-101",
  "comment": "Approved after policy verification"
}

Sensitive information should be handled according to enterprise privacy and audit requirements.

27. Human Decision Validation¶

Never trust the UI response blindly.

Validate:

Decision
Reviewer
Authorization
Action
State

Example:

Human says:
"Approve"

System checks:

Reviewer authorized?
 ↓
Request still valid?
 ↓
Action unchanged?
 ↓
Policy still satisfied?
 ↓
Execute

28. Approval Expiration¶

Human approvals can become stale.

Example:

Agent prepares action
 ↓
Human approves
 ↓
Two days pass
 ↓
Underlying data changes

The original approval may no longer be valid.

Therefore define:

Approval TTL

or:

Re-validation

before execution.

29. Approval Expiration Flow¶

flowchart TD

    A[Approval Request] --> B[Human Approval]

    B --> C{Still Valid?}

    C -->|Yes| D[Execute]

    C -->|No| E[Re-validation]

    E --> F[New Approval]

    F --> D

30. Stale State¶

Human workflows can create stale state.

Example:

Agent reads account balance
 ↓
Human approval
 ↓
Balance changes
 ↓
Execute

The system should re-check critical business conditions before the side effect.

31. Approval + Revalidation¶

Recommended:

Human Approval
 ↓
Revalidate Current State
 ↓
Authorization
 ↓
Execute

This prevents executing against outdated assumptions.

32. Human Overrides¶

A reviewer may override an agent recommendation.

Example:

Agent:
Refund = ₹10,000

Human:
Refund = ₹5,000

The modified action must pass through:

Schema Validation
 ↓
Business Rules
 ↓
Authorization
 ↓
Execution

33. Human Input Is Also Untrusted Input¶

Human approval interfaces should still validate:

Input Format
Permissions
Scope
Action
Identifiers

A human should not be able to approve an action outside their authorization scope.

34. Authorization¶

Approval does not automatically mean authorization.

Example:

Agent proposes:
Delete customer data

Reviewer clicks:
Approve

The system must still check:

Is reviewer authorized?
Is operation allowed?
Is target allowed?
Is policy satisfied?

35. Separation of Duties¶

High-risk operations may require multiple people.

Example:

Agent
 ↓
Reviewer A
 ↓
Reviewer B
 ↓
Execute

This can reduce:

Single-Person Risk

for highly sensitive actions.

36. Multi-Level Approval¶

flowchart TD

    A[Agent Proposal] --> B[Manager Approval]

    B --> C{Approved?}

    C -->|No| D[Reject]

    C -->|Yes| E[Compliance Approval]

    E --> F{Approved?}

    F -->|No| D

    F -->|Yes| G[Execute]

37. Human Escalation¶

An agent can escalate when it cannot safely continue.

Examples:

Low Confidence
Unknown Intent
Policy Conflict
Tool Failure
High Risk
Repeated Errors

Flow:

Agent
 ↓
Problem
 ↓
Escalation
 ↓
Human

38. Escalation Router¶

flowchart TD

    A[Agent] --> B{Can Continue?}

    B -->|Yes| C[Continue]

    B -->|No| D[Escalate]

    D --> E[Human]

    E --> F[Decision]

    F --> C

39. Human Correction¶

Humans may provide corrective information.

Example:

Agent:
Customer requested refund.

Human:
No. Customer requested a replacement.

Then:

Human Correction
 ↓
Update State
 ↓
Re-plan
 ↓
Continue

40. Correction Flow¶

flowchart TD

    A[Agent Analysis] --> B[Human Review]

    B --> C{Correct?}

    C -->|Yes| D[Continue]

    C -->|No| E[Human Feedback]

    E --> F[Update State]

    F --> G[Re-plan]

    G --> D

41. Human Feedback as State¶

Example:

class AgentState(TypedDict):
    query: str
    plan: list
    human_feedback: str
    approval_status: str

The feedback can become part of the next reasoning step.

42. Human Feedback Should Be Scoped¶

Avoid blindly injecting every human message into every future step.

Instead:

Human Feedback
 ↓
Relevant State Field
 ↓
Specific Node

This keeps the workflow predictable.

43. HITL for RAG¶

Human review can also be used in RAG systems.

Example:

Retrieve
 ↓
Generate Answer
 ↓
Human Review
 ↓
Publish

Useful for:

Legal Documents
Financial Reports
Regulated Content
Customer Communications

44. HITL for Tool Calling¶

Example:

Agent
 ↓
Tool Selection
 ↓
Risk Check
 ↓
Human Approval
 ↓
Tool

This is one of the most important enterprise HITL patterns.

45. HITL for Agentic Workflows¶

For longer workflows:

Plan
 ↓
Research
 ↓
Draft
 ↓
Human Review
 ↓
Execute
 ↓
Validate

The human becomes a controlled checkpoint within the larger workflow.

46. Human-in-the-Loop vs Human-on-the-Loop¶

Human-in-the-Loop¶

Human actively participates in execution.

Agent
 ↓
Human
 ↓
Continue

Human-on-the-Loop¶

Human supervises the system and intervenes when necessary.

Agent
 ↓
Execute
 ↓
Monitor
 ↓
Human Intervention if Required

The distinction matters when designing operational controls.

47. HITL vs Fully Autonomous¶

Fully Autonomous¶

Agent
 ↓
Decision
 ↓
Action

HITL¶

Agent
 ↓
Decision
 ↓
Human
 ↓
Action

Human-on-the-Loop¶

Agent
 ↓
Decision
 ↓
Action
 ↓
Monitoring
 ↓
Human Intervention

48. Choosing the Right Pattern¶

Use stronger human control when:

Risk ↑
Impact ↑
Irreversibility ↑
Uncertainty ↑
Regulatory Requirement ↑

Use more autonomy when:

Risk ↓
Impact ↓
Reversibility ↑
Confidence ↑

49. HITL Decision Matrix¶

Factor	Low	High
Business Risk	Automatic	Human
Financial Impact	Automatic	Human
Irreversibility	Automatic	Human
Model Confidence	Automatic	Review
Regulatory Sensitivity	Automatic	Human
Data Sensitivity	Lower Controls	Strong Controls

This is a conceptual framework; actual policies should be domain-specific.

50. Approval Request Design¶

An approval request should provide enough context for a human to make an informed decision.

Example:

Action:
Refund Customer

Customer:
Customer-1021

Amount:
₹7,500

Reason:
Duplicate payment

Evidence:
Transaction IDs
Policy Reference

Risk:
Medium

Agent Recommendation:
Approve

Avoid forcing reviewers to inspect raw model output to understand the proposed action.

51. Explainability for Reviewers¶

The reviewer should see:

What?
Why?
Evidence?
Risk?
Impact?

Example:

Action
 ↓
Reason
 ↓
Evidence
 ↓
Policy
 ↓
Risk

The goal is useful decision context, not exposing hidden chain-of-thought.

52. Review UI¶

A production review interface might contain:

┌───────────────────────────────┐
│ Approval Request              │
├───────────────────────────────┤
│ Customer: C-101               │
│ Action: Refund                │
│ Amount: ₹7,500                │
│ Risk: Medium                  │
│ Evidence: 3 transactions      │
│ Policy: Refund Policy #12     │
├───────────────────────────────┤
│ [Approve] [Reject] [Modify]   │
└───────────────────────────────┘

53. Approval Audit¶

Record:

Request ID
Thread ID
Execution ID
Action
Reviewer
Decision
Timestamp
Comments
Previous State
Approved State

For sensitive operations, audit records should be tamper-resistant according to enterprise requirements.

54. Approval Trace¶

Example:

Execution: exec-9001

Agent Proposal
 ↓
Risk Check
 ↓
Human Approval
Reviewer: user-200
Decision: APPROVED
 ↓
Revalidation
 ↓
Execution

This creates an auditable lifecycle.

55. Approval Metrics¶

Track:

Approval Rate
Rejection Rate
Modification Rate
Average Review Time
Approval Timeout Rate
Escalation Rate
Human Override Rate
Execution Success Rate

These metrics can reveal:

Poor Agent Quality
Poor Routing
Bad Risk Thresholds
Reviewer Bottlenecks

56. Human Review Bottleneck¶

If:

Agents
 ↓
1000 Approval Requests
 ↓
5 Reviewers

the human queue becomes a bottleneck.

Therefore measure:

Queue Depth
Wait Time
Reviewer Utilization
SLA Breaches

57. Approval SLA¶

Define business SLAs.

Example:

Low Priority
 → 24 hours

High Priority
 → 30 minutes

The actual SLA depends on the business process.

If the SLA expires:

Escalate
Reject
Re-route

58. Approval Timeout¶

flowchart TD

    A[Approval Request] --> B[Wait]

    B --> C{Decision Received?}

    C -->|Yes| D[Process Decision]

    C -->|No| E{Timeout?}

    E -->|No| B

    E -->|Yes| F[Escalate]

    F --> G[END]

59. Reviewer Availability¶

If no reviewer is available:

Approval Queue
 ↓
No Reviewer
 ↓
Escalation

Do not leave critical workflows indefinitely paused without monitoring.

60. Approval Delegation¶

Enterprise systems may support:

Primary Reviewer
 ↓
Backup Reviewer
 ↓
Escalation Team

This improves workflow resilience.

61. Human-in-the-Loop Security¶

Protect:

Approval Requests
Reviewer Identity
Customer Data
Financial Data
Agent State

Controls include:

Authentication
Authorization
RBAC
ABAC
Encryption
Audit
Tenant Isolation

62. Reviewer Authorization¶

A reviewer should only approve actions within their scope.

Example:

Finance Reviewer
 ↓
Financial Actions

HR Reviewer
 ↓
Employee Actions

The graph should enforce this.

63. Approval Token¶

For sensitive workflows, a decision can be represented by a controlled approval record.

Approval ID
+
Reviewer
+
Action Hash
+
Decision
+
Timestamp

Before execution:

Approval Record
 ↓
Action Still Matches?
 ↓
Authorized?
 ↓
Execute

This can reduce the risk of approving one action and executing another.

64. Approval Integrity¶

Consider:

Agent Proposal A
 ↓
Human approves A
 ↓
State changes
 ↓
Agent changes to Proposal B
 ↓
Execute B

This is dangerous.

Use:

Proposal Identity
+
Version
+
Approval Binding

to ensure the approval applies to the exact action being executed.

65. Approval Binding¶

flowchart TD

    A[Proposal A] --> B[Proposal Hash]

    B --> C[Human Approval]

    C --> D[Execution]

    D --> E{Hash Matches?}

    E -->|Yes| F[Execute]

    E -->|No| G[Re-approval]

66. Human Review + State Versioning¶

If state changes while waiting:

State v10
 ↓
Human Approval
 ↓
State v11

The system should determine whether approval remains valid.

For critical operations:

Approval
 ↓
State Validation
 ↓
Execute

67. Human-in-the-Loop and Concurrency¶

Multiple reviewers should not accidentally approve competing versions.

Use:

Version
+
Lock
+
Optimistic Concurrency

where appropriate.

68. HITL Failure Modes¶

Possible failures:

Reviewer Timeout
Reviewer Unauthorized
Approval Service Down
State Lost
Duplicate Approval
Stale Approval
Wrong Reviewer
Duplicate Execution

Every failure should have a defined response.

69. HITL Failure Handling¶

flowchart TD

    A[Approval Request] --> B{Review}

    B -->|Approved| C[Revalidate]

    B -->|Rejected| D[Stop]

    B -->|Modified| E[Validate Modification]

    B -->|Timeout| F[Escalate]

    B -->|Invalid Reviewer| G[Reassign]

    C --> H[Execute]

    E --> H

70. HITL and Idempotency¶

Approval does not eliminate duplicate execution risks.

Example:

Human approves
 ↓
Execute
 ↓
Network timeout
 ↓
Agent retries

The operation still requires:

Idempotency Key

71. HITL and Checkpointing¶

The key relationship is:

HITL
+
Checkpoint
=
Pause and Resume

Without durable state, long-running human workflows become fragile.

72. HITL and Observability¶

Trace:

Agent
 ↓
Approval Request
 ↓
Queue
 ↓
Reviewer
 ↓
Decision
 ↓
Resume
 ↓
Execution

This provides end-to-end visibility.

73. HITL Evaluation¶

Evaluate:

Decision Accuracy
Approval Accuracy
Escalation Accuracy
Reviewer Time
False Escalation
Missed Escalation

The goal is not simply:

More Human Reviews

The goal is:

Right Human Review
at the Right Decision Point

74. HITL Cost Optimization¶

Human review has operational cost.

Too many reviews:

High Human Cost
Slow Workflow
Reviewer Fatigue

Too few:

Higher Autonomous Risk

Optimize the escalation threshold using evaluation data.

75. Human Fatigue¶

If reviewers see:

1000 low-risk approvals

they may approve mechanically.

Therefore:

Risk-Based Routing
+
Useful Review Context
+
Good Thresholds

are important.

76. HITL Quality Feedback¶

Human decisions can become evaluation signals.

Example:

Agent Recommendation
 ↓
Human Decision
 ↓
Approved / Modified / Rejected

Aggregate these outcomes to identify:

Routing Errors
Tool Errors
Policy Errors
Agent Quality Problems

Do not automatically treat every human decision as training data without appropriate governance.

77. Human Corrections as Evaluation Data¶

Example:

Agent:
Refund ₹10,000

Human:
Change to ₹7,500

This indicates:

Agent Recommendation
≠
Human Decision

Repeated patterns may reveal opportunities for:

Prompt Improvement
Policy Improvement
Routing Improvement
Tool Improvement
Model Evaluation

78. HITL Production Architecture¶

flowchart TB

    U[User] --> API[API Gateway]

    API --> AUTH[Authentication]

    AUTH --> AGENT[Agent Runtime]

    AGENT --> GRAPH[LangGraph]

    GRAPH --> STATE[(Checkpoint Store)]

    GRAPH --> RISK[Risk Engine]

    RISK --> ROUTE{Approval Required?}

    ROUTE -->|No| TOOLS[Tool Gateway]

    ROUTE -->|Yes| QUEUE[(Approval Queue)]

    QUEUE --> REVIEW[Reviewer UI]

    REVIEW --> DECISION[Approval Decision]

    DECISION --> VALIDATE[Decision Validation]

    VALIDATE --> GRAPH

    TOOLS --> SERVICES[Enterprise Services]

    GRAPH --> OBS[Observability]

    GRAPH --> AUDIT[Audit]

79. Enterprise HITL Architecture¶

A robust architecture separates:

Agent
 ↓
Decision
 ↓
Risk Policy
 ↓
Human Review
 ↓
Authorization
 ↓
Execution

The LLM should never become the ultimate authority for high-impact actions.

80. HITL Design Principles¶

Principle 1 — Human at the Right Boundary¶

Do not insert humans everywhere.

Use them where:

Risk
+
Uncertainty
+
Impact

justify intervention.

Principle 2 — Persist Before Waiting¶

Prepare
 ↓
Checkpoint
 ↓
Wait

Principle 3 — Revalidate Before Side Effect¶

Approval
 ↓
Revalidate
 ↓
Execute

Principle 4 — Bind Approval to Action¶

Approval
=
Specific Action

Principle 5 — Keep Authorization Deterministic¶

Human Approval
≠
Authorization

81. Common Anti-Patterns¶

Anti-Pattern 1 — Human Approval Everywhere¶

Every Agent Step
 ↓
Human

Problems:

Slow
Expensive
Poor User Experience
Reviewer Fatigue

82. Anti-Pattern 2 — No Persistence¶

Agent
 ↓
Approval
 ↓
Process Restart

Problem:

Execution Lost

Use durable checkpointing.

83. Anti-Pattern 3 — Trusting Approval Forever¶

Approval
 ↓
Execute Days Later

Problem:

State May Have Changed

Use:

TTL
+
Revalidation

84. Anti-Pattern 4 — Approval Without Authorization¶

Reviewer
 ↓
Approve
 ↓
Execute

without checking:

Reviewer Permissions

is unsafe.

85. Anti-Pattern 5 — Approval Not Bound to Action¶

Approve A
 ↓
Execute B

Avoid this by using:

Action ID
Version
Hash

where appropriate.

86. Anti-Pattern 6 — Human Input as Raw Prompt¶

Avoid:

Human Text
 ↓
LLM
 ↓
Everything

Instead:

Human Decision
 ↓
Validated State
 ↓
Controlled Graph Transition

87. Anti-Pattern 7 — No Timeout¶

Waiting for Human
 ↓
Forever

Use:

SLA
Timeout
Escalation

88. Anti-Pattern 8 — No Audit¶

If a financial action happens, you should be able to answer:

Who approved?
What was approved?
When?
Why?
Which agent execution?
Which graph version?
Which policy?

89. Production Checklist¶

Human Review¶

[ ] Clear approval boundary
[ ] Risk-based escalation
[ ] Reviewer authorization
[ ] Review context
[ ] Approve / reject / modify
[ ] Timeout
[ ] Escalation

State¶

[ ] Durable checkpoint
[ ] Approval state
[ ] Thread identity
[ ] State version
[ ] Resume support

Security¶

[ ] Authentication
[ ] Authorization
[ ] RBAC / ABAC
[ ] Tenant isolation
[ ] Action binding
[ ] Audit

Reliability¶

[ ] Revalidation
[ ] Idempotency
[ ] Retry
[ ] Duplicate prevention
[ ] Failure handling

Operations¶

[ ] Approval metrics
[ ] Queue monitoring
[ ] Reviewer SLA
[ ] End-to-end tracing
[ ] Audit logs

90. Key Takeaways¶

Human-in-the-Loop introduces human oversight into AI Agent execution.
Humans should participate at meaningful decision boundaries.
High-risk and irreversible actions are strong candidates for HITL.
LangGraph can model pause-and-resume workflows using graph execution and persistence mechanisms.
Checkpointing is essential for durable human approval workflows.
Approval is not the same as authorization.
Human decisions must be validated before execution.
Critical approvals should be bound to the exact action being approved.
State can become stale while waiting for human input.
Revalidation should occur before important side effects.
Human modifications must pass through deterministic validation and authorization.
Approval workflows need timeout and escalation strategies.
Reviewer assignment should respect organizational permissions.
Multi-level approval can support separation of duties.
Idempotency remains necessary even when humans approve actions.
Human review should be risk-based rather than universal.
Human decisions can provide valuable evaluation signals.
HITL systems require strong observability and auditability.
The objective is not maximum human involvement.
The objective is the right level of human oversight for the risk of the action.

📝 Quick Revision Notes¶

HITL¶

Agent
 ↓
Decision
 ↓
Human
 ↓
Continue

Approval¶

Prepare
 ↓
Checkpoint
 ↓
Approve
 ↓
Revalidate
 ↓
Execute

Rejection¶

Proposal
 ↓
Reject
 ↓
Stop / Re-plan / Escalate

Modification¶

Proposal
 ↓
Human Modification
 ↓
Validate
 ↓
Authorize
 ↓
Execute

Durable HITL¶

Agent
+
Checkpoint
+
Human Decision
+
Resume
=
Durable HITL Workflow

Secure Approval¶

Human Decision
 ↓
Reviewer Authorization
 ↓
Action Validation
 ↓
State Revalidation
 ↓
Policy
 ↓
Execute

❓ Interview Questions¶

Beginner¶

What is Human-in-the-Loop?
Why do enterprise AI Agents need HITL?
What is an approval workflow?
What is the difference between human-in-the-loop and human-on-the-loop?
What is an interrupt in an agent workflow?
Why is checkpointing important for HITL?
What can a human do during an agent workflow?
What is risk-based escalation?
Why should approvals expire?
What is human review?

Intermediate¶

How would you implement an approval workflow in LangGraph?
How would you pause an agent until human approval?
How would you resume execution after approval?
How would you store human decisions?
How would you handle rejected actions?
How would you handle human modifications?
How would you prevent duplicate execution after approval?
How would you validate reviewer authorization?
How would you handle stale approvals?
How would you implement approval timeouts?
How would you design a review queue?
How would you implement risk-based routing?
How would you audit human decisions?
How would you evaluate HITL effectiveness?

Advanced¶

Design a production-grade LangGraph HITL architecture.
How would you implement durable approval workflows?
How would you guarantee that an approved action is the same action eventually executed?
How would you handle state changes while waiting for approval?
How would you design multi-level approval?
How would you implement separation of duties?
How would you prevent duplicate financial transactions after resume?
How would you design reviewer authorization across multiple tenants?
How would you handle approval service failure?
How would you design approval SLA and escalation?
How would you optimize human review cost?
How would you prevent reviewer fatigue?
How would you use human decisions as evaluation signals?
How would you combine HITL with deterministic policy engines?
How would you design HITL for long-running agents?
How would you implement HITL for high-risk tool calls?
How would you design HITL across multiple agent subgraphs?
How would you recover an interrupted HITL workflow after a deployment?
How would you design auditability for regulated AI workflows?
How would you distinguish human approval from authorization?
When should an enterprise agent remain fully autonomous?

🛠️ Practical Exercise¶

Build a customer refund agent.

Requirements:

1. Receive refund request
2. Retrieve transaction
3. Analyze refund eligibility
4. Calculate proposed refund
5. Classify risk
6. Request human approval for high-risk refunds
7. Resume after approval
8. Revalidate transaction
9. Execute refund
10. Record audit

Architecture:

flowchart TD

    A[START] --> B[Validate Request]

    B --> C[Retrieve Transaction]

    C --> D[Analyze Eligibility]

    D --> E[Prepare Refund]

    E --> F[Risk Assessment]

    F --> G{Approval Required?}

    G -->|No| H[Revalidate]

    G -->|Yes| I[Checkpoint]

    I --> J[Human Review]

    J --> K{Decision}

    K -->|Reject| L[Reject]

    K -->|Modify| M[Validate Modification]

    M --> I

    K -->|Approve| H

    H --> N[Authorization]

    N --> O[Execute Refund]

    O --> P[Audit]

    P --> Q[END]

    L --> P

🧪 HITL Evaluation Exercise¶

Create at least:

100 Refund Requests

Classify:

Low Risk
Medium Risk
High Risk

Measure:

Automatic Approval Rate
Human Escalation Rate
Human Rejection Rate
Human Modification Rate
Approval Latency
False Escalation Rate
Missed Escalation Rate
Execution Success Rate
Duplicate Execution Rate

🚀 Failure Simulation¶

Simulate:

1. Human approval timeout
2. Reviewer unauthorized
3. Approval service unavailable
4. State store unavailable
5. Transaction changes after approval
6. Process crash after approval
7. Process crash after refund execution
8. Duplicate resume request

Verify that the system safely handles each case.

🏢 Production Architecture Challenge¶

Design a HITL platform supporting:

100,000 Agent Executions
10,000 Pending Reviews
Multiple Tenants
Multiple Reviewer Roles
Long-Running Workflows
High-Risk Financial Actions

Required components:

Agent Runtime
 ↓
LangGraph
 ↓
Checkpoint Store
 ↓
Risk Engine
 ↓
Approval Queue
 ↓
Reviewer Service
 ↓
Authorization
 ↓
Enterprise Tool Gateway
 ↓
Audit

The system must support:

Pause
Resume
Reject
Modify
Reassign
Escalate
Expire
Revalidate
Retry
Recover

🧠 Final Architecture Challenge¶

Design a Banking Operations Agent that can:

1. Analyze customer requests
2. Retrieve customer data
3. Retrieve bank policies
4. Recommend an operation
5. Classify risk
6. Request human approval for high-risk actions
7. Allow authorized reviewers to modify the action
8. Revalidate the action before execution
9. Execute through a Tool Gateway
10. Recover after infrastructure failures
11. Maintain a complete audit trail

Your architecture should include:

flowchart TB

    U[User] --> API[API Gateway]

    API --> AUTH[Authentication]

    AUTH --> AGENT[LangGraph Agent]

    AGENT --> STATE[(Checkpoint Store)]

    AGENT --> RAG[LlamaIndex RAG]

    AGENT --> RISK[Risk Engine]

    RISK --> DECISION{Human Required?}

    DECISION -->|No| POLICY[Authorization + Policy]

    DECISION -->|Yes| QUEUE[Approval Queue]

    QUEUE --> REVIEW[Reviewer UI]

    REVIEW --> APPROVAL[Approval Decision]

    APPROVAL --> VALIDATE[Decision Validation]

    VALIDATE --> REVALIDATE[State Revalidation]

    REVALIDATE --> POLICY

    POLICY --> TOOLS[Tool Gateway]

    TOOLS --> BANK[Banking Services]

    BANK --> RESULT[Execution Result]

    RESULT --> AGENT

    AGENT --> OBS[Observability]

    AGENT --> AUDIT[Audit]

Answer:

Where does the graph pause?

What state is persisted?

Who can approve?

How is approval authorized?

How is approval bound to the action?

What happens if the state changes?

What happens if the reviewer does not respond?

How do you prevent duplicate execution?

How do you recover after process failure?

Which decisions remain deterministic?

Which decisions can be delegated to the AI?

📚 References & Further Reading¶

Recommended areas for further study:

LangGraph Human-in-the-Loop
LangGraph Interrupts
LangGraph Persistence
LangGraph Checkpointing
Stateful Agent Workflows
Human Approval Systems
Risk-Based Automation
Human Oversight in AI
Agent Authorization
Tool Authorization
Durable Execution
Idempotent APIs
Workflow State Management
Enterprise Approval Workflows
AI Observability
AI Governance
AI Security
Multi-Tenant Agent Platforms

LangGraph's interrupt, persistence, checkpointing, and resume APIs evolve over time. Verify the exact implementation and API behavior against the official LangGraph documentation for the version used in your project.

⬅️ Previous: 20. LangGraph Nodes, Edges and Routing

📚 Part VIII Index: AI Engineering Frameworks & Tooling

➡️ Next: 22. LangGraph Tool Execution

Enterprise AI Engineering Handbook

Building Production-Grade Enterprise AI Systems — One Chapter at a Time.