How to Add Human Approval to an AI Workflow

As AI agents move from answering questions to actually taking action — sending messages, updating records, processing payments, executing multi-step tasks with real consequences — a question that used to be mostly theoretical has become an operational necessity: when, exactly, should a human step in before something happens? Get the answer wrong in one direction and you've built a system too slow and over-supervised to be worth the automation. Get it wrong in the other direction and you've built something that can quietly cause real damage before anyone notices.

By 2026, this has stopped being an edge-case design question. More than 80% of enterprises are expected to have deployed generative AI-enabled applications this year, and that scale of deployment has forced human-in-the-loop design from an afterthought into a genuine architectural requirement, one that regulators including the EU AI Act and NIST's AI Risk Management Framework now explicitly expect organizations to have addressed.

The three modes, and why they need to coexist

The clearest framing to come out of recent practitioner research splits human involvement into three distinct modes, and the key insight is that a single agent workflow usually needs all three at different points, not just one applied uniformly across everything it does. Human-in-the-loop means the agent prepares an action but a person has to approve it before anything actually executes — appropriate for high-risk, hard-to-reverse actions like a financial disbursement or an external communication. Human-on-the-loop means the agent acts autonomously while a person monitors the results and can intervene after the fact — a reasonable fit for medium-risk work where speed matters and a mistake, if one happens, is recoverable. Full autonomy means the agent acts with no real-time gating at all, reviewed later if at all — appropriate specifically for high-volume, low-risk, easily reversible tasks like categorizing incoming tickets or drafting a first-pass version of routine content.

The mistake most teams make early on is picking one of these modes and applying it to an entire workflow, when a single realistic workflow often needs different oversight levels at different steps. An agent that reads a document, drafts a summary, and then negotiates a vendor contract within the same overall task shouldn't apply the same oversight level to all three actions — the first two are low-risk and reversible, the third is exactly the kind of consequential, hard-to-undo action that warrants a real approval checkpoint before it goes anywhere. The oversight model has to be set per action, based on that action's actual risk and reversibility, not decided once for the whole agent and left uniform regardless of what it's doing at any given moment.

Deciding where the checkpoints actually go

The practical method for figuring out where approval belongs is more concrete than it might sound: map every action an agent can take against a simple question — how hard would this be to reverse if it turned out to be wrong? Actions that are cheap and easy to undo — drafting content that a human will read before it's sent anywhere, tagging or categorizing internal records, searching a knowledge base — are reasonable candidates for full autonomy or after-the-fact monitoring. Actions that are expensive, external-facing, or irreversible — sending a communication outside the organization, deleting data, authorizing a payment, committing to a contractual term — belong squarely in human-in-the-loop territory, where the system pauses and genuinely waits rather than proceeding and hoping for the best.

There's a design detail here that's easy to get wrong and important enough to call out directly: the requirement for approval needs to live in the workflow itself, not inside the agent's own reasoning. If an agent is left to decide for itself whether a given action needs human sign-off, a subtle reasoning error — or a deliberate attempt to manipulate the agent's instructions — can talk it out of a checkpoint that was supposed to be mandatory. A genuinely safe approval gate is enforced structurally, outside the agent's own judgment, not something the agent is simply asked nicely to respect.

What actually makes approval meaningful, not theatrical

Human-in-the-loop design fails in a specific, common way: an organization puts a person nominally "in the loop" without giving them the training, context, or time to actually exercise judgment at that checkpoint, which produces the appearance of oversight without the substance of it. Real oversight requires three things at each decision point: a person with enough context to actually understand what they're approving, genuine authority to reject or modify the action rather than a checkpoint that's effectively rubber-stamped by default, and a documented rationale for the decision that could hold up if it were ever reviewed later. Without those three elements together, a human-in-the-loop checkpoint isn't oversight — it's a liability dressed up as process, satisfying the letter of a governance requirement without providing the actual safeguard the requirement was meant to create.

There's also a practical scaling problem worth addressing directly: asking a human to review every single output an agent produces, line by line, doesn't scale and tends to produce exactly the kind of fatigue that makes people start approving things reflexively rather than actually evaluating them. The more sustainable pattern is reviewing the decision, not the entire execution trace — surfacing the specific judgment call that actually needs a human's input, rather than the full, granular record of everything the agent did to get there. A reviewer given a clear, specific decision to make tends to engage with it seriously. A reviewer buried in a wall of low-level execution detail tends to skim and approve, which defeats the purpose of having a checkpoint there at all.

Logging and auditability aren't optional extras

Every intervention — every approval, every rejection, every modification a human makes at a checkpoint — needs to be logged in a way that can be reconstructed later, not as a bureaucratic afterthought but as a genuine requirement once these systems are handling anything with real regulatory or financial stakes. That audit trail is what turns "a person was technically in the loop" into something a regulator, an internal review, or a post-incident investigation can actually verify. Without it, even a well-designed approval process is difficult to defend after the fact, because there's no record connecting a specific decision to the specific person and rationale behind it.

Why this discipline matters even outside full agent automation

It's worth noting that this same underlying discipline — deciding deliberately where a second, human judgment belongs rather than trusting an AI output uniformly across every use — applies well beyond fully autonomous agent systems executing real-world actions. Anyone using AI for consequential work, even in a much simpler, conversational form, is implicitly making the same risk-tiering decision every time they choose whether to act on an AI-generated answer directly or check it first. A quick internal note probably doesn't need a second look. A claim going into a client deliverable, a technical recommendation, or an analysis someone is about to act on deserves the same kind of deliberate checkpoint that a well-designed agentic workflow would build in structurally — just applied by a person choosing, in the moment, whether this particular output warrants scrutiny before it goes further.

Where Kahlo fits into this

Kahlo isn't an agent execution platform gating real-world actions like payments or external communications — that's a genuinely different problem than the one it's built to solve. But the same underlying principle it's built around — that a high-stakes AI output deserves a deliberate second check before you act on it, rather than being trusted uniformly by default — is exactly what Council and Compare exist to make easy to actually do. Instead of building a formal approval workflow around a single model's answer, Council sends a prompt to several models in parallel and returns one synthesis with any disagreement surfaced explicitly, giving you a built-in second read on exactly the kind of decision that would warrant a human-in-the-loop checkpoint in a fully agentic system — a claim you're about to act on, a technical judgment call, a piece of analysis with real consequences attached.

That's the same risk-tiering logic the more formal HITL research keeps landing on, just applied at the scale an individual or small team actually operates at: not every output needs the same level of scrutiny, but the ones that do deserve a real, deliberate second look rather than a single confident answer taken at face value — and having that second look built into the same workspace as the work itself is what makes it something people actually do, rather than a governance step that gets skipped the moment it adds friction.