Human-in-the-Loop for AI Agents: How to Design an Approval Gate

Key takeaways

• Put a gate on any agent action that changes a record, contacts someone outside the team, or cannot be cleanly undone. Keep final decisions out of the agent’s reach entirely.
• Design the reviewer’s screen so a trained person can decide in a couple of minutes: the proposed action, the evidence behind it, and what happens on each choice.
• Offer three choices, approve, reject and return, and make the reason a structured field. Rejection reasons are the best data you will get about the agent.
• On timeout, do nothing and escalate. Never approve by default.
• Widen authority one action type at a time, using the gate’s own history, and keep the person who owns the workflow in charge of that decision.

“Human in the loop” is easy to write in a design document and hard to build well. The phrase tells you a person is involved somewhere. It does not tell you which actions they see, what evidence is in front of them, how long they have, what their choices are, or what gets written down. Those details decide whether the gate protects anything.

This post walks through one gate in one regulated workflow, commercial KYC onboarding at a bank, and pulls out the design decisions a risk or operations lead can reuse. If you are looking for who answers for an agent’s outcome, that is a different question, covered in who is accountable when an AI agent makes a bad decision. Here the subject is the mechanics of the gate itself.

The workflow and the owner

The setting is commercial onboarding. A KYC evidence agent gathers what the applicant typed, what they uploaded and what external registries hold, compares them, and lists the differences. We described that agent in detail in how a KYC evidence agent works in commercial onboarding.

The accountable owner for the gate in this example is the KYC onboarding analyst who works exceptions, with the compliance officer above them owning the final onboarding decision. The agent prepares. The analyst approves or turns down what the agent proposes to do next. The compliance officer decides whether the bank takes the customer.

The agent never proposes “approve this customer”, because that action is not in its toolset. It does propose the smaller steps in between, and some of those carry real consequence.

Step one: decide which actions get a gate

List every action the agent can take in the workflow and sort them by what happens if the action is wrong.

In this example the list looks something like this:

A usable rule: gate anything that changes a record someone else relies on, anything that leaves the team, and anything that cannot be cleanly reversed. Leave reading, comparing and drafting ungated, and limit what the agent can reach so that ungated actions stay harmless. The last row is the important one. Decisions with regulatory weight should be unreachable by the agent, which is stronger than gating them.

Everything gated is a consequential action, and a person decides each one. This gate design sits inside a broader risk and control framework that covers identity, runtime policy and evidence as well.

Step two: design what the reviewer sees

Take one item from the analyst’s queue. The registry shows a shareholder at 22 percent. The tax-authority extract shows 28 percent. Under the bank’s policy, which applies the FinCEN 25 percent beneficial ownership threshold, the answer decides whether this person is screened. The agent proposes to write 28 percent to the case record because the tax extract is more recent.

The analyst’s screen should show, in this order:

1. The proposed action, in one sentence. “Set shareholder ownership for J. Okafor to 28 percent on case 4471.” Plain words, with the exact field and value.
2. Why the agent proposes it. The rule or rubric it applied (“prefer the most recent authoritative source”), and its stated confidence if your workflow records one. Treat this as an output to check.
3. The evidence, side by side. Both values, each with its source, retrieval time and a link to the underlying document. The agent should never show only the value it prefers.
4. What each choice will do. Approve writes 28 percent and triggers screening for this shareholder. Reject leaves the record unchanged and closes the proposal. Return sends the item back to the agent with the analyst’s instruction.
5. What else is waiting on this item. For example, “compliance approval is blocked while this exception is open.”

If a trained analyst cannot decide from that screen in a couple of minutes, fix the screen before you blame the reviewer. Usually the source document or policy rule is missing, or the agent’s preferred value is presented as fact.

Step three: approve, reject or return, with a reason

Three choices cover almost everything.

• Approve. The action runs as proposed. The analyst can add a note.
• Reject. The action does not run. A reason is required.
• Return. The action does not run, and the item goes back with an instruction, such as “use the certified share register instead, requested on the 12th.” Return keeps the work alive without forcing the analyst to rebuild it by hand.

Make the reason a structured field with a short free-text note beside it. In this workflow the codes might be: wrong source preferred, evidence missing, outside policy, wrong action for this case, duplicate. Free text alone is unreadable at volume. Codes give you a picture of what the agent gets wrong.

Rejection reasons are the most useful data the gate produces. If “evidence missing” dominates, the agent is not reaching a source it needs. If “wrong source preferred” dominates, the rubric is wrong. Review the codes with the workflow owner on a fixed cadence, and change one thing at a time.

Step four: record the decision

Each gated item should leave a record that someone outside the team can read months later without asking an engineer:

• The proposed action, exactly as the reviewer saw it
• The evidence shown, with sources and retrieval times
• The reviewer’s identity, their choice, the reason code and note, and the time
• What then happened: the write, the message sent, or nothing
• Any timeout or escalation along the way

This record is one piece of the wider case record. Our decision records checklist covers the rest: session, prompt and policy version, tool calls and refused actions.

