Human-Approved AI Actions: Write-Confirm Explained

Write-confirm is the architecture that turns an AI agent's intent to act into a human-approved action: the agent proposes, the system pauses and surfaces the exact action, a person approves, and only then does it execute. Understanding how it works under the hood explains why it makes agent actions safe without making them slow.

The two-turn flow

At its core, write-confirm splits a mutating action across two turns. In the first turn, the agent reasons that a tool should be called — say, create a CRM lead. Instead of executing, the system intercepts the call, records it as a pending action with its exact parameters, and emits a confirmation event to the interface. The conversation pauses there. In the second turn, a human approves (or declines). On approval, the system executes the originally proposed call and feeds the result back into the conversation. The agent never touches the system directly; the gate sits between intent and execution.

Why interception, not trust

The key design choice is that the gate is structural, not advisory. It's not a prompt asking the model to "please confirm" — models can ignore that. The mutating tool is wrapped so that calling it cannot execute without passing through the approval step. The agent literally has no path to the side effect except the one that requires a human. That's what makes it reliable: safety doesn't depend on the model behaving, because the model can't bypass the gate.

Reads stay fast

Only mutating tools are wrapped. Read tools — lookups, searches — execute immediately, because they change nothing. This is why write-confirm doesn't slow the agent down for the things that should feel instant: answering questions, fetching status. The pause is reserved for the rare, consequential action. The visitor experiences a responsive agent; the operator sees an approval only when something real is about to happen. See human-in-the-loop AI for the principle.

What the operator sees

The approval surface shows the action concretely: which tool, on which target, with which parameters. A refund shows the amount and reason; a record update shows the fields. The operator isn't approving a vague "the agent wants to do something" — they're reviewing the precise effect. That specificity is what makes approval meaningful rather than a rubber stamp. Approve and it runs; decline and nothing happens.

Pairing with scope and audit

Write-confirm is one of three controls. Least-privilege scoping bounds what tools the agent has at all. Write-confirm gates the use of mutating ones. And an audit log records every call and approval, so you can later verify each write was signed off. The architecture assumes that any one layer could fail and ensures the others still hold. See MCP security for the surrounding controls.

Why it scales

Because the gate is uniform — applied to any tool marked mutating, from any MCP server — it scales across integrations without custom work. Connect a new server, mark its writes, and they're automatically gated. One approval mechanism covers every tool, which is only possible because MCP standardizes the read/write distinction.

Getting started

See write-confirm in action on the AIML.chat free plan: connect a tool and watch a write pause for approval. Compare tiers on the pricing page, and read our human-in-the-loop design for the deeper story.