Delegating to a Human as If They Were an Agent

In a system where an agent delegates subtasks, a human is another worker with an unusual latency profile. Treating them that way — same interface, same contract, same result shape — turns human involvement from a special case that breaks the flow into an ordinary part of the design.

The uniform interface

A delegation is a task specification and a result. Whether a model or a person produces the result shouldn't change the calling code.

delegate(task: "Verify these three invoice totals against the ledger",
         context: {...}, deadline: "4h", assignee: "agent" | "human")

→ {status: "done"|"failed"|"needs_input",
   result: {...},
   completed_by: "human:u_88",
   notes: "third invoice has an FX discrepancy — flagged, not resolved"}

The supervisor's aggregation, error handling, and reporting work identically either way. That uniformity is the point: it means routing a task to a human is a configuration decision rather than a rewrite.

What's genuinely different about the human worker

Latency is hours, not seconds. Any run that can delegate to a person must be suspendable — durable state, an expiry, a defined timeout behavior. This is the requirement that drives everything else, and it's why systems without resumability end up handling humans as an awkward special case.

They need context, not just a task. A model gets a task string and works from it. A person needs to know why this matters, what's already been established, what decision hangs on it, and what "done" looks like. → The gathered and attempted fields that make agent escalations useful are essential here.

They'll answer a different question than the one asked. People correct the premise, which is one of the main reasons to involve them. The result shape needs room for it — a notes field, and a way to return "you asked the wrong thing" as a legitimate outcome rather than a parse failure.

Their availability varies. Weekends, time zones, holidays. A deadline of four hours means something different at 4pm Friday, and a system that doesn't model this produces expiries that are nobody's fault.

Designing the task for a person

The specification that works for a model is usually wrong for a human:

• Ask for a decision, not an analysis. "Approve or reject this refund; here's the evidence" gets answered. "Review this refund" invites an open-ended investigation nobody has time for.
• Include what the agent would have done. A person confirming or overriding a proposal is far faster than one deciding from scratch — and the difference between the two answers is a metric worth collecting.
• Bound the effort explicitly. "This should take about two minutes" sets expectations and surfaces mis-scoped delegations when it turns out to take twenty.
• Make it actionable where it arrives. A task in the tool someone already has open gets done; one requiring a login to a separate system waits.

✅ Which tasks to route to a person

• Judgment the agent lacks context for — organizational, political, relationship-dependent.
• Accountability requirements — someone must own the decision.
• Ground truth the agent can't reach — did the customer actually say that on the call?
• Low-confidence, high-consequence cases, routed on the agent's own confidence signal.
• Sampling for quality, where a fraction of routine tasks goes to a human as an ongoing check.

That last one is underused and cheap: routing a small random sample of completed work to a person gives you continuous ground truth about agent quality, which no eval suite provides.

⚠️ Not a dumping ground

The failure mode is delegating everything ambiguous, producing a queue nobody can keep up with — the approval-fatigue problem in a different costume.

Instrument it the same way: what fraction of human results differ from what the agent proposed? Near zero means you're routing things the agent could have handled. And watch queue age, not just depth, because that's what determines whether the system feels responsive.

The takeaway

A human is a worker with a slow, variable response time and much better judgment about context. Give them the same delegation interface, with context and a proposed answer rather than a bare question, a realistic deadline that understands weekends, and room to correct the premise. Then measure how often they disagree — that number tells you whether the routing is earning its cost, in either direction.