What Is Human-in-the-Loop?

Post 3 in the HITL in Agentic Systems series. Posts 1 and 2 covered what agentic is and why humans are needed in the loop. This post clarifies the definition of HITL, what an approval gate is, and the basic flow: pending → approve/reject/modify → continue or fix.

---

Opening: From the term to the approval gate

“Human-in-the-loop” (HITL) originally comes from machine learning: humans participate in the loop to label data, correct predictions, or check model output. In agentic systems, HITL has a similar idea but applies to actions: humans participate at a stop point (approval gate) to decide whether the agent may execute the next step. This post defines HITL, the origin of the term, and how an approval gate works in a simple flow.

---

1. Definition of HITL

Value: You get a clear definition: HITL = human participation in the decision or action loop at stop points. It is not “human review after everything is done” — HITL is stopping before the action (or before the tool runs) for human confirmation.

Challenges: Many people think “someone checks” means after the agent has run. In proper HITL, the stop point is inside the flow: the agent finishes preparing a step (e.g. draft email, deploy plan), the system stops, waits for approve/reject/modify, then executes or rolls back. This difference drives state and queue design (posts 4, 5).

Design: Compare three models:

• No human: Agent runs end-to-end, no stop. Fits read-only or low-impact.
• Human review after: Agent finishes, human checks the result later. Useful but not “in the loop” — the action already happened; review is only for correction or learning.
• Human in the loop (at gate): Flow stops at the gate; the agent does not run the next step until the human decides. This is HITL as used in this series.

Simple diagram:

[Agent produces output] → [Gate: pending] → [Human: Approve / Reject / Modify] → [Approved: continue] or [Rejected: rollback/fix]

Solution: HITL = approval gate(s) in the flow. At each gate: state pending; human sees the item in the queue (post 5), performs one of Approve / Reject / Modify; the system updates state and either continues the workflow or rollbacks/fixes. Post 4 details the state machine (pending_review, approved, rejected, timeout).

Implementation: In code or a workflow engine, a “gate” is usually a step where execution pauses, creates a “pending_review” record, and waits for an event from the UI/API (user clicks approve/reject). Without that event, the workflow does not run the next step.

---

2. Origin of "human-in-the-loop" in ML/AI

Value: Knowing the origin avoids confusion: in ML, HITL is often about data (labeling, active learning, correction); in agentic systems, HITL is about actions (action approval, workflow gate). Same idea — human in the loop — but different context.

Challenges: We do not go deep into ML history; only enough for the reader to see the shift from “human labels data” to “human approves action”.

Design: Short paragraph:

• ML: Humans label data, correct model predictions, or choose instances to label next (active learning). The “loop” is train → predict → human correct → train again.
• Agentic: Humans participate at a stop point before the agent executes an action (send email, deploy, write DB). The “loop” is agent proposes → human approve/reject → agent continues or stops.

Solution: Same name “human-in-the-loop”, same spirit of humans controlling quality or risk in the loop; difference is the object: data vs action. This series focuses agentic HITL — approval gates for actions.

Implementation: A short comparison table (ML HITL vs Agentic HITL) helps the reader remember: ML = data/label, Agentic = action/approval. Then back to the approval gate and the three actions (Approve, Reject, Modify).

---

3. Approval gate — stop point and three actions

Value: You will see that an approval gate is where the workflow stops and waits for the human to do one of three things: Approve (continue), Reject (cancel/rollback), Modify (change content or parameters then possibly approve). Modify matters for the feedback loop (posts 7, 8): the system records changes to improve.

Challenges: Modify can be complex: edit email body, change deploy parameters. The UI and data model must support “modified payload”. Also timeout: if no decision within X minutes, what happens? Escalate, default reject, or remind — policy-dependent (post 11).

Design: Detailed flow:

1. Agent produces output (e.g. draft email, deploy plan) → save to store, state pending_review.
2. System pushes the item to the queue (post 5); reviewer sees it in dashboard/Slack/email.
3. Human chooses Approve → state becomes approved → workflow runs the next step (send email, run deploy).
4. Or Reject → state rejected → workflow rollbacks or stops, per design.
5. Or Modify → human edits content/parameters → can then approve the revised version; system stores diff for learning (posts 7, 8).

Solution: These three actions are enough for most gates. Timeout should be defined: after X minutes with no decision → auto reject or escalate. Post 4 maps states (pending_review, approved, rejected, timeout) to the state machine; post 5 covers queue and channels (Slack, email, dashboard).

Implementation: When implementing, each “gate” needs: (1) state field (pending_review, approved, rejected, timeout); (2) event handler for user action (approve, reject, modify); (3) metadata reviewed_by, reviewed_at (posts 4, 6). Post ends with a lead-in: post 4 will draw the state machine and metadata; post 5 will cover where the reviewer “clicks” (queue, channel).

---

Previous: Why We Need Humans in the Loop (post 2). Next: States and State Machine (post 4).