Delegate to human: making escalation a first-class capability

Two different things called "human in the loop"

An approval gate is designed in advance. The system knows that posting an invoice over a threshold requires a signature, so the run stops there every time, by policy. That is covered in human-in-the-loop for agentic systems.

Delegation is dynamic. The agent is midway through a case, encounters something outside what it can responsibly resolve, and hands the work to a person. Nothing in the plan predicted this particular case. The question is not whether the agent is allowed to act; it is whether it should.

Systems that implement only the first behave badly in the wild, because the interesting failures are exactly the unplanned ones. An agent with no way to delegate has exactly two options in an ambiguous case: guess, or fail. Both are worse than asking.

Escalation is a tool, not a fallback

Give the agent an actual tool, listed alongside the others, with a schema:

delegate_to_human(
  reason,            # one of a closed set
  summary,           # what the agent was doing
  blocking_question, # what it needs decided
  options,           # candidate answers, if any
  evidence,          # links, record ids, extracted values
  suggested_owner    # role or queue
)

Making it a tool has three effects. The agent can choose it explicitly rather than drifting into an error path. The call is logged like any other, so you can measure it. And the payload is structured, which is what makes the human side fast.

When should an agent delegate?

Do not leave this to the model's judgment alone. Enumerate the reasons, and make them a closed set so they can be counted:

Low confidence on an extraction or classification that drives a consequential step.
Ambiguity: more than one plausible match, and choosing wrong is expensive.
Missing information that no available tool can supply.
Policy edge: the case is near a threshold or outside the documented procedure.
Conflicting sources: two systems disagree about the same fact.
Repeated failure: the same step has failed twice and a third attempt will not help.
Novelty: no skill matches this situation at all.

Each reason should also appear in the evaluation set, with cases that must trigger it. An agent that never delegates is not confident, it is uninstrumented.

What the human receives

The quality of a delegation is judged by how long it takes a person to act on it. A good handoff answers, without any clicking: what is this case, what has already happened, what exactly is being asked, what are the candidate answers, and what happens after I answer.

A bad handoff says "unable to process invoice, please check". The person then repeats the agent's work from scratch, which costs more than if the agent had never started.

Two practical rules. Ask one question per delegation; if two decisions are needed, either ask them together with both sets of options or split into two cases. And offer options rather than an open field wherever the answer is from a known set, because a structured answer can be fed straight back into the run.

The return path

Delegation is only half a mechanism. The run has to survive the wait and resume correctly, which means:

State is persisted, not held in a conversation. The case may wait overnight.
Partial work is not lost. Whatever the agent established before delegating is still valid when the answer arrives.
The answer is recorded as provenance: who decided, when, what they chose, and against what evidence.
There is a timeout. A case that waits three days should re-route or surface on a dashboard, not sit silently.
Nothing half-applied. If the agent had already written something before it got stuck, the delegation says so explicitly.

Routing: who gets asked

"A human" is not an address. Delegations go to a role or a queue with an owner, chosen by reason and by case: a pricing question goes to the category buyer, a compliance flag to the compliance queue. If the system cannot decide, it should have a default queue rather than a default person, so that holidays and departures do not create silent black holes.

Delegation rate is a metric, not a defect

Track it. The number is diagnostic in both directions.

Pattern	Usually means
Rate climbing over weeks	The process changed and the skills did not
Rate near zero	Thresholds too loose; check for wrong answers accepted silently
One reason dominating	A fixable gap: a missing tool, a bad data source, an unclear rule
Same case type every week	A skill waiting to be written

In the first weeks of a live system the delegation rate should be high and falling. Each cluster of delegations tells you what the next skill, tool or threshold change should be, which makes this one of the most useful signals a running agent team produces.

The design principle

An agent that can say "I should not decide this" is more useful than one that always produces an answer, because the second kind forces people to check everything, and checking everything costs more than doing it. Build the escalation path on day one, measure it, and let it shrink as the system learns the work.

Frequently asked questions

How is this different from an approval gate?

An approval gate is a planned stop: the policy says this step always needs a signature. A delegation is unplanned: the agent has met a case it should not resolve on its own. A system needs both, and they have different payloads, different routing and different metrics.

Does delegation slow the process down?

It replaces an invisible wrong answer with a visible short wait. In practice, well-routed delegations with a complete payload are resolved in minutes, and the total cycle time still falls because the cases that used to be re-checked by hand no longer are.

Should the agent try to resolve ambiguity by asking more tools first?

Yes, up to a point. Cheap, safe reads that could resolve the question should be attempted before escalating, and the delegation payload should record what was already tried. Repeating the same failing call is not investigation.