MCP and tools
Human-in-the-loop queues for irreversible MCP actions
If Claude can refund, post, or export, it needs a review queue, not a braver system prompt. Here is how we design human checkpoints that agents actually wait on.
July 20, 2026/3 min read/Claude Certified Engineers
A human-in-the-loop queue is a required stop between Claude drafting an action and the action hitting a system of record. The stop is a record with a payload, a reviewer, a decision, and an id the execute tool must present. A Slack ping is not a queue. A stronger system prompt is not a queue.
We put this seam in every MCP integration that can move money, PHI, or master data.
Draft, review, execute
Three tools, not one:
draft_refundwrites a review item. Allowed in production.- A human UI shows the payload, the trace, and the policy that applied.
execute_refundrequireschange_ticket_id. The server checks the ticket is approved and unexpired.
If execute exists without the id, Claude will call it. See tool schemas. The server must reject missing, expired, or already-used tickets. Idempotency matters here: an agent that retries an approved refund must not charge twice.
Reads can stay on the agent. get_invoice does not need a human. post_credit_memo does. The line is irreversibility and sensitivity (money, PHI, privilege, master data, production config), not "the model might be wrong." The model is sometimes wrong on reads too. You accept that. You do not accept a silent wire.
Product, not ceremony
Give reviewers a queue with SLA, filters, and an audit trail. Staff it. If the queue is a shared inbox nobody owns, people will bypass it and you will put execute back on the agent.
A workable queue shows:
- The proposed payload, not a prose summary Claude wrote about the payload.
- The trace: tools already called, records already read.
- The policy that applied ("refunds over $500 need finance").
- Approve, reject, or request changes. Rejection must be a first-class tool result the agent can explain to the user.
Eval the path. Cases where the user begs Claude to "just do it" must still stop. That is a P0 in the guardrail suite. If your golden set has no "ignore the queue" case, you do not have a safety suite. You have a happy path.
Draft-only is a valid production design
Architect-level review is the person who asks whether Claude should have the execute tool at all. Sometimes the right design is draft-only forever. A legal research agent that never files. A CRM agent that never updates. That is still a shipped system, and it is often how you make week six of a build without gambling the ledger.
On Salesforce and SAP work we default to draft-plus-queue for writes. See Claude on Salesforce and SAP. If your current MCP server exposes update with a freeform object, the next change is not a nicer prompt. It is this split.
Questions
- When does a Claude agent need a human in the loop?
- Whenever the tool is irreversible or sensitive: money movement, PHI, privilege-aware legal files, master data deletes, production config. Reading a record is usually fine. Posting one is not.
- How do we stop Claude from calling the execute tool anyway?
- Do not ship the execute tool without a required change_ticket_id that only the review UI can mint. Schema plus server validation, not a polite request in the prompt.
- Does a queue slow the six-week build?
- No. A queue is how you ship in six weeks without gambling production. Skipping it is how nine-month demos happen.