Human-in-the-loop for AI agents

There’s a failure pattern we see often enough to name. A team builds an agent, wires it to real actions — issue the refund, update the contract, send the outbound email, adjust the credit limit — and lets it run autonomously because autonomy was the whole pitch. It works beautifully in testing. Then one day the agent takes a consequential action on a bad inference, and because nothing sat between the decision and the effect, the effect is already real by the time anyone notices. The postmortem always reaches the same conclusion: this action should never have executed without a human looking at it first.

The overcorrection is just as bad. Spooked teams route everything through human review, which destroys the economics that justified the agent and trains reviewers to click “approve” without reading, because 95% of what crosses their desk is fine. Now you have the cost of an agent, the latency of a human, and the vigilance of neither.

Human-in-the-loop done right is neither extreme. It’s a design discipline: decide which actions need a human, when in the flow the human enters, and what they see when they do — then build the gate before the incident forces you to. This post is that discipline, grounded in what Salesforce actually gives you to build it: escalation topics, Omni-Channel handoff, Flow and Apex approval gates, and the audit trail underneath. It’s the operational half of the governance story we started in agent sprawl is the new shadow IT.

The only question that matters: reversibility × blast radius

Not every agent action deserves a human, and pretending otherwise is how you end up with rubber-stamp reviews. The useful filter is two-dimensional. For any action an agent can take, ask:

How reversible is it? Reading a record is free to undo. Sending an email or moving money is not.
How large is the blast radius? One record, or ten thousand? One customer, or a segment?

Plot your actions on those two axes and the gating strategy falls out of the grid:

	Low blast radius	High blast radius
Reversible	Fully autonomous — answer questions, read records, draft (don’t send)	Autonomous with monitoring — log everything, alert on volume anomalies
Irreversible	Confirm-then-act — a lightweight in-conversation confirmation	Approval gate — a human authorizes before the action executes

The bottom-right cell is the one that needs a real approval gate: irreversible and consequential. Issuing a refund above a threshold. Changing a contract. Deleting records. Sending outbound communication to a large audience. Everything else can run with lighter controls, and being honest about which quadrant an action falls in is what lets you gate the few that matter without smothering the many that don’t. The classic mistake is treating “the agent might be wrong” as the trigger — it’s always possibly wrong; the trigger is whether being wrong is expensive and permanent.

Gate on consequences, not on uncertainty. An agent is always uncertain. The question is whether this particular action, taken wrongly, is something you can’t take back.

This is the same logic behind least privilege in agent security: the defense that holds isn’t catching every bad decision, it’s making sure the actions an agent can take unsupervised are ones you can live with it taking wrongly.

Where the human enters: escalation is the built-in gate

The most common human-in-the-loop pattern in Agentforce is already a first-class feature: escalation. When an agent hits the edge of what it should handle alone — a request outside its topics, a frustrated customer, a decision above its authority — the standard Escalation topic fires and hands the conversation to a human through an Omni-Channel Flow. The flow checks agent availability and routes the conversation to the right queue using your existing skills and capacity rules, and critically, the human picks up with full context: the live transcript, the records the agent already pulled, the actions it attempted, and a sentiment read on the customer.

That context transfer is the difference between escalation that helps and escalation that annoys. A handoff that dumps the customer into a cold queue to re-explain themselves is worse than no agent at all. Design the Escalation topic and its Omni-Channel Flow as deliberately as any customer-facing action:

Define escalation triggers explicitly in the topic instructions — not just “when the customer is angry,” but the concrete conditions: request type outside scope, a monetary threshold crossed, repeated failure to resolve, an explicit ask for a human.
Build and activate the outbound Omni-Channel Flow and attach it in the builder so the routing actually happens.
Carry the context forward so the human inherits the transcript and records rather than starting blind.

Escalation covers the “agent knows it’s out of its depth” case. It does not, by itself, cover the case where the agent is confident and shouldn’t act — that’s a different gate.

Gating an action: route consequence through a Flow, not the LLM

When the risk isn’t “the conversation needs a human” but “this specific action needs sign-off,” the pattern is to make the consequential step a deterministic action that requires approval, rather than something the agent executes directly. The agent decides whether to request the action; your platform decides how and whether it actually happens — the same clean split we argue for in the Flow, Apex, or Agentforce decision guide.

Concretely: instead of giving the agent a “process refund” action that writes to the ledger, give it an action that submits a refund request for approval. The action creates or updates a record and kicks it into a Salesforce Approval Process, which pauses until a human approves. Nothing irreversible happens until that approval lands. Here’s the shape of an invocable Apex action that does exactly that:

public with sharing class SubmitRefundForApproval {
    public class Request {
        @InvocableVariable(required=true) public Id caseId;
        @InvocableVariable(required=true) public Decimal amount;
    }
    public class Result {
        @InvocableVariable public Boolean submitted;
        @InvocableVariable public Id approvalId;
    }

    @InvocableMethod(label='Submit Refund for Approval'
        description='Files a refund request into the approval process; does not disburse.')
    public static List<Result> submit(List<Request> requests) {
        List<Result> results = new List<Result>();
        for (Request req : requests) {
            Refund_Request__c rr = new Refund_Request__c(
                Case__c = req.caseId,
                Amount__c = req.amount,
                Status__c = 'Pending Approval'
            );
            insert as user rr; // user-mode DML enforces the agent user's CRUD/FLS

            Approval.ProcessSubmitRequest psr = new Approval.ProcessSubmitRequest();
            psr.setObjectId(rr.Id);
            psr.setComments('Submitted by agent on case ' + req.caseId);
            Approval.ProcessResult pr = Approval.process(psr);

            Result res = new Result();
            res.submitted = pr.isSuccess();
            res.approvalId = rr.Id;
            results.add(res);
        }
        return results;
    }
}

