Human-in-the-Loop Best Practices
Ten practices for designing privilege rings, approval gates, kills, and escalation so human oversight stays real under production load.
Use them as a design rubric and a PR checklist before agents gain side-effecting tools.
How to Use This List
- Walk A when scoping autonomy; B when implementing gates and kills; C when operating queues and evidence.
- Tick items only when true in code, config, and runbooks - not as aspirations.
- Pair with Common Guardrail Mistakes That Undermine Human Oversight for the inverse checklist.
- Re-check after adding tools, MCP servers, or new environments with real credentials.
A - Scope Autonomy First
- 1. Map every capability to a privilege ring. Observe, draft, mutate, and irreversible (or your equivalent) with a written default policy per environment.
- 2. Enforce rings in the tool dispatcher, not only in prompts. The host must allow, deny, or pause before side effects.
- 3. Prefer split tools over dual-mode mega-tools. Draft and send (or read and refund) should not share one ungated entrypoint.
- 4. Default-deny new tools and MCP servers. Assign a ring and owner before the model can call them.
- 5. Keep least privilege per role and environment. Dev, staging, and prod policies differ; real credentials imply real gates.
B - Gates, Kills, and Escalation
- 6. Hard-gate irreversible and external actions. Fail closed on timeout; support approve, reject, and edit with re-validation.
- 7. Bind decisions to exact args and idempotency keys. Prevent double execute; show humans the payload that will run.
- 8. Ship a kill switch with shared state and tool-boundary checks. Per-run and global scopes; cancel in-flight work where possible.
- 9. Escalate when stuck instead of guessing. Cap retries; route briefs with a clear question to the right queue.
- 10. Freeze side effects while waiting on humans. Pending approval or escalation is not a green light for other writes.
C - Operate Oversight Over Time
- 11. Emit audit events for requests, decisions, executes, kills, and escalations. Include actor, run id, and args fingerprint.
- 12. Redact secrets from packets, logs, and chatops. Show destinations and amounts; never paste live tokens.
- 13. Staff and measure the human queue. Track volume, approve rate, time-to-decision, and sample for rubber-stamping.
- 14. Close bypass paths. Notebooks, crons, and admin scripts use the same dispatcher or an explicitly audited break-glass flow.
- 15. Drill approve, reject, kill, and escalate in staging. Controls that are never practiced fail in the first SEV.
Applying These Practices in Order
- Scope (1–5): cheapest to fix before tool sprawl; blocks silent autonomy.
- Runtime controls (6–10): launch blockers whenever credentials or customers are real.
- Operate (11–15): keeps oversight honest after traffic and fatigue set in.
FAQs
Why "ten practices" if there are fifteen checkboxes?
Items 1-10 are the core HITL design practices. Items 11-15 extend them into evidence and operations so the list stays useful after launch.
What is the first practice if we can only adopt one?
Hard-gate irreversible tools in a single dispatcher (practices 2 and 6). Everything else builds on a choke point that can pause.
How do these practices relate to frameworks?
They are framework-agnostic. LangGraph interrupts, AI SDK tool-approval states, and custom queues are mechanisms; rings and packets are the policy.
Do internal admin agents need the same rigor?
Yes when they can touch prod data, money, or customer messages. Internal does not mean low blast radius.
How do we reduce approval fatigue without removing gates?
Widen safe auto-run (R0-R1), tighten packets for R2-R3, batch only similar low-medium items, and review queue metrics weekly.
When is dual control required?
High-value money movement, production deploys, broad permission changes, and any action your compliance policy already treats as dual-control for humans.
How should timeouts behave?
Fail closed for irreversible tools. Escalate to a secondary queue if you need coverage; do not treat silence as consent.
Where should kill switches live in the UX?
On the run detail page, in authenticated chatops, and in on-call CLI. Measure time-to-trip in drills.
Can we auto-approve after N successful runs?
Only for narrow, templated arg envelopes with strong monitoring - never as a blanket for open-ended tool args.
How do audit trails differ from product analytics?
Audit answers who authorized which side effect. Analytics answers funnels and engagement. Keep access and retention appropriate to each.
What evidence shows practice 1 was violated?
Tools with side effects that have no ring label, or one allowlist where refunds and search share the same auto policy.
Where should teams link this list?
In the section sidebar as the close-out checklist, and from ADRs or runbooks that introduce new agent side effects.
Related
- Privilege Rings: Scoping What an Agent Can Do Without Asking - tier model
- Human-in-the-Loop Basics - first gate patterns
- Building an Approval Gate Before Irreversible Actions - gate recipe
- Kill Switches: Stopping a Runaway Agent Mid-Execution - emergency stop
- Designing Escalation Paths When an Agent Gets Stuck - uncertainty routing
- Audit Trails: Logging Every Agent Action for Later Review - evidence design
- Common Guardrail Mistakes That Undermine Human Oversight - inverse checklist
Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana
@solana/web3.js+@solana/spl-token.