PaperlayerView exact revision on arXiv

Source-linked AI summary

READY or Not: Reliable Enterprise Agent Deployment

Veronica Chatrath, Bryan Zhu, Jingxuan Fan, George Pu, Soham Dinesh Tiwari, Soham Dan, Ryan Young, Yuan, Li, Yuang Yao, Apaar Shanker, Minglai Yang, Daniel Yue Zhang, Yunzhong He, Ying Liu, Chenguang Wang, Zhijun Yin, Yuan Xue

arXiv:2609.02095v1cs.AI

TL;DR

Professional-work benchmarks measure autonomous task performance, but enterprise deployment requires a human–AI system to meet a specified reliability level with acceptable oversight and cost. READY addresses this gap by selecting and statistically qualifying minimum-cost oversight policies for workflow-specific deployments. In a clinical-audit evaluation of 16 systems and 750 cases, similar autonomous accuracy required markedly different human-review rates at the same reliability target.

  • Problem

    Enterprise deployment requires determining whether an agent can meet workflow-specific reliability with acceptable human oversight and operating cost, beyond autonomous benchmark performance.

  • Method

    READY evaluates workflow-specific execution, selects a minimum-cost oversight policy satisfying a reliability target, and statistically qualifies the frozen policy on held-out evidence.

  • Results

    In 16 agent systems and 750 clinical-audit cases, GPT-5.4’s 72.8% versus Sonnet 5’s 72.5% autonomous accuracy required 39.2% versus 29.6% human review, respectively, at the same 76% reliability target.

  • Takeaways & Limitations

    READY supports comparing agents by the cost and oversight required for reliable deployment rather than autonomous performance alone.

  • Takeaways & Limitations

    The empirical evaluation focuses on trajectory-invariant terminal accept-or-escalate policies; large-scale validation of trajectory-dependent oversight is left to future work.

Abstract

from arXiv · show

An AI agent can perform well on benchmarks and still be unsuitable for deployment. Existing AI-agent benchmarks measure whether an agent can complete realistic professional work, whereas enterprise deployment asks a different question: whether an agent can meet a required reliability level, under acceptable human oversight, and at tolerable cost. We introduce Reliable Enterprise Agent Deployment (READY), a framework for qualifying AI agents for deployment on enterprise workflows. READY preserves each workflow's own definition of successful execution while applying a common qualification procedure. Given an agent, a workflow, and a class of candidate oversight policies, READY measures the reliability and operating cost of the human-AI system, selects the minimum-cost policy that satisfies a specified reliability target, and statistically qualifies it on held-out cases. The resulting deployment profile characterizes the supported operating point: reliability, human-oversight burden, and cost. READY is implemented as an open testbed that decouples workflow specification, execution, evaluation, and qualification, and runs on existing agent-evaluation infrastructure. In an end-to-end clinical-audit case study spanning 16 agent systems and 750 cases, READY reveals differences hidden by autonomous performance: two systems separated by only 0.3 points in autonomous accuracy (72.8% vs. 72.5%) require 39.2% versus 29.6% human review, respectively, to qualify at the same 76% reliability target under the evaluated oversight policy. READY thus shifts enterprise agent evaluation from how well can the agent perform the work? to under what conditions, and at what cost, can it be reliably deployed? By making those conditions explicit and statistically testable, READY provides a basis for comparing agent systems, setting oversight requirements, and making evidence-based deployment decisions.

1 Introduction

READY reframes enterprise agent evaluation around reliable deployment of a human–AI system, not autonomous task performance alone. It selects and qualifies oversight policies that meet workflow-specific reliability requirements at minimum cost.

  • Motivation: Enterprise deployment asks whether a human–AI system can meet required reliability with acceptable oversight and operating cost.Autonomous accuracy alone does not determine readiness; deployment depends on identifying cases for human review and the cost of that review.
  • Framework: READY preserves each workflow’s definition of successful execution while applying a common deployment-qualification procedure.Workflow success may include outcome correctness, process requirements, evidence grounding, and policy adherence.
  • Empirical result: 16 agent systems evaluated on 750 clinical-audit cases show that similar autonomous performance can correspond to substantially different reliability–oversight tradeoffs.GPT-5.4’s 72.8% versus Sonnet 5’s 72.5% autonomous accuracy required 39.2% versus 29.6% human review, respectively, at the same 76% reliability target.
  • Testbed: READY provides an extensible interface separating workflow evaluation from deployment qualification and supports heterogeneous workflows through existing agent-evaluation infrastructure.Workflows retain their own task populations, environments, evaluators, and standards of correct work.
  • Framework: READY selects the minimum-cost oversight policy that satisfies a specified reliability target, then statistically qualifies the frozen policy on held-out data.The resulting deployment profile characterizes the supported reliability–oversight–cost operating point rather than autonomous capability alone.

