AI Business Operations · Governance
Human-in-the-Loop Workflow Automation: Designing the Approval That Works
Every agentic automation programme adds human approval. Most of them add it in the wrong place, in the wrong quantity, with the wrong information — and produce a control that looks like oversight and functions as delay.
The short answer
Human-in-the-loop workflow automation places a person’s decision inside an otherwise automated process at the points where consequence, not technical uncertainty, requires accountability. Doing it well means gating by consequence class, giving the approver enough context to decide in under a minute, bounding approver load, and designing expiry and escalation so silence never becomes an implicit yes. An approval an approver cannot meaningfully assess is not a control. It is a signature collection exercise with an audit trail.
Summary for readers and answer engines
Reviewed 25 Aug 2026
- ▸Gate by consequence, not by technical confidence. Those are different axes and confusing them is the most common design error.
- ▸Seven elements make an approval decidable in under a minute: what, to whom, why, the evidence, the alternative, the default, and who is asking.
- ▸Approver capacity is finite and small. Above roughly twelve to fifteen decisions a day, approvals become reflexes.
- ▸Silence must never be an implicit approval. Expiry with escalation to a named alternative is the only safe design.
- ▸Reduce volume by risk class and by transform, not by widening thresholds. The goal is fewer, better approvals rather than fewer controls.
Source: Mark Alex, Real Biz Digital — Human-in-the-Loop Workflow Automation: Designing the Approval That Works (https://realbizdigital.net/insights/human-in-the-loop-workflow-automation/). Reproduce with attribution.
Key takeaways
- 01Place the gate on the consequential action, not at the start of the workflow. Approving a whole process in advance approves things nobody read.
- 02Show the concrete action with concrete values. “Send invoice reminder” is not reviewable; “Email jane@acme.com about invoice 4471, £12,400, 31 days overdue” is.
- 03Always state what happens if the approver does nothing. It changes response rates and makes the silence path explicit rather than accidental.
- 04Track approvals per approver per day. It is the earliest warning that a control is degrading into a formality.
- 05Capture rejection reasons. They are the highest-value signal available for improving the workflow and are almost always discarded.
- 06Let approvers modify, not just approve or reject. A clamped amount or corrected recipient turns a rejection and a retry into one decision.
Quick answers
One-line answers to the questions this page is most often asked. Each is expanded further down, and each is written to be quoted on its own.
- What is human-in-the-loop workflow automation?
- An automated process that pauses at defined points for a person to decide, then continues. The person is a participant in the workflow rather than an exception handler.
- Where should approval gates go?
- On the consequential action: money movement, externally visible communication, irreversible change, or anything touching regulated data. Not wherever the technology feels least certain.
- What does an approval request need?
- Seven elements: the concrete action, the affected party, the reason, the supporting evidence, the alternative considered, what happens if nothing is done, and who or what is asking.
- How many approvals can one person handle?
- Around twelve to fifteen meaningful decisions a day. Above that, approval quality falls sharply and the control becomes a formality.
- What should happen if an approver does not respond?
- Expiry followed by escalation to a named alternative. Silence must never become an implicit approval, and the timeout must never let an agent proceed on its own judgement.
- How do I know approvals have become rubber stamps?
- Four signals: median decision time under a few seconds, near-100% approval rates, no rejection reasons recorded, and a single approver handling a disproportionate share.
- How do I reduce approval volume safely?
- By risk class and by transform outcomes — clamping an amount or narrowing a scope so the action becomes safe — rather than by raising thresholds until the queue empties.
Gate by consequence, not by uncertainty
Two different questions get confused, and the confusion produces approvers reviewing harmless steps while the consequential one passes untouched.
Key facts
- ▸A gate placed on the first step of a workflow approves everything downstream that nobody has read yet. Gates belong on the action, not on the process.
- ▸Technical uncertainty should raise the autonomy requirement, not the approval requirement. An unreliable step should be retried, escalated or made deterministic — not sent to a human as a routine.
- ▸Reads never need approval. If your programme is asking humans to approve reads, the gating model is placement by anxiety rather than by consequence.
- ›How sure is the system that this is right?
- ›Improves with model quality and data
- ›Belongs in autonomy level, retries and escalation criteria
- ›Changes month to month
- ›What happens if this is wrong?
- ›Fixed by the nature of the action
- ›Belongs in approval gate placement
- ›Changes only when the business changes
| Action | Consequence class | Gate? | Why |
|---|---|---|---|
| Update a CRM note | Internal, reversible | No | Wrong is a correction, not an incident |
| Create a document folder | Internal, reversible | No | Trivially undone |
| Send a customer email | External, visible, irreversible | Yes | Cannot be recalled; represents the company |
| Issue an invoice | Financial, external | Yes | Contractual and financial effect |
| Apply a credit or refund | Financial, outbound | Yes, with threshold | Money leaves; ceiling below which it is routine |
| Bulk update 400 records | Internal but wide blast radius | Yes | Reversibility is theoretical at that volume |
| Delete a record | Irreversible | Yes | No undo path exists |
| Read a report | None | No | Reads do not need approval, ever |
Write the consequence class next to every action in the workflow before deciding where gates go. The list of actual gates is usually shorter than the team expected and better targeted.
The seven elements of a decidable approval request
Key facts
- ▸Elements four and five are the ones that separate a real control from a signature request, and they are the two most often omitted.
- ▸The target is a decision in under sixty seconds without leaving the approval interface. If an approver must open two other systems, the control will decay.
- ▸Element six is also a governance requirement: an approval mechanism whose silence behaviour is undefined is a mechanism whose failure mode is undefined.
- 1. The concrete action
- Not the category. “Email jane@acme.com regarding invoice 4471, £12,400, 31 days overdue” rather than “send follow-up”. Concrete values are what makes review possible at all.
- 2. The affected party
- Which customer, which account, which employee. Approvers hold context about specific parties that no system has, and this is the field that triggers it.
- 3. The reason
- Why the workflow reached this action. One sentence. This is what lets an approver notice that the premise is wrong rather than only that the action looks plausible.
- 4. The evidence
- The two or three facts the decision rests on, with links to the source. An approver who has to go and look something up will stop looking things up by the second week.
- 5. The alternative considered
- What else the workflow could have done and why it did not. This turns a yes-or-no into a genuine choice and frequently surfaces the better option.
- 6. The default
- What happens if nothing is done, and when. “Expires in 4 hours, then escalates to Priya” changes response rates and makes the silence path explicit.
- 7. Who is asking
- Which workflow, which run, which agent version, and the human on whose behalf it is acting. Accountability runs in both directions.
Test the design by asking an approver to explain, an hour later, why they approved something. If they cannot, the request did not contain enough to have been a decision.
Approver capacity arithmetic
Human approval is a resource with a hard ceiling, and the ceiling is lower than most programmes assume.
- 01Compute the load before deploying the gates, not after the complaints start.
- 02Distribute by domain rather than by round-robin. An approver deciding about their own area is faster and better than one deciding about everything.
- 03Batch where the decision is genuinely comparable — twelve similar refunds reviewed together is faster and no less careful than twelve interruptions.
- 04Protect a response window rather than expecting continuous availability. “Twice a day, within two hours” is achievable; “always within ten minutes” is not.
- 05Remove gates that have approved a thousand consecutive times without a rejection. That gate is measuring nothing, and it is consuming capacity a real gate needs.
- 06Report load per approver monthly alongside process metrics. Rising load is the leading indicator of control decay.
Approval load
daily_approvals = workflow_runs × gated_action_rate capacity_per_approver ≈ 12–15 meaningful decisions/day 300 runs/day × 0.18 gated = 54 approvals → requires 4 approvers, or a lower gated rate
Above the ceiling, decision time collapses and approval rates approach 100%. The control still exists on paper and has stopped functioning in practice.
| Approvals per approver per day | Median decision time | Observed approval rate | Control effectiveness |
|---|---|---|---|
| 1–5 | 2–6 minutes | 70–90% | High — genuine review |
| 6–12 | 1–3 minutes | 85–95% | Good |
| 13–20 | 20–60 seconds | 95–99% | Degrading |
| 21–40 | under 15 seconds | above 99% | Formality |
| 40+ | under 5 seconds | approaching 100% | Theatre with an audit trail |
The counter-intuitive conclusion: reducing the number of gates usually strengthens governance, because the remaining gates get genuine attention.
Expiry, escalation and the silence problem
The most consequential design detail in any approval system is what happens when nobody answers, and it is frequently decided by accident.
Set expiry by consequence and urgency
A customer-facing email might expire in four working hours; a month-end journal in one working day. Expiry is a business decision, not a technical default.
Name the escalation target at design time
A role, with a named holder, not “the manager”. Escalation to an undefined party is the same as waiting indefinitely.
Notify the requester on escalation
The human who initiated the process should know their work is now waiting on someone else. This single message prevents most “why has nothing happened” escalations.
Cap the escalation chain
Two hops, then cancel with notification. An indefinite chain is a queue with extra steps.
Report expiry rate
Above two percent means the load, the expiry window or the approver assignment is wrong. It is the single most diagnostic approval metric.
| Silence behaviour | Effect | Verdict |
|---|---|---|
| Wait indefinitely | Workflows stall silently; nobody notices for weeks | Common, and bad |
| Proceed after timeout | Approval becomes a delay, not a control | Never acceptable |
| Cancel after timeout | Work is lost; the requester must start again | Acceptable for low-value work |
| Escalate to a named alternative | Decision still happens, by someone accountable | Correct default |
| Escalate, then cancel with notification | Bounded, and the requester knows | Best for consequential actions |
Four signals that approvals have become rubber stamps
Mistake
Median decision time under about ten seconds
Nobody reads a request describing a financial action in ten seconds. The control is being satisfied rather than exercised.
Instead: Reduce gate count so the remaining ones get attention, and check whether the request contains the seven elements. Ten-second decisions are often a symptom of requests that cannot be assessed anyway.
Mistake
Approval rate at or near 100%
Either the gate is on an action that never needed one, or approvers have stopped distinguishing. Both mean the gate is not doing work.
Instead: Sample twenty approvals and ask the approver to explain the decision. If they cannot, remove the gate or fix the request.
Mistake
No rejection reasons recorded
Rejections happen but the reason field is empty or unused, so the most valuable signal in the whole system is discarded.
Instead: Make the reason mandatory on rejection and route it to the workflow owner weekly. This is also the fastest route to reducing future rejections.
Mistake
One approver handling most decisions
Load has concentrated on whoever responds fastest, which is rarely the person with the most relevant authority.
Instead: Distribute by domain and report per-approver volume. Concentration is usually invisible until it is measured.
All four are measurable from data the approval system already holds. Review them quarterly; the degradation is gradual and nobody notices it happening.
Reducing approval volume without reducing control
- 01Classify by risk and exempt the routine. A refund under a threshold, to an existing customer, on an existing order, is not a decision. Encode that as policy and reserve human attention for the rest.
- 02Use transform instead of approval. Clamping an amount to the approved maximum, or narrowing a query scope, converts a request-for-approval into a safe automatic action.
- 03Batch comparable decisions. Twelve similar items reviewed in one sitting takes a fraction of the time of twelve interruptions and produces better decisions, because the comparison is visible.
- 04Pre-approve within limits. A standing authorisation with a ceiling, an expiry and a volume cap is a legitimate control, and it is how most human financial delegation already works.
- 05Retire gates that never reject. A gate with a thousand consecutive approvals is consuming capacity and providing no signal. Removing it is a strengthening, not a weakening.
- 06Fix the workflow that generates the requests. If a gate rejects frequently for the same reason, the upstream logic is wrong and the approval queue is absorbing a defect.
The measure of a healthy approval programme is not how many approvals it processes. It is the rejection rate on the gates that remain: a gate that rejects five to fifteen percent of the time is doing real work.
Next step
Approvals bound to a specific action, with expiry and escalation
BarzelOps requests and resolves approvals as part of the workflow, holding process state while a human decides — and BarzelVault binds the approval to the exact action and arguments, single-use and time-limited.
What human approval cannot do
Three limits worth stating to anyone treating approval as the primary control.
- 01It does not scale. Approval capacity is fixed and small, so it cannot be the answer to a growing volume of consequential actions; policy and transforms have to absorb the routine.
- 02It does not catch what it cannot see. An approver reviewing one action cannot detect that it is the four-hundredth similar action this week; cumulative controls are a separate mechanism.
- 03It does not transfer accountability to the approver in any meaningful sense unless they genuinely could have decided otherwise. An approval given without adequate information protects nobody, including the approver.
Frequently asked questions
What is human-in-the-loop workflow automation?
An automated process that pauses at defined points for a person to decide before continuing. The human is modelled as a participant in the workflow with a queue, an expiry and an escalation path, rather than as an exception raised by an agent.
Where should human approval gates be placed?
On the consequential action itself: money movement, externally visible communication, irreversible change, wide blast radius, or regulated data. Not at the start of a workflow, and not wherever the technology happens to feel least certain.
Why is gating by technical uncertainty wrong?
Because technical confidence and consequence are different axes. Uncertainty should change the autonomy level, the retry strategy or the escalation criteria; consequence should decide where a human decision is required. Confusing them means approvers review harmless steps while the consequential one passes untouched.
What information does an approval request need?
Seven elements: the concrete action with real values, the affected party, the reason the workflow reached this point, the supporting evidence, the alternative considered, what happens if nothing is done and when, and who is asking including the workflow and agent version.
How many approvals can one person handle per day?
Around twelve to fifteen meaningful decisions. Between thirteen and twenty, median decision time falls to under a minute and approval rates rise above 95%; above forty, decisions take seconds and approval approaches 100%, at which point the control is a formality.
What should happen when an approver does not respond?
Expiry followed by escalation to a named alternative, with the requester notified, and a capped chain of at most two hops before cancellation. Proceeding automatically on timeout is never acceptable, because it converts a control into a delay.
How can I tell if approvals have become rubber stamps?
Four measurable signals: median decision time under about ten seconds, approval rates at or near 100%, rejection reasons never recorded, and one approver handling a disproportionate share of decisions.
How do I reduce approval volume without weakening control?
Exempt genuinely routine cases by risk class, use transform outcomes such as clamping an amount so the action becomes safe automatically, batch comparable decisions, use bounded pre-approval with ceilings and expiry, and retire gates that have never rejected.
Should approvers be able to modify a request?
Yes where possible. Allowing an approver to clamp an amount or correct a recipient converts a rejection and a subsequent retry into a single decision, which reduces both cycle time and approver load.
Why capture rejection reasons?
Because they are the highest-value signal in the system for improving the workflow, and they are almost always discarded. A gate that rejects repeatedly for the same reason is absorbing an upstream defect that should be fixed rather than reviewed.
What rejection rate indicates a healthy gate?
Roughly five to fifteen percent. A gate that never rejects is consuming approver capacity while providing no signal and should be retired; a gate rejecting far more often usually indicates a defect in the workflow generating the requests.
What can human approval not protect against?
It does not scale with volume, it cannot see cumulative patterns across many individually reasonable actions, and it confers no real accountability unless the approver genuinely had the information to decide otherwise.
Glossary
- Human-in-the-loop
- A design in which a person’s decision is required at defined points within an otherwise automated process.
- Consequence class
- A categorisation of an action by what happens if it is wrong, used to decide gate placement.
- Approval request
- The structured payload presented to a human, containing the elements needed to decide.
- Approver capacity
- The number of meaningful decisions a person can make per day before quality degrades.
- Expiry
- The point at which an unanswered approval escalates or cancels rather than continuing to wait.
- Escalation target
- The named alternative decision-maker for an expired approval.
- Rubber-stamping
- Approval behaviour that satisfies a control without exercising judgement.
- Transform outcome
- Modifying an action so it becomes safe automatically, removing the need for approval.
- Pre-approval
- A standing authorisation bounded by ceiling, expiry and volume.
- Rejection reason
- The recorded explanation for a refused approval, and the most useful improvement signal available.
Standards and entities referenced
Every named framework on this page resolves to a public definition. If you are checking our claims, start here rather than with us.
Sources and further reading
Primary specifications and standards this article relies on. Where a claim is our own operating judgement rather than something a standard states, the text says so.
- 01 · NISTNIST SP 800-63 — Digital Identity Guidelines ↗Assurance levels behind step-up authentication and re-authentication decisions.
- 02 · COSOCOSO Internal Control — Integrated Framework ↗The control framework auditors map financial process evidence against.
- 03 · ISACACOBIT 2019 Framework ↗Governance and management objectives, including segregation of duties.
- 04 · U.S. SECSarbanes-Oxley Act — Section 404 ↗Where segregation of duties becomes an externally audited control.
- 05 · Object Management GroupBPMN 2.0 specification ↗The modelling standard business process orchestration vocabulary comes from.
- 06 · NISTNIST — AI Agent Standards Initiative ↗Identity, authorization, auditing and non-repudiation framed as prerequisites for autonomous agents.
- 07 · OWASP GenAI Security ProjectOWASP Agentic AI — Threats and Mitigations ↗Threat taxonomy specific to tool-using agents rather than to chat completions.
- 08 · BlackLineBlackLine — Agentic Financial Operations ↗Market reference: the phrase ‘Agentic Financial Operations’ and the governance framing around it.
Last reviewed 2 September 2026 by Mark Alex. External links open in a new tab; we do not control their content.
Cite this article
Alex, M. (2026). Human-in-the-Loop Workflow Automation: Designing the Approval That Works. Real Biz Digital. https://realbizdigital.net/insights/human-in-the-loop-workflow-automation/
Try the mechanics on a live server
To see a governed tool surface respond before you point an agent at your accounting system — Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run: no signup, no key, 54 tools. Setup is in the reference.
Buy it on the marketplace
BarzelOps is this execution layer, sold as a running product
Forty tools covering capability discovery, workflow planning, preview before execution, run, trace, pause, resume and cancel, approval request and resolution, credential validation and connector health — across accounting, CRM, email, calendar, documents, Slack and storage. Opinionated workflows ship with it: customer onboarding, invoice follow-up, lead-to-invoice, pipeline cleanup, monthly close preparation and weekly operations briefings. The Free tier runs 100 calls a day.
| Plan | Price | Included | Right for |
|---|---|---|---|
| Free | Free | 100 calls/day · 10 core tools: plan, preview, run, trace | Proving one workflow end to end before anyone signs anything |
| Pro | $19/mo | 15,000 calls/mo · 26 tools including approvals and templates | One operator automating their own recurring procedures |
| Team | $49/mo | 50,000 calls/mo · the complete 40-tool surface | An operations team running cross-app workflows under approval |
| Enterprise | $199/mo | Unlimited calls · deployment and connector scope by agreement | Multi-team execution with audit and residency obligations |
Sold on the MCPize marketplace · prices as listed 2 Sep 2026 · the listing is authoritative
The five Barzel servers, and which problem each one is sold for
One estate rarely needs all five. This is the honest mapping, so you buy the layer your problem actually lives in.
| Server | Sold for | Entry price | Where it sits |
|---|---|---|---|
| Barzel Central Gateway | Knowing and governing the estate: inventory, registry, routing, risk scoring, approvals, evidence | Free, then $10–$149/mo | Control plane — decides what may be reached, and by whom |
| BarzelVault | Stopping a specific dangerous action before it executes, with proof afterwards | $199–$3,999/mo | Decision point — evaluates the individual call before execution |
| BarzelOps | Running real business workflows across HubSpot, Xero, Gmail, Drive and Slack under approval | Free, then $19–$199/mo | Execution layer — does the work the policy allowed |
| Barzel FinOps Atlas | Attributing AI spend to agents, tools and outcomes, then forecasting and capping it | Free, then $29–$799/mo | Economics layer — what the estate costs per outcome |
| Barzel Scripture Intelligence | A free, credential-free public MCP server to test clients and inspect real protocol traffic | Free, unmetered, no signup | Reference implementation — safe place to learn the protocol |
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.