The agent calls this like any other action, but it can’t disburse a cent — it can only file a request. A human approver, an approval process rule, or a Flow Orchestration step decides the outcome, and the disbursement runs only on approval. This inverts the risk: the LLM’s probabilistic judgment gets you to a proposal, and a deterministic, auditable, permissioned process turns the proposal into an effect. For high-volume or multi-stage sign-off, Flow Orchestration does the same job declaratively with assigned work items and stages, which is often the better fit when the approvers aren’t a single person.

A note on the confirmation quadrant: for irreversible-but-small actions, a full approval process is overkill. The lighter pattern is instructing the agent to confirm in-conversation before acting — “I’m about to cancel order #1234, shall I proceed?” — which catches the honest mistakes without adding a human to the critical path. Reserve the heavyweight approval gate for the high-blast-radius cell.

The reviewer’s interface is the part everyone underbuilds

An approval gate is only as good as what the human sees when they hit it. The recurring failure in production is handing a reviewer a bare record and a yes/no button, which produces exactly the rubber-stamping the gate was meant to prevent. A reviewer who can’t reconstruct why the agent proposed this in fifteen seconds will either approve everything or become the bottleneck that kills the deployment.

So treat the approval payload as a designed artifact. Whatever record or work item the human reviews should carry: what the agent is proposing and the value at stake, the reasoning or trigger that led here, the grounding it used, and a confidence or policy signal. The goal is a decision the reviewer can make correctly fast — because if approvals are slow, the pressure to remove them becomes irresistible, and you’re back to full autonomy by attrition.

And every gate, approval, and override has to be logged. This is where human-in-the-loop meets observability: the audit trail of who approved what, when, and why is both your compliance evidence and your tuning signal. Agentforce’s Command Center and session traces give you the telemetry layer for this — we covered what it does and doesn’t show in the observability deep-dive. If approvals are being rubber-stamped, the data will show it before an auditor does.

When the gate is not optional

Sometimes human oversight isn’t a design choice — it’s the law. The EU AI Act, now phasing in, classifies a range of common B2B agent use cases — decisions in HR, creditworthiness, and certain customer-facing communications — as high-risk, and high-risk systems carry a legal requirement for meaningful human oversight. If your agent touches hiring, lending, or other regulated decisioning, the approval gate isn’t there to make you comfortable; it’s there to keep you compliant, and “the model was confident” is not a defense.

This is also why the Einstein Trust Layer, useful as it is, doesn’t close the loop on its own. It masks PII, checks for toxicity, and logs interactions — real protections we mapped in what the Trust Layer protects and what stays your job — but it does not decide whether an irreversible business action should execute. That judgment is the human’s, and the gate is how you route it to them.

Takeaways

Human-in-the-loop isn’t a slider between “autonomous” and “supervised” — it’s a per-action design decision. Classify every action an agent can take by reversibility and blast radius, and gate only the irreversible, high-consequence ones; let the reversible and low-stakes majority run autonomously so the agent still pays for itself. Use escalation and Omni-Channel handoff when the conversation needs a human, and route consequential actions through a deterministic approval — a Salesforce Approval Process or Flow Orchestration — so the LLM proposes and your platform disposes. Invest in the reviewer’s interface, because a gate that produces rubber-stamps is worse than no gate. Log every decision, both to tune the agent and to prove oversight. And know which of your use cases are legally required to keep a human in the loop before an auditor tells you. This is the architecture that separates the agents that survive production from the ones in the cancellation statistics — designed restraint, not blanket autonomy.

Understanding the basics

What is human-in-the-loop for AI agents?

Human-in-the-loop (HITL) means inserting a person at specific points in an agent’s workflow to review, approve, or override its actions before they take effect. The mature version isn’t reviewing everything — it’s identifying which actions are consequential and hard to reverse, and gating only those, while letting reversible, low-stakes actions run autonomously. Done well, it preserves most of the agent’s efficiency while keeping a human accountable for the decisions that actually carry risk.

How do you add human approval to an Agentforce agent’s actions?

Make the consequential step a deterministic action that requires sign-off rather than one the agent executes directly. Instead of a “process refund” action that writes to the ledger, give the agent an action that submits a refund request into a Salesforce Approval Process or Flow Orchestration, which pauses until a human approves. The agent decides whether to request the action; the platform decides whether it actually happens. For lower-stakes irreversible actions, instruct the agent to confirm in-conversation before proceeding.

Which agent actions need a human and which don’t?

Classify by reversibility and blast radius. Reversible, low-impact actions — answering questions, reading records, drafting content — can run fully autonomously. Irreversible, high-impact actions — moving money above a threshold, changing contracts, deleting records, mass outbound communication — need a real approval gate. The middle ground, irreversible but small, is often served by a lightweight in-conversation confirmation. Gate on consequences, not on the fact that the agent might be wrong, because an agent is always possibly wrong.

Building agents that take real actions and need to do it safely? Talk to us about our Agentforce practice — we design the guardrails and approval gates as part of the build, not after the incident.

Human-in-the-loop for AI agents: designing the approval gate before you need it