Agents that know when to defer

A single model call with a long prompt is not an architecture. It works until the first request that needs two kinds of expertise, and then it degrades in the least useful way available: confidently, and in prose.

The usual response is to split the work across several agents. That is the right instinct and it introduces a new problem. A system with five agents has more than five failure modes, because most of the failures happen between them rather than inside them.

The seam is the system

When a triage agent hands a request to a billing agent, three things can go wrong that have nothing to do with either agent's quality. The handoff can happen when it should not have. It can fail to happen when it should have. And it can happen without carrying the context that made it necessary.

None of those are model problems. They are routing problems, and they get solved with ordinary engineering rather than a better prompt. The mechanism that works is unglamorous: make every routing decision carry a confidence value, and make every handoff an explicit, logged event rather than an emergent property of the conversation.

Confidence as a first-class value

Every classification an agent makes gets a number attached, and that number is part of the record rather than a debugging aid. A triage agent does not return "refund" — it returns "refund" at 0.94, and the orchestrator decides what 0.94 is worth.

The value of this is not the number itself. It is that a threshold becomes a policy you can state, argue about, and change without touching a prompt. Below 0.6, escalate. Between 0.6 and 0.85, proceed but flag for review. Above 0.85, act. Those boundaries are business decisions, and putting them in configuration rather than in a system prompt means the people who own the decision can see it.

• ●Thresholds live in configuration, not prose, so they can be tuned per tenant.
• ●Every confidence value is logged with the decision it produced, which makes threshold tuning empirical rather than intuitive.
• ●A confidence value that never falls below the threshold is a bug in the classifier, not a sign of a healthy system.

Handoffs are events, not vibes

The second half is making transfers explicit. An agent does not silently become another agent. It emits a marker, and the orchestrator acts on it.

The practical benefit shows up the first time something goes wrong in production. A session log that reads as a sequence of typed events can be replayed, audited, and explained to the customer whose refund was held. A log that reads as a transcript cannot.

$ session.init
› agent: triage           [0.94]
  intent: refund
› HANDOFF: billing
› agent: billing          [0.81]
  status: held
› HANDOFF: human
  reason: amount > $500
› agent.review           pending

Deferring to a human is a feature

The most important handoff target is not another agent. Systems that touch money, identity, or anything irreversible need a path that ends at a person, and that path should be reached deliberately rather than as a fallback when everything else has failed.

In practice this means the escalation rule is often not about confidence at all. An amount over a threshold escalates at any confidence, because the risk is in the action rather than in the classification. A system that only escalates when it is unsure will confidently do the expensive wrong thing.

This is the same shape as human-in-the-loop execution more generally: the model proposes, and something harder-edged decides whether the proposal becomes an action.

What this costs

Explicit orchestration is more code than a single call with a long prompt, and the code is boring. Routing tables, thresholds, event types, replay tooling. None of it demos well.

What it buys is a system whose behaviour can be explained after the fact, tuned without a rewrite, and trusted with operations that have consequences. That is the difference between a demo that impresses and a platform that runs.