Human-in-the-loop is not a button

Almost every agent proposal includes the phrase "human in the loop". It reassures committees, satisfies policy templates and usually appears on the architecture diagram as a small figure next to an approve button. The phrase is so common that it has stopped carrying information.

The question is not whether a person is involved. It is where they are involved, what they see when they get there, whether they can genuinely say no, and whether they have time to think before saying yes. A person who approves forty agent actions an hour from a queue that shows only a summary is present. They are not in control.

Our earlier article The human in the loop must show their work dealt with independent verification and the record a reviewer must leave. This part deals with the step before that: deciding where a person should intervene at all. We continue with Ubuntu Municipal Services, the fictional municipal entity in this series.

Four conditions for real intervention

Intervention only works when four things are true at the same time.

1. The right point. The person is placed before the action that matters, not after it has taken effect, unless the action is cheap to undo.
2. The evidence. The person sees what the agent saw: the sources, the tool results, the rule it applied and any uncertainty, not just its conclusion.
3. The authority. The person can reject, change or escalate the action, and doing so is a normal outcome rather than an exception that needs justifying.
4. The time. The volume and the interface allow a genuine look. If approval is faster than reading, it is ceremony.

Remove any one and the human becomes a liability shield: someone to blame when the agent is wrong, without the means to prevent it.

Where should a person step in?

Apply a short test to each action the agent can take, not to the agent as a whole.

Can the action be undone quickly and cheaply? If not, a person approves before it happens. At Ubuntu, issuing a work order sends a crew and a vehicle out of the scheduled round, and once they are dispatched the cost cannot be recovered, so a supervisor approves it. A single re-collection booking, by contrast, can be cancelled within the day at no cost, which is why Part 4 allowed the agent to make it.

Is the action above an impact threshold? Thresholds can be about money, the number of people affected, or legal consequence. A re-collection for one street is below Ubuntu's threshold; a re-routing that affects an entire ward is above it, even though both can technically be reversed.

Is the case novel, disputed or outside policy? If so, the agent escalates to an official with the case file. The resident who says the truck has missed the street for the third week, and that they have already complained twice, is not a routine case.

Otherwise, act, then sample and review. Low-impact, reversible, routine actions go ahead, and a person reviews a sample afterwards. This is where most of Ubuntu's agent activity sits, and it is where reviewers find the patterns that should change the rules.

The test produces three kinds of human involvement: approval before the action, escalation of the case, and review after the fact. Each needs a different interface and a different staffing plan.

Designing the approval screen

An approval screen should let a supervisor decide in under a minute for a typical case, and should make rejection as easy as approval. At Ubuntu, a work-order approval shows:

• the resident's complaint and the earlier complaints on the case;
• the route log entries for that street, with dates and times;
• the agent's proposed action and the rule it applied;
• anything the agent was unsure about, stated plainly; and
• three buttons of equal weight: approve, change and reject with a reason.

What it deliberately does not show is a confidence percentage. A number that looks precise tends to be trusted more than the evidence behind it.

Watching for rubber-stamping

Approval rates tell you whether oversight is real. If supervisors approve 99 per cent of agent proposals in an average of four seconds, either the agent is very good and approval is unnecessary for that action, or nobody is reading. Both conclusions call for a change: move the action to sample-and-review, or fix the interface and the workload.

Ubuntu tracks approval rate, time to decide, and the share of approved actions later found to be wrong in sampling. These are illustrative measures, but the principle is general: measure the oversight, not just the agent. Our article Human-in-the-loop is not a bottleneck explains how reviewer corrections become the data that improves the agent.

When the person and the agent disagree

Disagreement is information. When a supervisor rejects a proposal, the reason should be captured in a structured way, so that it can be counted and used to improve rules, prompts or evaluation sets. When an official overrules the agent on an escalated case, the outcome should feed back into the scenarios the agent is tested against.

Accountability must also be clear. The person who approves is accountable for the decision to approve on the evidence they were shown. The team that designed the agent is accountable for what that evidence contained. If an approval screen omits the fact that would have changed the decision, the failure belongs to the design, not the approver.

Administrative fairness

For public bodies in South Africa, human involvement also has a legal dimension. Decisions that adversely affect people may need reasons and a route to challenge them. A process in which an official signs whatever the system proposes, without the information or time to consider it, is unlikely to satisfy that expectation. Our article Human-in-the-loop is not administrative justice, part of the Rewiring Government for the AI-Native Era series, looks at this in detail. This is general information, not legal advice.

Questions to ask

1. For each agent action, is the person before it, after it, or not involved, and why?
2. What exactly does the reviewer see? Show me the screen.
3. Can the reviewer change or reject the action as easily as approving it?
4. How many decisions per hour does each reviewer handle?
5. What are the approval rate and decision time, and what do they tell you?
6. Where do rejection reasons go?

Key points

• Oversight needs the right point, the evidence, the authority and the time.
• Decide intervention per action, using reversibility, impact and novelty.
• Measure approval rates and decision times to detect rubber-stamping.
• Disagreements are data; capture them and feed them back.

Next: Part 7, Multi-agent is an organisational choice, not a feature count. All parts are on the series page.

How CloudNala can help

CloudNala designs human intervention points for agent systems. We classify each action by reversibility, impact and novelty, design approval and escalation screens around the evidence a reviewer needs, and set up the measures that show whether oversight is working.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Book an Agent Due-Diligence Review or write to us at consult@cloudnala.co.za