Human in the loop automation means you decide how much of a process runs on its own and where a person steps in: with Floowed that's a setting per operation (decide every case, only the routine ones, or none), exceptions go to the right person with the reason attached instead of a guess, and every case keeps a full record so you can move the line as trust grows.
Most writing on the subject treats it as a compromise: automation you don't quite trust, with a person bolted on to catch its mistakes. That framing produces the wrong design. It puts one review queue at the end of the process, fills it with everything the machine was unsure of, and asks one tired person to clear it. The machine gets no better, the person gets no faster, and nobody can say afterwards why a given case went the way it did.
The better framing is a line. On one side, cases the system settles on its own. On the other, cases a person decides. Where you draw that line is a business decision, it should differ by operation, and it should move.
Full automation versus manual is the wrong question
Operations leaders tend to get asked a binary question: can this be automated or not? The honest answer for almost any real process is "parts of it, for some cases, once we've seen it work". A supplier with a clean registry record, current insurance and bank details that match is routine. A supplier whose bank letter names a different entity is not. Both are supplier onboarding. Treating them the same, in either direction, is the mistake.
There are three separate things people mean by "human in the loop", and they are worth pulling apart:
- Judgment. A person makes a call the rules don't cover, or signs off on one they do. This is the loop in the proper sense.
- Waiting. The case is missing something: a document, a sign-off, an answer from another team. A person isn't needed to judge anything. Someone just hasn't replied.
- Checking the machine. A person confirms what the system read or concluded, because the reading might be wrong.
Most review queues mix all three, which is why they grow. Waiting shouldn't be in a review queue at all; it should be chased. Checking the machine should shrink over time as you see where it's reliable. Only judgment belongs to a person by design, and even then, only for the cases your rules say need it.
The setting: every case, only the routine ones, or none
In Floowed, how much it decides on its own is a setting on each operation, not a property of the product. There are three positions.
| Setting | What Floowed does | What a person does | When to use it |
|---|---|---|---|
| None | Gathers, reads, chases and checks every case against your rules, then comes back with a recommendation and the reasons | Confirms or overrides every decision | A new operation, a new rule set, or a decision where policy requires a person to sign |
| Only the routine ones | Settles cases that pass every rule cleanly; sends the rest to a named person with the specific reason | Decides the exceptions | Once you've seen its recommendations agree with your team's decisions on the routine cases |
| Every case | Decides and acts on every case within your rules; raises only what the rules themselves flag | Owns the rules and reviews the record | High-volume, well-understood decisions where the rules capture the policy fully |
Even on "none", almost all the work is done. The gathering, the reading, the chasing and the checking all run. What a person receives isn't a pile of documents; it's a case with the evidence assembled, every rule evaluated, and a recommendation with the reasons behind it. The person's job shrinks to the part only a person should do.
The setting is per operation, so it can be different for supplier onboarding and for invoice approval in the same company, and it can sit at "none" for a regulated decision indefinitely while the routine operations move along.
Moving the line as trust grows
Trust in an automated decision shouldn't be a leap. It should be earned on evidence you can look at, and three things make that possible.
Watch it agree. Start on "none". Every recommendation Floowed makes is recorded next to the decision your team actually took. After enough cases you can see exactly where the two agree and where they don't, by rule and by case type, not as an overall impression.
Replay before you change. When you tighten a threshold or add a rule, you can replay the new version on past cases and see what would have changed before it goes live. The rules run in a deterministic policy engine, so the same inputs on the same version give the same outcome, and the replay is a fair preview of the change.
Move one class of case at a time. "Only the routine ones" is defined by your rules, so you choose what routine means. Start with the narrowest definition (every rule passed, every document read cleanly, nothing chased) and widen it as the record shows it's safe.
The line can move back, too. A new supplier category, a regulatory change, an unfamiliar document type: pull the setting back to "none" for that operation until you've seen it handle the new ground.
Exceptions go to the right person, not to a queue
The second design mistake in most human-in-the-loop systems is the generic exception queue. Something fails, it lands in a list, and whoever is free picks it up and works out what's wrong.
In Floowed an exception carries its reason and goes to the person who can resolve it. A bank-detail mismatch on a new supplier goes to finance. A price variance on an invoice goes to the budget owner or procurement. A document that can't be read with enough confidence goes to someone who can look at the page. The person gets the case with the evidence and the specific rule that didn't pass, not a notification that something needs attention.
And much of what lands in other systems' exception queues never reaches a person in Floowed, because it isn't an exception at all. A missing certificate, an unapproved purchase order, a customer who hasn't sent the second page: those are chased. Floowed asks whoever owes the answer (a person, a system or an agent), asks again if they don't reply, and the case picks up where it left off when the answer lands. Floowed runs these as long-running asynchronous cases, so a case can wait three weeks for a reply without anyone keeping a tracker. Portal tools instead ask the customer to log in and upload it; Floowed vs Moxo compares the two approaches.
That separation is what keeps the human loop small. People see judgment calls, not waiting. An AI assistant in Slack works the other way round: it's capable, but it improvises each job and a person approves each action, as we set out in Floowed vs Viktor.
Every case keeps a full record
A human in the loop is only as defensible as the record around it. For every case, Floowed keeps what was read and from where, who was asked for what and when they answered, which rule and which version of it decided the case, whether a person confirmed or overrode it and why, and what was written to which system.
That record does three jobs. It answers the auditor who asks, a year later, why a case was approved. It tells you where to move the line, because agreement between recommendations and human decisions is visible case by case. And it shows where your rules need work: when people keep overriding the same rule, the rule is wrong, not the people.
Where the machine can be wrong, and where it can't
It's worth being precise about what is and isn't deterministic, because it tells you where the loop belongs.
The rules are deterministic. Given the same inputs and the same version, the policy engine reaches the same outcome every time. A person doesn't need to re-check that a rule was applied correctly.
Reading and research are not deterministic. Extracting values from a scanned document, researching a company, interpreting a free-text reply: these are model-driven, and models can be wrong. Floowed's runtime is model-agnostic, routing between open-weight and frontier models on cost, latency and data residency, and it cross-checks what it reads against every other source rather than trusting a single extraction. But checking the machine belongs here, on the inputs, which is why the loop should be placed at the reading and the judgment, not at the arithmetic.
The same logic applies when AI agents are doing the work. Agents do the tasks. Floowed runs the process: it tells the agent, the person or the system what's needed next on each case, and it holds the line on what gets decided without a person. An assistant can be a step inside a Floowed operation; the human in the loop still sits where you put them.
Documents: one example of where the loop belongs
Documents are the most common reason a person gets pulled into an automated process, so they make a good worked example.
Thresholds are per field, not global. A single confidence threshold across every field is the classic mistake. Low confidence on a document's type may be acceptable; the same confidence on an account holder's name or an amount is not. Set thresholds by field and by what the field feeds into, and revisit them as the record shows where reading is reliable.
Real documents are messy. They arrive handwritten, photographed at an angle, scanned at low resolution, or stamped over. Floowed reads them in whatever state they arrive. When a value can't be read with confidence, the case goes to a person with the page and the field highlighted, not with the whole file.
Cross-checks beat confidence. A confident extraction can still be wrong about the world. An ID that doesn't match the selfie, an address that doesn't match the utility bill, a company name on a tax form that doesn't match the registry: each should route to a person even when the reading itself was confident, because the loop is about the case, not the OCR.
New formats are new ground. A bank statement layout, payslip or tax form the system hasn't seen before is exactly where to pull the setting back to "none" until the record shows it's reading correctly.
In lending: an example with high stakes
Lenders processing large volumes of applicant documents (applications, bank statements, credit reports, appraisals) ask for two things at once: high accuracy and the ability for a person to verify. Human in the loop automation is how you get both.
In mortgage and secured lending, it is common for 10 to 15% of applications to go to underwriter review: the slice where income, collateral or identity evidence doesn't reconcile cleanly. In unsecured and SME credit, routine applications can clear on their own once the data passes the credit policy, borderline and thin-file applications go to the credit and risk team, and applications with fraud indicators go to specialist review. Many lenders also require a person to sign off before a decline is final, which is exactly what the "none" and "only the routine ones" settings are for. We cover the lending side in more depth on our lending page.
How to start
- Pick one operation that recurs. Something your team does every week, that crosses a few systems and people: supplier onboarding, invoice approval, a client change request.
- Write down the rules you already apply. They usually live in a procedure document or in one senior person's head. See our explainer on business rules engines for how to structure them.
- Start on "none". Let Floowed gather, read, chase and recommend on every case while your team keeps deciding.
- Read the record. Look at where recommendations and decisions disagree, fix the rules that were wrong, and replay them on past cases.
- Move the line for the routine cases. Then widen what routine means as the evidence supports it.
Set-up is live in minutes: name the operation in Slack, Microsoft Teams or the Floowed Dashboard and Floowed builds it on your systems and your rules, over API, MCP and 400+ integrations. Your systems of record stay where they are.
Frequently asked questions
What is human in the loop automation?
An automated process where people are deliberately placed at the points that need judgment, rather than removed entirely or kept on every step. Done well, the system does the gathering, reading, checking and chasing, and people decide the cases your rules say need a person.
How is it different from full automation?
Full automation decides every case without a person. Human in the loop automation lets you choose, per operation, whether the system decides every case, only the routine ones, or none, and change that choice as you see how it performs.
Where should the human sit in an AI process?
At judgment calls and at inputs the machine might have read wrongly: unusual documents, cross-checks that don't reconcile, decisions your policy says a person must sign. Not at the arithmetic of applying rules, which a deterministic policy engine does the same way every time, and not at waiting for missing information, which should be chased.
Doesn't a human in the loop slow everything down?
Only if everything goes to the human. When routine cases settle on their own, waiting is chased rather than queued, and exceptions arrive with the evidence and the reason, the person sees fewer cases and spends less time on each.
How is this different from Zapier or n8n with an approval step?
A trigger-based tool can pause for an approval, but it runs a step, not a case: it doesn't gather the evidence, read the documents, chase what's missing or record which rule decided. Our comparisons of Zapier alternatives, n8n alternatives and Relay.app alternatives go into where that line falls.
Set the line yourself
Pick an operation, start with a person confirming every case, and move the line when the record says you can. Start free with $80 of credits, no card and no sales call. Start free, or talk to us.