> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Human in the Loop Approvals Checkpoints and Guardrails > Guide to inserting human approvals, checkpoints, and technical guardrails into AI agent workflows to balance automation, safety, and auditability. As we give AI agents more autonomy, a central design question emerges: where should a human still be involved? This guide explains patterns for inserting human judgment into agent-driven workflows so you get the right balance of automation, safety, and auditability. Human-in-the-loop (HITL) means the agent handles most routine work but pauses at selected points so a person can review, approve, or correct actions. The goal is not maximum autonomy—it is the right level of autonomy for the task, especially as the potential impact or irreversibility of an action increases. A presentation slide titled "The Goal Isn't Maximum Autonomy" with a long green-to-red gradient bar illustrating a spectrum from "Manual" to "Fully Autonomous." It notes increasing agent oversight for high-impact irreversible tasks and labels manual as too little autonomy while fully autonomous means agents act without human review.

A presentation slide titled "The Goal Isn't Maximum Autonomy" with a long green-to-red gradient bar illustrating a spectrum from "Manual" to "Fully Autonomous." It notes increasing agent oversight for high-impact irreversible tasks and labels manual as too little autonomy while fully autonomous means agents act without human review.

Overview of controls Three distinct controls are commonly used to insert human judgment or system limits into agent workflows: approvals, checkpoints, and guardrails. They differ in when the human or system intervenes, and how that intervention is applied. | Control | When it applies | What it does | Typical use case | | -: | -: | - | - | | Approvals | Immediately before a specific action | Pauses execution until a human explicitly approves or rejects the prepared action | Financial transactions, destructive operations, production changes | | Checkpoints | At planned stages of a multi-step workflow | Pauses to let a human inspect intermediate results before continuing | Bulk operations, staged rollouts, sampling-based validation | | Guardrails | Enforced at the system, tool, or identity level | Automatically prevents disallowed actions regardless of model behavior | Permissions, allowlists, spending caps, restricted APIs | These three patterns and their relationships are illustrated below. A dark-themed slide titled "Multiple Forms of Oversight" showing three panels labeled Approvals, Checkpoints, and Guardrails. Each panel has an icon and a short description about pausing for human approval, planned review stages, and system-enforced constraints.

A dark-themed slide titled "Multiple Forms of Oversight" showing three panels labeled Approvals, Checkpoints, and Guardrails. Each panel has an icon and a short description about pausing for human approval, planned review stages, and system-enforced constraints.

Approvals Approvals halt execution right before a concrete, consequential action. The agent can analyze the situation and prepare a proposed change, but it does not execute that change until a human reviewer explicitly signs off. When to use approvals * High-impact, irreversible, or customer-facing actions (refunds, deletion of records, production deployments). * Any action where legal, financial, or reputational consequences require an auditable, human decision. Example * A support agent computes a \$200 refund and prepares a transaction. The refund is not executed until a support lead approves. If approved, the workflow continues and logs the decision; if rejected, the agent either stops or proposes an alternative. Design tip * Avoid approval fatigue. Requiring approval for low-risk, frequent tasks leads reviewers to approve automatically. Reserve approvals for genuinely consequential actions. Checkpoints A checkpoint pauses a workflow at a planned staging point so a human can inspect intermediate outputs before the agent proceeds. This is ideal for multi-step tasks where an early mistake could cascade. When to use checkpoints * Bulk changes or staged operations where validating a sample reduces downstream risk. * Complex multi-step workflows where intermediate validation prevents amplification of errors. Example * A helpdesk agent proposes reclassifying 400 tickets. It first processes a sample of 20 tickets and hits a checkpoint for a human review. If the sample is correct, the human approves and the agent applies the reclassification to the remaining tickets. A slide titled "Review the Work Before it Continues" showing a workflow diagram that pauses for human review: Pull tickets → Group by issue → CHECK (human review) → Apply labels → Notify owners. A Helpdesk AI example notes the agent tests a reclassification plan on a 20-ticket sample before running it on 400 tickets.

A slide titled "Review the Work Before it Continues" showing a workflow diagram that pauses for human review: Pull tickets → Group by issue → CHECK (human review) → Apply labels → Notify owners. A Helpdesk AI example notes the agent tests a reclassification plan on a 20-ticket sample before running it on 400 tickets.

Guardrails Guardrails are hard system limits enforced outside the model. They are implemented as permissions, policies, allowlists, quotas, or infrastructure constraints and remain effective even if the model is given malicious input or behaves unexpectedly. Key properties * Not just a prompt instruction—guardrails are technical controls applied to the agent's identity, tools, or infrastructure. * Enforced automatically at runtime, independent of the model’s output. Example for a helpdesk agent * Allowed: read tickets, draft replies, tag priority, suggest knowledge-base articles. * Prohibited by guardrail: access billing systems, delete records, send email outside an allowlist, exceed a spending cap. Important distinction * Saying “never delete records” in a prompt is guidance. Configuring the agent’s permissions so it cannot call any record-deletion API is a guardrail. A presentation slide titled "Guardrails Enforce Hard Limits" that contrasts allowed helpdesk AI actions (read tickets, draft replies, tag priority, suggest articles) on the left with prohibited actions (access billing/payments, delete records, email outside the allowlist, exceed the spending cap) on the right.

A presentation slide titled "Guardrails Enforce Hard Limits" that contrasts allowed helpdesk AI actions (read tickets, draft replies, tag priority, suggest articles) on the left with prohibited actions (access billing/payments, delete records, email outside the allowlist, exceed the spending cap) on the right.

A slide titled "Match Oversights to Risk" showing a 2x2 matrix that maps high/low impact against hard/easy to undo. The four boxes recommend controls: "Require Approval" (refunds, delete data, production changes), "Checkpoint or Staged Execution" (bulk/large-scale changes), "Review Before Execution" (external messages, permanent state changes), and "Let It Run" (summarize, draft, classify, triage).

Production practices When deploying agentic workflows in production, follow these recommended practices: * Focus human review on high-impact actions. Preserve automation for low-risk tasks so agents remain valuable. * Start with conservative oversight for new workflows. Use production telemetry to measure reliability, then reduce supervision where safe. * Log every decision: what the agent attempted, what was approved/rejected, timestamps, and final outcomes. These logs are critical for debugging, governance, and audits. * Enforce critical limits outside the model: permissions, allowlists, spending caps, and infrastructure policy so the system doesn’t rely only on human reviewers or prompt constraints. A dark-themed slide titled "Getting it Right in Production" that outlines four practices for production workflows. Each practice has a red icon and brief text: "Review high-impact actions," "Start with more oversight," "Log Every Decision," and "Enforce limits outside of the model."

A dark-themed slide titled "Getting it Right in Production" that outlines four practices for production workflows. Each practice has a red icon and brief text: "Review high-impact actions," "Start with more oversight," "Log Every Decision," and "Enforce limits outside of the model."

Summary * Approvals: use when an explicit human decision is required before executing a consequential action. * Checkpoints: use when staged review of intermediate results reduces the risk of cascading errors. * Guardrails: implement as technical, system-level limits that the agent cannot bypass. The objective is to automate what can be safely automated, while preserving human judgment and enforcing system-level constraints where consequences require it. Design for risk: apply approvals and checkpoints for actions with higher impact or low reversibility, and always implement system-level guardrails and comprehensive logging to maintain safe, auditable workflows. Links and references * [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management) * [Responsible AI principles and governance patterns](https://www.oecd.org/going-digital/ai/) * Guidance on designing human-in-the-loop systems: academic and industry literature on HITL best practices and auditability This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.