Routing Agent Work: Auto-Approve, Queue or Block

Ask the same three questions of every action the agent proposes, before it runs. The answers are properties of the action and its arguments, not of the agent's prose rationale.

Can it be undone without residue

Reversibility is the primary axis, and the useful definition is strict. Undoable means you can restore the prior state completely: no notification already delivered, no external party already acted on it, no third-party system already acknowledged it. Sending a draft into a review folder is reversible. Sending an email to a customer is not. Writing to a staging table is reversible. Writing to a production ledger is not. Anthropic's framework for trustworthy agents treats irreversibility as a distinct risk axis and recommends preferring reversible actions and requesting narrower scope when reversibility is unclear, as cited in the Scalekit analysis 5.

A practical test: if the action executes and you discover it was wrong ten minutes later, what does recovery cost? If the answer is "delete a row" or "git revert", it is reversible. If the answer is "call the customer and apologize" or "reconcile the ledger by hand", it is not.

How far does the damage spread

Blast radius is the count and reach of what one invocation touches: records, systems, people, money. A tool that updates "a customer record" should accept exactly one record per call, not a batch parameter that lets one invocation fan out across a table because batching was convenient to implement 18. Scope creep in tool design is the quietest way blast radius grows, because nobody decided to let the agent touch the whole table, it simply was not prevented.

Blast radius also has a rate dimension. One bad refund is a data point; fifty in an hour is an incident. Cap the number of actions of a given type per minute, hour or session regardless of whether each one individually looks fine, and cap the aggregate value moved in a window, with the cap requiring a manual reset rather than a silent cooldown 18.

How confident is the model, discounted for calibration

Treat the model's stated confidence as a weak signal, discounted by how well it has been calibrated on your traffic. LLM confidence reflects token probability, not factual accuracy, and an agent can be highly confident about an action that turns out wrong; one production team recorded an average confidence of 0.87 on actions later judged incorrect, which made confidence-only thresholds useless 20. Calibration is achievable but needs labeled data for your specific domain and degrades as the input distribution shifts 20.

So compute a calibrated score: bucket historical actions by the model's raw confidence, count what fraction in each bucket were actually approved or correct, and use the observed rate, not the raw number. If the model says 0.9 and your bucket data says actions in that range were right 0.72 of the time, 0.72 is the number that enters the policy.

Route on the combination, in a fixed order, because some combinations must dominate others. Irreversibility overrides confidence: a confident irreversible action is still irreversible. Blast radius overrides reversibility: a reversible action that touches ten thousand records can be undone, but the rollback itself may be an incident.

The table above mirrors the tiering that runtime policy guides converge on: reads allow and record, sensitive reads refuse or redact, reversible narrow-reach changes allow under a bound, reversible wide-reach changes hold for one named approver, irreversible changes hold and require a restore plan, and security-sensitive changes are refused outright 17.

The decision rule in prose: if the action is reversible and its blast radius is under the tier's numeric bound, send it to auto-approve even when confidence is mediocre, because the cost of a wrong call is a rollback and the cost of a review is a person's scarce attention. If it is irreversible or over the bound, it goes to a human, and the number of required approvers scales with uncertainty. If it falls in the security-sensitive class, it is blocked no matter how confident or how reversible it claims to be.

Take a support agent that can issue refunds. Make the numbers explicit and inspect what they do to routing.

Define the tool so one invocation processes exactly one refund, with a cap of three refunds per account per rolling 24 hours, an approval trigger for any single refund above a fixed dollar threshold, and an aggregate cap on dollars processed per hour that requires manual reset 18. Assume your history shows the agent's refunds are approved by reviewers without edits in most cases and the reversibility is genuinely high (a refund can be reversed by a compensating charge, though the customer sees the fluctuation).

Now classify three proposals:

• A $12 refund on a single order, first refund for that account today. Reversible, low blast radius, under every cap. Route: auto-approve. Nobody looks, and if it was wrong, a compensating charge fixes it.
• A $900 refund, the second for the account today. Reversible, single record, but above the dollar threshold. Route: review queue with the order, the customer history and the proposed amount attached. One approver.
• A batch adjustment crediting 4,000 accounts after a pricing error. Over the rate cap and the aggregate cap in one invocation, touching many records across a shared system. Route: review queue with predicted blast radius attached, and two approvers, because rolling it back would itself be disruptive. If the tool had no batch parameter and the agent proposed 4,000 sequential single-record calls, the rate gate refuses the fourth and asks for a human.

The useful insight here is that the batch case and the single case differ in policy outcome for reasons that have nothing to do with the model's confidence. Two proposals the model rates at 0.95 land in different routes because one is a one-way door across a wide surface and the other is a small reversible change.

Put the policy at the tool boundary, outside the model. A rule in the system prompt is text the model reads, and a prompt injection can override it; a rule at the gate is outside the model's reach 17. Runtime guardrails compare each live action against policy and either let it through, hold it, escalate to a human or shut it down 12.

A minimal policy as data, evaluated on the tool call and its parsed arguments:

