Human-in-the-loop, literally: the five approval outcomes that keep agents accountable

Almost every agentic AI vendor now says it keeps a “human in the loop.” The phrase has become so common that it no longer tells a buyer anything. The question that matters for a regulated enterprise is narrower: when the agent reaches a consequential step, what can a person actually do about it?

Approve / reject is not enough

If the only choices are approve or reject, reviewers face a bad trade-off. Reject a nearly-right action and the work stalls; approve it to keep things moving and the control becomes a rubber stamp. Real operational work lives in between — a draft that needs one figure corrected, an action that’s fine once a question is answered, a decision that belongs one level up.

Zahen models approval as five explicit outcomes, not a binary:

• Approve — the action proceeds as proposed.
• Reject — the action is stopped, with a reason recorded.
• Edit & approve — the reviewer adjusts the proposed action, then approves the corrected version.
• Request more info — the task pauses and asks for what’s missing instead of guessing.
• Escalate — the decision is routed to someone with the authority to make it.

Each outcome is a recorded decision, attributable to a named person. That is the difference between a control that produces evidence and one that just slows things down.

Risk lives on the tool, not the task

A common failure mode is asking humans to approve everything, which trains them to approve without reading. Governed execution inverts this: risk is a property of the tool, not the task. Reading a policy document is low-risk and runs freely; issuing a refund, sending an external email, or writing to a system of record is high-risk and pauses automatically for a human decision.

Because risk is configured per tool, the set of actions that require approval can be tightened or loosened without touching the workflow logic — and a tool can be switched off entirely with an instant kill-switch, no code deploy required.

The rule that cannot be overridden

The most important property is the one that’s easy to skip in a demo: no self-approval. The person (or agent) that proposes a high-risk action cannot be the one that approves it. This rule is enforced by the platform and cannot be overridden — not by an administrator, not by a configuration flag.

This is what separation of duties looks like in software. It’s also what a risk or compliance reviewer is looking for when they decide whether an agentic workflow can go to production. Approvals taken from a chat channel — for example, approving or rejecting directly from a Slack message — run as you, under the same role-based permissions, and the no-self-approval rule still holds.

Why this matters before you scale

Enterprises that get agentic AI into production — in the UAE and elsewhere — tend to share one habit: they treat the approval model as a first-class design decision, not an afterthought bolted on before launch. Start there. If you can answer “what can a reviewer do, and what can they never do?” in concrete terms, you have a workflow that survives a risk review. If you can’t, you have a demo.