2 Design Overview

READY defines deployment qualification as a staged process that turns workflow-specific execution evidence into a statistically supported deployment profile. Its specifications separate workflow semantics, evaluation evidence, deployment assumptions, and policy qualification.

  • Objective: READY evaluates whether an agent can be deployed reliably and economically on a concrete enterprise workflow.The framework evaluates the human–AI system induced by an oversight policy rather than the agent in isolation.
  • Three-phase flow: The three phases are workflow evaluation, minimum-cost policy optimization, and held-out statistical qualification of the selected policy.The output describes the reliability–oversight–cost operating point supported under stated deployment assumptions.
  • Workflow semantics: Each workflow maps trajectories into multidimensional measurements and a success predicate that can include outcome, process, grounding, or policy requirements.Instance-level success is distinct from diagnostic measurements retained about the execution.
  • Policy selection: READY’s optimization searches candidate policies for those meeting reliability and optional risk constraints, selecting the lowest-cost feasible policy.If no feasible policy exists, the evaluated policy class does not support the requested operating point.
  • Deployment profile: Deployment profiles report the qualified policy, reliability, confidence, oversight burden, cost, risk, and the scope and assumptions under which the result holds.Qualification is conditional on the workflow, system, policy, and declared deployment assumptions.

3 Oversight Policy Optimization and Deployment Qualification

READY treats oversight as a constrained optimization over human–AI operating policies. It estimates reliability and cost, selects a policy using development evidence, and qualifies that frozen policy on held-out cases.

  • Qualification quantities: The key distinction is between autonomous agent performance and the reliability of the deployed human–AI system.An oversight policy determines how effectively observable information is used to introduce intervention and what that intervention costs.
  • Qualification quantities: Deployment reliability is the probability that an execution under policy π satisfies the workflow-specific success criterion.The probability averages over workflow instances and, when relevant, stochastic execution, environments, oversight, and actors.
  • Qualification quantities: Operating cost includes agent execution and human review or intervention, with policy-dependent components when intervention changes subsequent execution.READY can estimate case-level costs directly instead of assuming one constant review cost.
  • Policy evaluation: In terminal accept-or-escalate deployment, saved autonomous executions allow many threshold policies to be evaluated without re-executing the agent.The routing decision uses an observable signal, while autonomous success is generally unknown at deployment time.
  • Deployment implications: The empirical value of an oversight policy depends on how effectively it identifies cases requiring intervention, so similar autonomous success rates can yield different operating points.The evaluated metrics are properties of the deployed configuration under a specified policy, not intrinsic agent properties.
  • Optimization and qualification: At target reliability Y, READY chooses the feasible policy with minimum operating cost, while development selection remains separate from held-out qualification.The selected policy is frozen and evaluated against the actual deployment target on held-out evidence.

4 READY Evaluation Runtime and Open Testbed

