Human-in-the-Loop Design for Production Agents

Friday afternoon. The agent drafts a customer reply, updates the CRM, and almost fires a refund. Someone in ops catches it because they happened to be watching the channel. That is not a control system. That is luck.

“Autonomous” is not the same as “unsupervised.” In production, agents touch money, customers, and systems of record. Human-in-the-loop (HITL) is how you keep autonomy useful without making it reckless.

What HITL actually means

HITL is not a vague promise that “a human can review.” It is a set of design choices you can point to in the code and the runbook:

• When the agent must pause
• Who can approve
• What happens on timeout or rejection
• How the decision is logged

If those four are undefined, you do not have HITL. You have hope.

Where to require approval

Require a human when the action is:

• Irreversible or expensive (refunds, purchases, bulk writes)
• Externally visible (customer email, public content)
• Permission-sensitive (cross-tenant or PII access)
• Ambiguous under eval (low confidence, conflicting tools)

Do not require approval for every token. That recreates the manual workflow you tried to automate. The skill is placing pauses where blast radius justifies them.

Patterns that work

1. Propose → approve → execute

The agent drafts the action (email, CRM update, ticket reply). A human confirms. Only then does the write happen. Preview must not mean “already written to production.”

2. Dual thresholds

Auto-run when confidence and policy checks pass. Otherwise escalate. Separate “looks fluent” from “safe to act.” Fluency is a presentation property. Safety is a systems property.

3. Role-scoped approvers

Ops can approve triage. Finance approves money moves. Do not invent a single “AI owner” for every risk class. Match the approver to the blast radius.

4. Timeboxed escalation

If nobody approves in N minutes, follow a documented fallback: queue, safe default, or notify on-call. Silent stalls are failures. Your users will invent their own workaround if you leave them hanging.

Controls beyond the button

HITL alone is not enough. Pair it with:

• Tool allowlists and least privilege
• Audit logs of tool calls and approvals
• Eval coverage for “should have paused” cases
• Override and kill switches

See workflow automation for how this gets scoped in engagements.

Design checklist

Walk this list with your team before you celebrate the demo:

1. List every side-effecting tool
2. Mark which need approval vs auto-run
3. Define approver roles and SLAs
4. Define timeout behaviour
5. Log proposals, decisions, and executions
6. Add eval cases for missed pauses and false pauses
7. Test the kill switch

Common mistakes

• Approving in Slack with no link back to the system of record
• Letting the agent “preview” by already writing to production
• No audit trail of who approved what
• HITL on reads only, while writes stay free

Each of these feels minor in a prototype. Each becomes painful after the first incident.

Bottom line

Controlled autonomy beats unchecked agents. Design the pause points before you celebrate the demo. If you want help mapping risk to gates for a real workflow, discuss your use case. Related reading: when not to use an agent.