A demo lets the model talk straight to the screen. Production often should not. A human review loop is the path where a person sees the output, changes it or rejects it, and only then does the product send, publish, pay, or file.
This is part of shipping AI past the demo, not a sign the model "is not ready" in the abstract. Some actions are cheap to undo. Some are not. Myrafy's AI work treats the loop as a product surface with a queue, an SLA, and an audit row — next to evals and prompt injection as a release bar.
When a Person Must See the Output
Ask what happens if the model is wrong once, in front of a customer or a regulator.
| If the worst case is… | Review |
|---|---|
| A draft the user will edit anyway | Optional; show the draft in place |
| An email or ticket reply sent as the company | Review before send, at least for the first release |
| Money, access, or a filing | A person approves; the model only proposes |
| A public post or a policy answer | Review until the eval set says otherwise, in writing |
| A summary nobody acts on | Log it; do not staff a queue you will ignore |
"Human in the loop" as a slide is not a loop. A loop has a queue, a person whose job includes the queue, and a state the customer can understand (draft, waiting, sent).
Workplace software is a clear case: a model can draft a handover note or cluster tickets; a manager still approves leave or publishes recognition. That split — draft versus decide — is the same one we use in OrgPlaza for human decisions, and the same one an assistant feature needs when the action is hard to undo.
The Queue Is a Product Surface
Minimum the reviewer can do:
- Read the model output and the inputs it used (the ticket, the clause, the retrieved chunks)
- Edit, approve, or reject with a reason
- See how long the item has waited
- Open the same item twice without sending twice
Do not make the reviewer hunt through logs to see the prompt. If they cannot see why the model said it, they will rubber-stamp or they will skip the tool.
Staffing is a product decision. A queue that needs a lawyer and a queue that needs a support lead are different SLAs, different UIs, and different costs. Put the role in the SOW. "Someone will check it" is how the queue reaches 400 items and the team turns the feature off.
SLA, Audit, and Who May Skip the Loop
Write three numbers:
- Target age — how old an item may get before you page
- Bypass — which roles may send without review, and for which actions
- Retention — how long you keep the draft, the edit, and the reviewer's id
Audit is not a nice-to-have when the output leaves the building. Store the model version, the retrieved ids, the reviewer's decision, and the final text. You will need that the week a customer asks "who said this?"
Bypass is where teams get sloppy. If everyone can skip review, you do not have a loop. If nobody can skip it during an outage, you have a single point of failure. Name the bypass, log it, and review the log. Same idea as a production deploy: exceptions are allowed and visible.
Do not "temporarily" auto-send while you wait for the queue UI. Temporary paths become the incident.
Evals Do Not Go Away
A review loop is not a substitute for an eval set. Reviewers are a sample, they get tired, and they disagree. You still want a gold set in CI for faithfulness, refusals, and the cases that must never pass — the bar in shipping past the demo.
Use the queue as a source of labels:
- Edits and rejects become the next eval rows
- Agreement between two reviewers, on a slice, tells you whether the rubric is real
- If approve-without-edit is 99% and customers still complain, reviewers are clicking through; fix the UI or the incentive, not the model slogan
RAG features need this more, not less. The reviewer should see the citations. If the citations are wrong, the approve button is how you publish a confident mistake.
Injection still applies. A reviewer reading untrusted text is safer than a tool that acts on it, and still not magic: do not let the document authorize the tool. The approve action is your code, under the reviewer's session, not the model's.
FAQ
Will review make the feature too slow? For anything customer-visible and hard to undo, slow is the requirement. If the business needs sub-second send, you are in "auto, with a kill switch and an eval," and you should say that out loud — not pretend a queue exists.
Can we start with review and remove it later? Yes, if you wrote the exit rule: which metric, on which slice, for how long, and who signs. Without that, "later" never comes, or it comes as a quiet config change.
Is this only for generative text? No. A classifier that files a regulatory report, or a ranker that hides a safety case, can need the same queue. The question is blast radius, not whether the model emits prose.
The Bottom Line
Human review loops are for outputs you would not let a new hire send unsupervised. Give the loop a queue, an owner, an SLA, and an audit row. Keep evals. Let the model draft; let a person decide when the cost of being wrong is not a typo.
A chatbot with no owner is not a process. It is a demo that learned your customers' addresses.
Designing an AI feature that still needs a person in the path? See AI and machine learning or get a free estimate.