READY is an open testbed that adds workflow semantics and deployment qualification to existing agent-evaluation infrastructure. It standardizes the evidence crossing workflow, runtime, and qualification layers without requiring a uniform task or execution implementation.

  • Architecture: The architecture has specification, evaluation-runtime, and qualification layers that respectively define assumptions, execute workflows, and analyze evidence.This separation permits existing evaluation infrastructure to be reused across different task representations and grading mechanisms.
  • Specifications: READY’s workflow specification identifies the reusable workflow, task-instance population, sampled cases, and execution environment.In the Inspect implementation, READY task instances correspond to Samples rather than enclosing Tasks.
  • Specifications: The evaluation specification defines the workflow evaluator, success predicate, and routing signals exposed to oversight policies.The evaluator may be deterministic, human-annotated, model-assisted, or composed from multiple mechanisms.
  • Specifications: Deployment assumptions separately specify reliability targets, oversight models, operating costs, and risk tolerances, allowing the same evidence to support different requirements.Development and held-out partitions are versioned, and policy-selection cases remain separate from qualification cases.
  • Runtime: The runtime supports both replay-based terminal routing and policy-in-the-loop trajectory-dependent intervention.For trajectory-dependent policies, intervention changes subsequent execution and produces policy-dependent trajectories.
  • Qualification handoff: The resulting deployment profile is an evidence-backed operating point conditional on the workflow, system, policy, and deployment assumptions.It is not a context-free model score, and material changes require rerunning qualification.
  • Open testbed: READY separates workflow-specific definitions of successful work from a common deployment-qualification procedure.New workflows contribute their own evaluation semantics, populations, environments, and cost measurements through the shared interface.

5 Empirical Evaluation: Deployment Qualification on CliniCARE-Bench

The CliniCARE-Bench case study instantiates READY to examine whether routing signals support selective autonomy and whether similar autonomous performance yields different qualified operating points.

  • READY adapts CliniCARE-Bench to measure selective autonomy, human oversight required for reliability targets, and deployment value differences.
  • The study also tests whether systems with similar autonomous performance support materially different qualified operating points.
  • The evaluation asks whether the routing signal separates more reliable from less reliable autonomous executions.

2. How does the required human-review burden grow as the reliability target increases? (Section 5.4)

READY converts routing signals into held-out reliability–oversight frontiers, showing how review burden changes with reliability targets and how routing quality can separate deployment value from autonomous accuracy.

  • Experimental setup: 16 systems were evaluated on 750 cases, with identical case-based development and qualification splits of 375 cases each.The split preserves paired cross-system comparisons while retaining the cohort’s natural verdict distribution.
  • Experimental setup: The stated confidence signal ranges from 5 to 36 distinct values across systems, limiting reachable operating points for coarse signals.Eight missing-confidence or missing-report runs were assigned s_i = 0 and escalated first.
  • Deployment frontier: Targets above reliability 0.90 are unreachable when selective success remains below the assumed review success ah = 0.90 at every observed coverage level.This boundary follows from the evaluated review assumption rather than autonomous capability alone.
  • Routing quality: Autonomous accuracy and routing quality differ: base accuracy and AUROC are essentially uncorrelated (Pearson ρ = −0.12), while AURC tracks accuracy (ρ = −0.80).AUROC isolates ranking quality from base rate, whereas AURC captures the absolute risk–coverage tradeoff faced in deployment.
  • Deployment comparison: At Y = 0.76, Sonnet 5 requires 29.6% human review versus GPT-5.4’s 39.2%, despite autonomous accuracies of 72.5% and 72.8%.Both qualify under ah = 0.90; Sonnet 5’s stated-confidence signal more sharply separates successes from failures.
  • Deployment frontier: Single-target review burden can be misleading: Qwen-3.7-Plus requires 61.9% review versus MiniMax-M3’s 33.9% despite better routing metrics, because Qwen overshoots to bR = 0.874.The full reliability–oversight frontier is therefore the fairer cross-system comparison.

6 Related Work

READY integrates capabilities from related evaluation literatures into a deployment-qualification framework that measures reliability, oversight, cost, and held-out statistical support. It preserves workflow-specific success criteria while evaluating the human–AI system under an oversight policy.

  • Deployment qualification: READY addresses deployment qualification rather than capability alone, asking which oversight policy meets a reliability target at acceptable operating cost.Its workflow-specific success predicate can include outcome correctness, process requirements, evidence grounding, policy adherence, and other task requirements.
  • Evaluation infrastructure: READY builds on evaluation infrastructure that standardizes task specification, execution, scoring, and logging, while adding deployment qualification.Its focus is the deployment claim rather than merely how an evaluation is executed and recorded.
  • Integration across literatures: READY integrates six related-work dimensions: executable work, interaction, target reliability, operating cost, human oversight, and held-out statistical qualification.Table 4 identifies READY as the only approach integrating all six into one deployment-qualification claim.
  • Selective prediction and deferral: Selective prediction typically trades automated coverage against accepted-case error, whereas READY evaluates the declared human-review path and the resulting human–AI system reliability.This makes human review part of the operating policy rather than treating escalation as mere abstention.
  • Cost-aware routing and deferral: READY differs from routing and cascade methods by using human review, a statistically qualified reliability floor on held-out data, and workflow-specific success criteria.Confidence-based routing can provide READY’s signal, while READY supplies the qualification procedure.
  • Human oversight: READY measures review effectiveness rather than assuming human oversight improves outcomes, qualifying a specific human–AI configuration on held-out evidence.This responds to related findings that human–AI teams may underperform the stronger component and that overreliance can undermine review.

