How to add a human gate to an agent workflow

Put the gate at the moment of action, not in the prompt. Mark each step by how hard it is to undo, let the agent draft everything at or above that line, and route the draft to a named person who approves, edits or refuses it. The platform holds the action until they decide, and files the verdict.

What is a human gate, and who owns it?

A human gate is a point in a workflow where the agent stops, presents a finished draft, and waits for a named person to decide. The action already exists in full: the payment instruction, the letter, the account change. Nothing leaves the system until someone with the authority to approve it says yes.

Two people own a gate. The process owner decides where it sits and who may clear it. The approver owns each decision that passes through it. Neither should be the engineer who built the agentic workflow, because the gate exists to put judgement outside the build.

The gate is not an instruction to the model. "Ask a human before paying" written into a prompt is a request the model may or may not follow. A gate is enforced by the layer that executes the action, so the agent cannot skip it, talk its way past it, or forget it after a long conversation.

How do you add the gate, step by step?

1. Person, process owner: list every action the workflow takes. Write each one as a verb on a system: "creates a credit note in the ledger", "sends an email to the customer". Reads count too, but they rarely need a gate.
2. Person, process owner: mark each action by how it is undone. Some actions reverse cleanly; some reverse with cost or embarrassment; some do not reverse at all. Anything in the last two groups is a gate candidate.
3. Agent, depth 1: replay recent cases and report which actions it would have taken. This shows how often each gate would fire. A gate that fires on every case will be rubber-stamped within a week.
4. Person, process owner: set the gate rule per capability. For example, "refunds up to the customer's limit run; above it, held for the team lead". The rule lives in the platform's bounds, not in the workflow definition.
5. Person, process owner: name the approvers and a fallback. Name a role and a deputy, with the authority each holds. An approver may not clear an action they requested.
6. Agent, depth 2: drafts the action and its reasons. The held item shows the exact action, the facts the agent used with their sources, and why the agent chose it.
7. Person, approver: approves, edits or refuses. An edit is recorded as a change by the approver, not as the agent's work.
8. Platform: executes or releases. On approval the action runs under the approver's authority. If nobody decides within the set window, the item expires as refused. A gate must never time out into approval.

Which controls make the gate hold, and what evidence do they leave?

Enforcement outside the model. The action is checked when it is attempted, against the bounds held by the platform. Evidence: a verdict of held, with the bound that decided it.

Separation of requester and approver. The person who asked for the work cannot clear it. Evidence: two identities on the record for every gated action.

Context shown to the approver. The approver sees what the agent saw, not a summary of it. Evidence: the source facts are linked to the held item, so a reviewer can later check what the approver had in front of them.

Expiry to refusal. A held item that nobody touches becomes refused. Evidence: an expiry entry with the time and the approver queue it sat in.

One definition in one place. Gates defined inside each workflow drift apart as people copy and edit them. The argument for keeping human gates in the platform rather than in each workflow is that one change to a bound applies everywhere, and one record shows what the rule was on any given day. Evidence: a versioned bounds history.

What should you measure once the gate is live?

• Hold rate: the share of actions that stop at the gate. If it is close to all of them, the line is too low; if it is close to none, check that the gate is wired at all.
• Edit rate: how often approvers change the draft before approving. A falling edit rate is the strongest sign the agent is drafting well.
• Refusal rate and reasons: what approvers say no to, grouped by reason. Repeated reasons belong in the agent's brief.
• Time to decision: how long items wait. A long queue pushes people to approve in bulk.
• Approval time per item: an approver clearing complex items in a few seconds each is not reviewing them.

Where does a human gate usually go wrong?

Rubber-stamping. The gate fires so often that approval becomes a reflex. Fix the line, not the people: move routine, reversible actions below it so the gate only sees decisions that need judgement.

The approver sees a summary. If the held item says "refund approved by policy" without the facts, the person is approving the agent's conclusion, not the action. Show the inputs.

The gate sits in the workflow, and the agent has another route. A second tool or a different workflow reaches the same system without the gate. Gate the capability, not the path.

Nobody owns the queue. Items pile up over a holiday and someone approves the backlog in one sitting. Name deputies and watch time to decision.

Approvals are not tied to authority. A team lead clears an action above their own signing limit because the queue let them. The approver's own limits must be one of the bounds the platform checks.

Where Pryme fits

In Pryme, a human gate is the held verdict. It comes from the minimum chain of bounds checked when the agent attempts an action, so the same gate applies whichever workflow reaches the capability. Every held, approved, edited or expired item is filed in the append-only record. The wider design is set out in the governed agentic operating system guide.