Routing a Request to a Person or a Model: A Decision Rule

A cutoff is only as good as the score it slices. You need a signal that produces a number per request, computes before a handler is chosen, and separates the cases a cheap handler answers correctly from the cases it gets wrong. There are five families worth trying, and they fail in different ways.

Calibration matters more than raw confidence. Neural networks are often overconfident, so a score of 0.9 does not mean nine in ten correct, and accuracy can drop on new inputs while confidence stays high the Appen HITL guide. Before you trust any score, bucket your labeled sample by score and plot accuracy per bucket. If the 0.9 bucket is only 60 percent correct, the score is a weak separator and you need a different signal, or a judge, or both.

A judge model is often the highest-leverage addition. Use a stronger model to grade the cheap answer against a rubric and route on that grade rather than on the cheap model's self-report. This is the "AI-first, human correction" pattern: automation produces a draft, something checks it, and only the disagreements reach a person the Roboflow HITL patterns. When you need several model families behind one endpoint to build this chain, Quanta Inference gives you text, image, video, audio and embedding models through one OpenAI-compatible API key, priced in US dollars Quanta Inference.

Do not pick the threshold by feel. Pull a sample of past requests that a person has already resolved or graded, record the score your signal would have produced for each, and then simulate. The steps are mechanical:

1. Collect 500 to 2,000 past requests with a label for whether the cheap handler's answer was acceptable.
2. Compute the signal score for every request, as it would run in production, before any handler acts.
3. Sort by score and, for each candidate cutoff, count how many requests fall above it (handled automatically) and how many fall below (escalated).
4. For each cutoff, compute expected misroutes: the incorrect answers above the line plus the extra cost of sending correct answers below it.
5. Convert both to dollars or minutes using your real unit costs, add them, and pick the minimum.

A worked example makes the trade-off concrete. Suppose 1,000 requests, a small model that costs 0.1 cents per call, and a person who costs 60 cents per review. A wrong automated answer on this task costs 2 dollars in rework and goodwill. Sweep the cutoff and you get a table like this:

The correct move is the 0.50 cutoff, because a person costs 600 times a model call and a mistake costs only 20 times one. Lower the cost of a mistake or raise the cost of a review and the optimum slides the other way. That sensitivity is the point: the threshold is an economic choice, not a safety preference. Rerun the sweep whenever review cost, mistake cost or traffic mix changes.

Two refinements tighten the result. First, add the large model as a middle stage and sweep two cutoffs at once: a lower bound below which the small model is not trusted, and an upper bound below which the large model is not trusted. Second, reserve a band at the top of the small model's range for spot checks, so you can detect drift in the score without routing the whole band to people.

Some requests should never be routed by score at all. A human is the correct first handler when the request needs authority a model cannot hold: approving a refund above a limit, signing off a medical or legal statement, or taking an irreversible action. The HITL literature is blunt on this: when agents can update records, send messages or trigger workflows, escalation paths must exist before the action happens the Databricks HITL overview.

Put these cases on a hard rule, not a threshold. A short allowlist of intents, value limits or regulated categories gets checked before scoring, and anything that matches goes to a person regardless of confidence. Regulation pushes in the same direction: Article 14 of the EU AI Act requires high-risk systems to be designed for effective human oversight, and Article 12 requires event logging the Appen HITL guide. A score cutoff will not satisfy an auditor who asks how oversight is guaranteed.

The distinction between human in the loop and human on the loop is useful here. In the loop means a person approves each routed item before it takes effect; on the loop means a person supervises aggregate behavior and can intervene by exception the Appen HITL guide. High-stakes, low-volume decisions belong in the loop. High-volume decisions with low individual stakes usually belong on the loop, with dashboards and a kill switch rather than per-item review.

A threshold you cannot observe is a threshold you cannot maintain. Every routing decision should emit a trace with the score, the handler chosen, the reason, and the outcome. OpenTelemetry's trace model fits this well: a span is a unit of work with a parent, start and end times, attributes and events, and a trace ties the spans of one request together across services the OpenTelemetry traces guide. Your router span becomes the parent of the model call and the review task.

The GenAI semantic conventions standardize what to record: the model called, input and output token counts, and finish reasons, with prompt and completion content captured only when you opt in the OpenTelemetry GenAI observability post. Add your own attributes for the routing score, the candidate handlers, the chosen handler and the rule that fired. Attributes are the cheapest place to put this data, and the more you attach to the routing span, the easier it is to answer which requests went wrong and why the Honeycomb instrumentation guide.

Logs and traces play different roles. A log records one event in isolation; a trace reconstructs how one request moved through retrieval, model calls, tool calls and post-processing the Braintrust tracing guide. Routing failures are path problems, so traces are the primary tool and logs fill in step detail. Capture the score on the router span, and you can query "requests where score was above cutoff and the outcome was marked wrong" directly.

Track four numbers weekly: volume by handler, misroute rate above the cutoff, review backlog, and cost per resolved request. Volume by handler tells you whether the split is drifting. Misroute rate is the quality signal the cutoff was supposed to control. Backlog tells you when review capacity, not the threshold, is the binding constraint. Cost per resolved request is the number the whole exercise exists to reduce.

Where the score is ambiguous, neither a small model nor a person is clearly right, and a large model earns its cost. A request scored just below the human cutoff and just above the small model's range should go to the large model first, with a person called in only if the large model's judge score also falls short. This middle band is where most of your cost savings hide, because each request moved from person to large model frees review capacity without dropping the quality bar.

Feedback from reviews must feed back into the system, or the threshold decays. The defining feature of a real HITL system is that corrections flow into training data, evaluation sets or routing thresholds, so the model needs less help over time the Appen HITL guide. Practically, label every review outcome, add the graded cases to your evaluation set, and rerun the cutoff sweep on a schedule. If your misroute rate is climbing while review volume stays flat, the score has gone stale.

Rewriting a routing table as code keeps the rules auditable. A small configuration object that names the hard rules, the two cutoffs and the middle-band behavior is easier to review than logic scattered through the application:

routing = {
    "hard_to_human": ["refund_over_limit", "legal_commitment", "account_closure"],
    "small_model_max": 0.50,   # above this, small model answers
    "large_model_max": 0.82,   # above this, large model answers
    "judge_floor": 0.65,       # below this, escalate to a person
}

def route(request, score, judge_score=None):
    if request.intent in routing["hard_to_human"]:
        return "human"
    if score >= routing["large_model_max"]:
        return "small_model"
    if score >= routing["small_model_max"]:
        if judge_score is not None and judge_score >= routing["judge_floor"]:
            return "large_model"
        return "human"
    return "large_model"

The numbers in the example are placeholders; your sweep sets them. What matters is that the decision is explicit, emits a trace attribute, and can be changed without touching the model calls.

If the reviewer side of this loop is where your team is thin, a Quanta expert for your line of business can own the review rubric and the cutoff sweep with you, and the skill library behind every expert is installable into your coding agent if you want the work done in your own repository Quanta Skills. Build the evaluation set first; the right owner becomes obvious once you can see the misroute rate.