7 Scope, Limitations, and Future Work

READY’s claims are conditional on the evaluated workflow population, versioned configuration, oversight assumptions, and deployment context. Future work should measure human-review economics directly and extend validation across policies, workflows, and domains.

  • Scope: READY does not provide universal agent certification or capture every organizational consideration in production deployment.Enterprise security, privacy, legal, regulatory, and governance processes remain outside the core methodology.
  • Empirical scope: The empirical evaluation focuses on trajectory-invariant, terminal accept-or-escalate policies using CliniCARE-Bench.Trajectory-dependent policies involving review, clarification, correction, or other intervention are treated as an extension rather than the central empirical setting.
  • Human-oversight assumptions: Deployment profiles are conditional on assumed human-review success rate, latency, and cost when the review path is not directly executed.The paper calls for direct measurement of reviewer effectiveness, review time, intervention type, and recovery cost.
  • Population and distribution validity: Qualification claims apply to the represented workflow population and versioned configuration, not arbitrary distribution shifts or materially different agent behavior.Continuous monitoring and requalification triggers are important but outside this work’s scope.
  • Risk and deployment context: READY optimizes expected operating cost subject to a workflow-success reliability target, while permitting additional tail-risk constraints when failure consequences differ substantially.The framework does not replace broader enterprise security, privacy, legal, regulatory, or governance processes.
  • Future work: Future work targets trajectory-dependent and multi-step oversight, direct measurement of human-review effectiveness and economics, and broader enterprise-domain validation.The open interface is intended to support these extensions without changing the qualification objective.

8 Conclusion

READY reframes enterprise agent evaluation as qualifying a human–AI operating point for required reliability, oversight, and cost. It combines workflow-specific success definitions with threshold-based routing and held-out statistical qualification, while recognizing that risk-sensitive extensions are optional.

  • READY evaluates deployment by required reliability, acceptable human oversight, and operating cost rather than autonomous task performance alone.
  • READY selects an oversight policy that meets a target reliability at minimum operating cost and qualifies that operating point on held-out evidence.
  • Each workflow retains its own definition of successful execution, while READY applies a common qualification methodology.
  • Threshold Routing: Threshold routing accepts cases with s_i ≥ τ autonomously and sends cases with s_i < τ to human review.
  • Threshold Routing: A monotone routing signal supports selective routing when increasing the threshold does not reduce success probability among retained autonomous cases.
  • Risk-Sensitive Qualification: Risk-sensitive qualification is optional and can use workflow-specific loss and CVaR when binary deployment success does not capture failure consequences.
  • Statistical Qualification: Held-out qualification requires a one-sided confidence bound, with bootstrap resampling aligned to the unit of statistical generalization.

B Supplementary Analyses for CliniCARE-Bench

The supplementary qualification procedure routes held-out cases using a frozen threshold, estimates reliability from accepted cases and assumed review success, and qualifies policies only when a confidence bound reaches the target.

  • Thresholds selected on the development partition are frozen before held-out qualification.
  • Held-out routing counts accepted cases and autonomously successful accepted cases to compute review fraction and accepted-case success.
  • The point reliability estimate combines observed accepted-case performance with the assumed success of human review.
  • The procedure uses a one-sided 95% exact Clopper–Pearson lower bound for accepted-case success.
  • A policy qualifies only when its 95% lower confidence bound is at least the target reliability Y.
  • The minimum assumed human-review success needed for qualification is found by a one-dimensional solve because the lower confidence bound is nondecreasing in that assumption.

B.2 Sensitivity to the Human-Review Assumption

