Sampling Subagent Instructions: When a Delegation Needs Review

The instinct when agents misbehave is to put a human on every prompt. That fails for two reasons.

The first is volume. Multi-agent research systems multiply token use, and Anthropic's internal evaluation found that a lead agent with supporting subagents outperformed a single-agent setup by more than 90 percent, with the gain tied to spreading reasoning across independent context windows, while multi-agent runs consumed roughly fifteen times more tokens than standard chat interactions (ByteByteGo's analysis of Anthropic's multi-agent research system). Fifteen times the tokens also means many more delegation events, most of them routine. Reviewing all of them converts a fast system into a queue.

The second is attention. A position paper from Hugging Face and Data & Society researchers argues that current agent design actively impedes effective human oversight and that the cognitive capacities for oversight degrade with extended use of automation, so agent development should treat the cognitive requirements of the overseer as a first-class design concern (AI Agents Push Humans Out of the Loop). A reviewer who approves two hundred low-stakes delegations an hour is not providing oversight. They are providing rubber stamps, and the habit carries over to the one delegation that mattered.

The decision rule that follows: spend human attention where the expected cost of an unreviewed mistake exceeds the cost of the review itself. Review cost is roughly constant per delegation. Expected loss varies by orders of magnitude. So you need a score that estimates expected loss from data you already have.

Rank tools by the worst plausible outcome of a wrong call, not by how often they are called. The progression is usually read, then write, then delete, then network, then payment or other irreversible money movement.

This is the same logic Microsoft applies at the architecture level: a multi-agent split is justified when regulations or policies mandate data isolation, because a least-privilege design "limits the blast radius of security incidents by containing breaches within individual agent boundaries" (Microsoft Cloud Adoption Framework). You can reuse the containment argument as a review trigger: if the tool boundary was drawn to contain damage, the delegation that crosses it deserves a second reader.

A scoring scale that works in practice:

Two details that are easy to miss. First, score the combination, not the single most dangerous tool: an agent with read access plus network send can exfiltrate, and an agent with write plus delete can destroy. Second, tool scoring should be a property of the tool definition that the orchestrator passes to the worker, so the score is computed, not argued, at delegation time.

The audit side has an equivalent argument: a tool trace proves what function was called, while an authorization record proves whether the action was permitted under the policy in force, for that agent, acting for that user, against that resource, and it lists the approval record as part of the authorization evidence (Permit's guide to AI agent audit trails). If your delegation record can hold a policy version and an approval id, the reviewer's verdict slots into the same envelope.

Cost is the trigger teams get wrong most often, because they look at spend after the fact. Put a budget on each delegation when the orchestrator creates it, then treat the budget as a review input.

Some numbers to anchor the reasoning. In Anthropic's research system, multi-agent runs used about fifteen times the tokens of chat interactions, which the analysis says makes the approach best suited to tasks where the value of the outcome outweighs the expense (ByteByteGo). On the workflow side, a practitioner survey of production patterns reports that orchestrator-worker designs cut costs 40 to 60 percent by using a capable model for the orchestrator and cheaper task-specific models for workers, and that workflows costing fifty cents in testing can reach very large monthly figures at high execution volume because the orchestrator makes additional model calls for decomposition and aggregation on top of every worker call (Beam AI's production patterns writeup).

The decision rule: set the review threshold in absolute currency, not tokens, because currency is what the budget owner understands. A simple version used by several teams is three tiers.

• Under the tier-one cap: no review, sample only.
• Between tier one and tier two: review if the delegation also scores 3 or higher on tools or is customer-facing.
• Above tier two: always review, and require the reviewer to state a ceiling.

Worked example. A lead agent decomposes a market-research request into eight worker subtasks. Seven are search-and-read tasks with a small cap each. One is a "build the comparison dataset" task with a large cap and write access to an internal table. The seven go to sampling. The one triggers on both budget and tools, and gets a reader before it starts. That is one review for eight delegations, and it lands on the delegation that could both cost the most and damage the most.

This trigger asks a different question from the others: not what the subagent is allowed to do, but who reads what it produces. A subagent drafting an internal scratch summary is low stakes. The same subagent drafting the reply that will be sent to a customer under the company's name is high stakes.

