Human-in-the-Loop AI Agents: Designing Approval Workflows

Human-in-the-loop AI agents are agents that pause at the risky moments and wait for a person to approve, reject, or cancel before acting. In Deelo, any action you mark allow-with-approval stops the run and queues the proposed action for a human, and a hard high-risk floor forces this pause on the most dangerous actions no matter how the agent is configured. Designing that workflow well -- deciding what pauses, who approves, and how fast -- is what lets you give an agent real responsibility without giving up control. This guide shows how.

Human-in-the-loop is a design choice, not a limitation. It means the agent does the work up to the point of consequence, then hands a decision to a person and waits. The agent has already done the thinking -- read the context, drafted the action, assembled the details -- so the human isn't doing the task; they're saying yes or no to a finished proposal. That distinction is the whole value. You get the agent's speed on the 95% that's mechanical and a person's judgment on the 5% that carries risk.

The alternative extremes both fail. Fully manual wastes the agent. Fully autonomous on risky actions is how you end up explaining a wrong refund to a customer. Human-in-the-loop is the middle that actually ships.

When a Deelo agent pauses for approval, the run doesn't die -- it holds. The proposed action sits in a pending state with everything a reviewer needs to judge it, and the person handling it has three choices.

You decide what pauses. In the permission grid, any verb on any tool can be set to allow-with-approval instead of a free allow, and the destructive-action policy has a confirm setting that makes the agent pause before anything destructive. Setting these well is a balancing act. Pause too little and you've built an autonomous agent wearing a human-in-the-loop costume. Pause too much and the approval queue becomes a full-time job nobody does, so approvals pile up and the agent stalls.

The rule that works: pause on anything externally visible, irreversible, or expensive, and let everything internal and recoverable run free. An agent updating its own notes shouldn't ask permission. An agent about to email a customer should.

Some pauses you don't have to remember to design, because Deelo forces them. The high-risk floor is a set of actions that always require human approval regardless of the agent's autonomy level or destructive-action policy -- the ones where a mistake is irreversible or expensive:

This floor is the safety net under your approval design. Even if you misconfigure a policy or grant too much autonomy in a hurry, the actions that could really hurt still stop for a person. You're designing the approvals that fit your workflow on top of a floor the builder won't let you accidentally remove.

The failure mode of human-in-the-loop isn't the agent; it's the queue. If approving an agent's work is annoying, people batch it to end-of-day, the agent's runs stall, and the time you saved evaporates into a review backlog. A workflow people actually keep up with follows a few rules:

Public-facing agents raise a sharp question: if a high-risk action needs human approval, and the person talking to the agent is an anonymous website visitor or caller, who approves? Never them. Deelo handles this with defer-and-report. When an outside user asks for something that crosses the floor -- 'refund my order,' 'cancel my booking,' 'delete my account' -- the agent doesn't ask the stranger to approve it. It does the safe part, gathers the details, and reports the request to your team for a human to decide. A public web agent also defaults to read-only until you deliberately open it up. So the worst a bad actor can do is create a task in your queue, never trigger the action itself -- which is exactly what makes a shareable agent safe to hand to strangers.

Human-in-the-loop and autonomy are two views of the same dial. The autonomy level sets the default -- how often the agent stops -- and your approval design decides what those stops are. Both sit inside the larger deployment lifecycle, and both depend on being able to see what the agent did, which is where monitoring comes in. Get the loop right and you stop thinking of the agent as a risk to contain and start thinking of it as a very fast colleague who checks in at the right moments.