Sensitivity analysis shows that the assumed quality of human review materially changes reachable reliability and review burden, while qualification outcomes can be non-monotone because thresholds are reselected and tested on held-out data.

  • The analysis repeats development selection and held-out qualification across human-review success assumptions from 0.80 to 1.00.
  • The review assumption, rather than agent capability, governs how much of the reliability range is reachable.
  • 23 percentage points: lowering assumed review success from 0.90 to 0.80 raises mean review burden and caps maximum attained reliability at 0.775.
  • At assumed review success 0.80, 311 of 496 policies route every case to review, qualifying only by not deploying.
  • Qualification counts need not increase monotonically with assumed review success because more generous assumptions can select larger but less reliable accepted sets that fail held-out bounds.

B.3 Process-Aware Success Definition

Replacing verdict-only success with a process-aware definition preserves routing-quality rankings but substantially changes deployment frontiers and review requirements.

  • The process-aware success definition requires both a correct four-way verdict and absence of a disqualifying process defect.
  • Routing-quality conclusions remain similar, with Spearman correlation 0.87 between AUROC rankings under the two success definitions and per-system AUROC changes no greater than 0.032.
  • Mean review burden rises from 53.0% to 69.8% under the process-aware definition.
  • Both Gemini Flash systems move from roughly 38% review to 100% at Y = 0.76, leaving no reachable deploying operating point under the process-aware definition.
  • Qualified-policy counts rise from 469 to 488 of 496 under the harder predicate because development selection chooses more conservative thresholds.
  • Qualified status is not monotone in success-predicate difficulty, so review burden must be reported alongside qualification.

B.4 Complete Per-System Results

Complete per-system results show that deployment behavior varies across reliability targets and verdict classes, even when agents have similar autonomous performance. Review burden can change discontinuously, while confidence provides ranking information within each predicted class.

  • Qualification across targets: Review burden can jump across reliability targets because systems with few distinct confidence values produce step-function qualification behavior.Opus 5 rises from 0.8% to 22.4% to 37.9% review, while Gemini-3.1-Pro remains at 100% for the upper two targets.
  • Routing behaviour by verdict class: Autonomous success varies strongly by predicted verdict class, from 0.856 for Yes to 0.336 for Indeterminate: Medically Ambiguous.Mean stated confidence varies less across those classes, ranging from 0.894 to 0.797.
  • Routing behaviour by verdict class: Within every predicted class, the routing signal retains ranking power, with pooled AUROC values from 0.611 for No to 0.668 for Indeterminate: Medically Ambiguous.This supports using a class-agnostic threshold rather than treating the predicted class itself as the routing signal.
  • Complete per-system results: The complete results therefore expose reliability–oversight operating points that autonomous performance alone does not reveal.The results are presented as per-system risk–coverage and qualification outcomes alongside routing-score distributions by verdict class.

B.5 Cost-of-Conflation Control: Always-Review-Indeterminate

The always-review-indeterminate control is not consistently more expensive, because indeterminate verdicts are less often correct in this benchmark. Its structural cost is a fixed review floor and dependence on the benchmark’s class-success profile.

  • Empirical cost comparison: The always-review-indeterminate control routes 48.9% of cases to review on average, versus 53.0% for signal-only routing, across 496 policies.It requires strictly more review in only 206 of 496 policy cells.
  • Empirical cost comparison: At reliability targets of 0.80 and 0.85, the control needs more review on 10 of 16 and 6 of 15 systems, with mean differences of −2.2 and −5.2 percentage points.These comparisons use each policy’s minimum review burden at the stated reliability, removing threshold-grid overshoot.
  • Why the control competes: Indeterminate adjudications have pooled autonomous success of 0.493, compared with 0.757 for definite adjudications, giving predicted class genuine information about autonomous failure.This benchmark-specific class-success pattern explains why class-based escalation is competitive here.
  • Structural limitation: Structurally, the control imposes a per-system review floor because no threshold can accept an indeterminate case.It therefore cannot trace a frontier across the reliability range in the same way as the signal-based policy.
  • Structural limitation: The control’s competitiveness depends on the benchmark’s assumption that indeterminate verdicts are relatively unreliable in this cohort.The broader design principle is to drive escalation with a measured routing signal rather than infer it from an outcome class.
Loading 2609.02095v1…