Two reasons to treat customer-facing output separately. First, the reputational and legal cost does not scale with spend: a cheap run can produce an expensive problem. Second, the failure modes are different, because phrasing, omission and tone are graded by humans who are not your users. The industry examples are well known and the writeups keep citing them, including a tribunal holding an airline liable for incorrect fare information given by its chatbot (Elementum's summary of human-in-the-loop practice).

The operational rule is a labeling requirement, not a scoring debate: every subagent's expected output field must say where the output goes. If the answer is "external," the delegation is reviewed. If the output reaches an internal system that later feeds an external surface, mark it indirect and review on a schedule or on change of template.

This is where the human-in-the-loop vocabulary is useful. Financial services practice distinguishes humans in the loop during execution, humans on the loop supervising after completion, and humans out of the loop for predetermined low-risk scenarios (Elementum). Map your customer-facing trigger to "in the loop" for the first runs of a new prompt, then step down to "on the loop" once verdicts are consistently clean.

Drift is the softest trigger and the one that catches the worst failures. The parent agent states a goal. The delegating prompt restates it as a subtask. The worker may then reinterpret it. Each restatement is a chance to move the target.

There are concrete signals you can compute at delegation time and compare after the run:

1. Goal overlap. Measure the similarity between the subtask prompt and the parent goal statement. A low overlap with a high tool score is a strong review signal.
2. Scope expansion. Count items the worker touched that were not named in the subtask (new files, new tables, new recipients).
3. Plan deviation. Ask the worker to declare a plan before acting, then compare the declared plan with the actions taken. Anthropic's lead researcher records the plan in memory before dispatch for exactly this reason, because large research tasks exceed the model's context window (ByteByteGo).
4. Handoff count. Each additional delegation hop multiplies the drift risk, because the subtask is now several restatements away from the goal.

Distributed tracing gives you the plumbing for signal four. Context propagation is what lets traces "build causal information about a system across services that are arbitrarily distributed across process and network boundaries" (OpenTelemetry), and the same discipline applies inside one agent system: if a hop does not carry the parent context, you cannot see the drift. A practical field guide to the symptoms includes root spans with no parent appearing mid-sequence and trace id discontinuities, which mean a downstream service started a new trace instead of continuing the original (TianPan.co on tracing across agent boundaries).

A useful comparison of the two structural patterns helps set the baseline. In the subagents pattern, a supervisor calls specialized subagents as tools, keeps conversation context, and the subagents stay stateless, which gives strong context isolation and centralized control at the cost of one extra model call per interaction; in a handoff pattern, control and state move to another agent, which suits conversational transfer but makes drift harder to bound (LangChain on choosing a multi-agent architecture). If you are on subagents, drift is a prompt quality problem. If you are on handoffs, drift is a state ownership problem.

Now combine them. Keep the rule dumb enough that a reviewer can predict it and an engineer can test it.

tool_score      1..5
spend_score     1..5   (budget tier, currency based)
customer_score  0 or 5 (external output = 5)
drift_score     1..5   (goal overlap, scope expansion, plan deviation)

review = (tool_score >= 4)
       or (spend_score >= 4)
       or (customer_score == 5)
       or (drift_score >= 4)
       or (sum(score) >= 12)
       or (hash(trace_id) % 100 < sample_rate)

Three properties worth noticing. First, each trigger is an absolute gate, not just a contributor, so one severe factor cannot be averaged away by three mild ones. Second, the sum catches combinations that are individually tolerable and jointly risky. Third, the sample clause is unconditional, which means a fixed share of low scores is reviewed anyway.

On the sample rate: pick it so that the review queue stays at a size the reviewers actually clear, and so that the sample is large enough to estimate how often a low score hides a real problem. If reviewers clear roughly a few dozen delegations a day, a sample rate high enough to produce a handful of low-score reviews per day is usually enough to detect a shifted distribution. Do not guess; measure the time per review and work backwards.

Then close the loop. Every verdict gets recorded next to the delegation with one of four values: approve, approve with edits, reject, or review blocked (the reviewer could not tell from the record). "Review blocked" is the most valuable signal you will collect, because it tells you the delegation record is missing a field.

Retune on evidence. If more than a small fraction of sampled low-score delegations turn out to need edits, lower the gates. If reviewers reject a trigger category consistently, either the rule is wrong or the score is miscalibrated. Record the change with a date and the evidence that justified it, so the next person can see why the threshold sits where it does.

One caveat from the oversight literature: the act of recording verdicts is not the same as oversight. The same position paper that warns about oversight degradation argues for design-level affordances and organizational protocols that support critical judgement and counteract skill atrophy (AI Agents Push Humans Out of the Loop). Concretely, that means giving reviewers enough context to disagree, not just a button, and rotating who reviews which category so nobody drifts into automatic approval.

If you would rather buy the inference plumbing than build it, Quanta Inference puts text, image, video, audio and embedding models behind one OpenAI-compatible API key, which removes one variable from the review equation: the model call path is the same regardless of which model a trigger routes to.