# policy.yaml, evaluated before every tool execution
defaults:
  on_unknown_tool: block
  require_agent_identity: true
  log_decision: always

tiers:
  read_logs:
    class: read
    route: auto_approve
  read_customer_record:
    class: read_sensitive
    route: block            # return redacted result instead
  update_ticket_status:
    class: reversible_narrow
    max_records: 1
    max_calls_per_hour: 60
    route: auto_approve
  issue_refund:
    class: reversible_narrow
    max_records: 1
    max_amount_usd: 250
    max_per_account_24h: 3
    aggregate_cap_usd_per_hour: 2000
    over_cap_route: review_queue
    approvers: 1
  bulk_price_adjust:
    class: reversible_wide
    max_records: 50
    over_cap_route: review_queue_with_blast_radius
    approvers: 2
  schema_migration:
    class: irreversible
    requires_restore_plan: true
    over_cap_route: review_queue
    approvers: 2
  rotate_credentials:
    class: security_sensitive
    route: hard_block

Three details make this work in practice. First, the policy evaluates arguments, not just tool names: a restart in a staging namespace and a restart in the payments namespace are different actions and belong in different tiers 17. Second, every grant is scoped to one task and expires, because a grant that outlives its task becomes a standing permission 17. Third, the credential valid at pause time is not guaranteed to be valid at resume time, which is the failure most approval-gate implementations skip; the queue-then-execute model holds credential state across the pause window and the agent references an identity and connection name rather than a raw token 5.

Layer the enforcement. Framework hooks (approval flags, interrupts) run inside the agent's process; a policy engine at the tool boundary intercepts each action before execution; infrastructure backstops such as cloud IAM and admission control refuse the request at the API even when the agent-side check is skipped 17. You need at least two of the three, because each covers a gap in the others.

A queue is only as good as the packet attached to each item. The reviewer needs the proposed action, the exact arguments, the agent's stated intent, the relevant context (customer history, recent similar actions), the predicted blast radius with the numbers that produced it, and a one-click approve or reject that records the decision. MLflow's review queues frame this as turning a spreadsheet of traces into a support-ticketing workflow: you define a queue with a name and an evaluation question, and flagged traces are assigned automatically or by rule 9. The Chevrolet dealer case, where a chatbot agreed to sell a vehicle for one dollar and called it legally binding, is the canonical reminder of what happens when a plausible but catastrophic action has no checkpoint 9.

Make the queue produce data, not just decisions. Every approve, edit and reject is a labeled example of what a human deems acceptable, and enough of them let you train a judge to pre-screen the queue or to tighten the thresholds that feed it 9. This is the mechanism by which routing improves: the thresholds are hypotheses, and queue outcomes are the test.

Two design choices matter more than the UI. Do not let an agent assess its own risk and set its own route; the gate's job is to route differently based on which side of the reversibility line an action falls on, not to trust the agent's estimate of its own danger 18. And separate autonomy from authority: autonomy is how many steps the agent takes unprompted, authority is which of those steps can finish without a human, and conflating them forces the false choice between a useless agent and a dangerous one 16.

Track four numbers per tier and review them weekly. The auto-approve error rate, meaning approved autonomously and later reversed or corrected, should stay below the cost you assigned to a rollback. The queue approval rate, meaning items a reviewer approved without edits, tells you whether the tier is over-gated. The queue latency, from enqueue to decision, tells you whether agents are stalling on human attention. And the block rate, which should be near zero for legitimate work and non-zero for attack attempts, because a hard block that never fires in production is untested.

Route from the data. If a queued tier is approved without edits in the large majority of cases over a sustained window, consider narrowing its blast radius in the tool design and moving it to auto-approve with sampling. If an auto-approved tier shows reversals above your tolerance, the blast-radius bound is too loose, not the confidence threshold. Confidence rarely needs to be the binding constraint for reversible actions, and it is usually the wrong lever for irreversible ones, where the question is whether any autonomous path should exist at all.

This is also where governance pressure shows up. Databricks notes that many AI regulations require meaningful human oversight for higher-risk systems, citing Article 14 of the EU AI Act on human monitoring and intervention and the NIST AI Risk Management Framework's emphasis on oversight in high-consequence applications 4. A routing policy with explicit thresholds is the artifact you show an auditor: it demonstrates that high-risk actions were designed to pause, and it records which named person approved which invocation.

Two failure modes to watch. A hard block that the agent can route around by calling a different tool is not a block, so every protocol (shell, cloud API, Kubernetes, MCP) should pass the same gate 17. And a queue that grows faster than review capacity will be abandoned, so the thresholds must be tuned to the team's real throughput, not to an ideal of total oversight.

If you are running several models behind one agent stack and want the routing logic to apply uniformly across them, Quanta Inference (https://quantaintelligence.ai/inference) puts text, image, video, audio and embedding models behind one OpenAI-compatible API key, which keeps the policy layer independent of which model proposed the action. For teams that want the whole gate built and tuned with them rather than assembled from parts, describing the workflow to a specialist at Quanta (https://quantaintelligence.ai/) is the shorter path.