Step five: decide what happens on timeout

Analysts go on leave, queues spike at quarter end, and some items will sit.

A timeout should never approve. When the window passes, the proposed action stays unexecuted, the item stays in the queue, and it escalates to a named deputy. Record the timeout as an event. If it times out again, it goes to the workflow owner. The case simply waits, which is what would have happened without the agent.

Pick the window by consequence and by service level. In this illustrative setup, a document request to an applicant might escalate after four business hours because the customer is waiting, while a record correction might wait until the next morning. These numbers are illustrative; set yours with the owner of the service level.

If items time out often, the gate is in the wrong place or the team is understaffed for it. Solve that directly rather than letting the gate approve on its own.

Step six: guard against rubber-stamping

A gate that approves everything in seconds protects nothing, even when reviewers are doing their best with an impossible queue. Watch for it with the gate’s own data:

• Approval rate and time-to-decision, per gate and per reviewer. As an illustration, if one gate is approved in more than 98 percent of cases with a median decision time under ten seconds, investigate. Either the action is safe enough to pre-approve, or nobody is reading the evidence.
• Reviewer load. Cap how many items one person handles in a sitting and spread the queue. Fatigue shows up as speed before it shows up as errors.
• Second-review sampling. Send a small sample of approved items to another reviewer. Disagreements tell you where the screen or the policy is unclear.
• Seeded items. Occasionally put a known-bad proposal into the queue, such as a value that contradicts its own source, and check it gets rejected. Tell reviewers this happens. The point is to test the gate rather than to catch anyone out.

Step seven: separate duties

The same separation you use for people should apply to agent approvals:

• Nobody approves an action they initiated. If an analyst triggered the evidence run and steered the agent with an instruction, a different analyst approves the resulting record write, or at least the final decision sits with someone else.
• The person who maintains the agent’s prompts, rubric or tool access should not be the person approving its actions in production.
• The analyst who approves exception fixes does not also give the final onboarding approval. In this example that belongs to the compliance officer, who cannot approve while a required exception is open.

Moring applies the same principle at the platform level: nobody approves their own deploy, and only named production approvers can promote an agent.

Step eight: graduate authority one action type at a time

After some weeks of gate data, the workflow owner may decide that some proposals no longer need a person every time. Requesting a missing standard document from the applicant, from a fixed list of document types, is a typical candidate.

Make that a recorded decision with clear limits:

• It applies to one action type with stated bounds (standard document list, no free-text message, one request per document per case).
• It rests on the gate’s history: rejection rate, the reasons for the rejections that did happen, and sampled reviews. Use your own figures and write down the threshold you used.
• The workflow owner and a risk approver both sign off, and it is reversible. A rise in complaints or a bad sample moves the action back behind the gate.
• Pre-approved actions are still logged and still sampled.

Some things never graduate. Writing a value that decides whether someone is screened, closing an exception, and anything the compliance officer owns stay with people. The agent gets faster at the preparation; the human keeps the decisions. For how these human in the loop controls connect to the rest of a governance program, see the Moring AI Governance hub.

Where the gate is enforced matters

A gate that lives only in a prompt (“ask the user before writing to the case system”) is an instruction the model can ignore or be talked out of. Enforce the gate outside the agent, at the point where the tool call happens.

In Moring, tool access goes through the MCP Gateway, where each tool server carries its own guardrails. Human approval is one of them, alongside rate limits, content filters, PII redaction and blocked patterns. Each agent has its own key, which reaches only the models it was granted and carries a monthly budget. If an agent misbehaves, Stop agent blocks its key so the gateway refuses every call, with who, when and why on record, and only the production approver or a super admin can resume it. The reviewer screen and reason codes described above belong to your workflow design; the platform’s job is to make sure the action cannot run until a person has said yes.

A short design checklist

• Every agent action is listed and sorted into ungated, gated, or out of reach
• Final regulatory decisions are not agent actions at all
• The reviewer screen shows the action, the reason, both sides of the evidence, and the effect of each choice
• Approve, reject and return are available, with structured reason codes
• Timeouts escalate to a named deputy and never approve
• Approval rate, time-to-decision and reviewer load are monitored per gate
• A sample of approvals gets a second review
• Nobody approves an action they initiated or an agent they maintain
• Each widening of authority is a recorded, bounded, reversible decision

The KYC demo walks through one onboarding case with these hand-offs, and our banking page covers related workflows. For a gate designed around a licensed decision rather than an analyst review, the claims triage walkthrough shows the same pattern in an insurance claim. If you would rather test it against your own process, send us one workflow you are considering for an agent. We will go through which actions in it need a gate and what the reviewer would need to see, and you can decide from there.

Frequently asked questions

Sources

About the author

Arya SharanProduct Marketing & GTM, Moring AIChennai

Owns product marketing and go-to-market at Moring AI across positioning, demand and enablement. Works with regulated buyers on how governed AI agents are scoped, evaluated and bought. Writes about the operating questions that decide whether an agent reaches production.

LinkedIn profile →