Key takeaways
- Classify tools by side effect and require gates for write and irreversible classes.
- Show a human-readable diff of the proposed action before execution.
- Define timeout, escalate, and cancel behavior for pending approvals.
- Store identity, draft, decision, and execution result as one audit record.
Why draft mode is the real production default
Demos celebrate autonomy. Operations celebrate reversibility. Most enterprise damage from agents comes from write tools that ran without a human seeing the proposed side effect.
A write gate is not distrust of models. It is acknowledgment that irreversible actions need the same change-management instincts you already apply to production deploys. Agents prepare; humans authorize when blast radius is high. The alternative is learning from refunds, customer messages, and config changes after they have already left the building.
Operators know the failure pattern: a helpful agent "just finishes" the workflow. The run looks successful in the product UI. Finance or support discovers the side effect later. By then the audit trail is a chat transcript and a tool log that do not agree on the payload.
Gates sit inside the harness (multi-agent harness deployment) and should align with task-based access control so approvals are task-scoped. A gate that approves any write the model proposes, regardless of task, is only a slower form of autonomy.
Failure modes without write gates
Silent execution. The model calls refund.create and the money moves before anyone reviews. The demo looked smooth. Production traffic makes the same path an incident.
Unreadable proposals. Humans are asked to approve raw JSON they cannot sanity-check. Approvers rubber-stamp because the UI is hostile. The gate exists on paper and fails in practice.
Stuck runs. Approvals never expire, queues grow, and operators disable the feature entirely. Autonomy returns through a feature flag named "temporary."
Split brain audits. Chat says approved, the tool log shows a different payload executed. The agent mutated the draft after the yes, or a retry replayed a different body.
Orphan approvals. The approving human leaves mid-shift. No escalate path exists. The draft sits until a customer complains, then someone executes without the original context.
The write-gate control model
Classify tools: read, write, irreversible. Reads auto-run under policy. Writes may auto-run only in low-blast sandboxes. Irreversible always drafts.
Render a diff: fields changing, target record, money amounts, message text, and who will be affected. Prefer domain language over tool jargon. If an approver cannot explain the blast radius in one sentence, the proposal UI is not ready.
On decision: approve executes once with idempotency keys; reject records reason; timeout follows a documented policy (reject, escalate, or park).
Operable steps:
- Tag every tool in the registry with a side-effect class.
- Block irreversible tools from direct execution in the harness and gateway.
- Persist a draft object with a content hash before showing the approval UI.
- Bind approve/reject to that hash; any mutation requires a new approval.
- Execute with idempotency keys and record the approving identity on the same audit row as the result.
Loading diagram…
Timeouts, identity, and idempotency
Bind approvals to the draft hash. If the agent changes the payload, require a new approval. Never execute a mutated draft under an old yes. This single rule prevents most split-brain audits.
Propagate the approving human's identity into the tool call audit, alongside the agent run ID. Finance and security will ask who authorized the action. "The agent" is not an acceptable answer for money movement or production config.
Define timeout behavior in writing before launch: reject, escalate to a secondary queue, or park with customer-visible status. Measure queue depth and age continuously. An approval SLA that nobody owns will be violated silently until someone turns HITL off.
Use idempotency keys so retries after partial failure do not double-charge or double-message. Pair with MCP gateway auth so drafts cannot be executed through a back door that skips the gate.
Evaluation of gates, not only of answers
Eval the gate itself. Cases should include: correct approve, correct reject, mutated draft after approve (must re-gate), timeout paths, and attempts to execute the same draft twice. End-to-end "helpful answer" scores will not catch a bypassed gate.
Mine reject reasons weekly. High reject rates on one tool often mean bad drafts, bad diffs, or a task type that should not reach irreversible tools yet. Low reject rates with rising incidents mean rubber-stamping.
Rollout and metrics
Start HITL on the top three irreversible tools. Measure approval latency, reject reasons, timeout rate, and post-approve incident rate. Add on-call ownership for the approval queue the same way you staff deploy approvals. If nobody owns the queue overnight, timeouts will fire into a void and operators will bypass the gate.
Widen autonomy only where reject rates are low and reverse paths exist. Promote a tool from irreversible-gated to auto-write only with evidence, not with optimism from a demo week. Keep a kill switch that returns a tool to gated draft mode without redeploying the whole harness.
Write gates turn agent autonomy into a controlled pipeline: speed where it is safe, friction where mistakes are expensive. That is how agentic workflows earn production trust without pretending that fluent tool calls are the same as authorized change.
FAQ
- What is a human-in-the-loop write gate for agents?
- A write gate pauses agent execution before a side-effecting tool runs, presents a draft or diff to an authorized human, and only executes after approve, reject, or timeout policies resolve, with a full audit trail.
- Which agent actions should require human approval?
- Anything that spends money, deletes or overwrites data, messages customers, changes production config, or is otherwise hard to reverse. Read tools and low-risk drafts can stay automated with logging.
- How do you keep HITL from blocking all automation?
- Scope gates to high-blast tools, batch low-risk writes after trust is earned, use step-up only when TBAC marks elevated risk, and measure approval latency so queues stay operable.