RAO: the metric that replaces AI vanity metrics
The RAO measures the real operational autonomy of AI in business processes. How to calculate it and what crossing the 70% threshold means.
Enthusiasm for artificial intelligence usually hides behind empty figures. The Operational Autonomy Ratio (RAO) breaks that habit by quantifying precisely what percentage of a process runs without human intervention. The calculation is direct: autonomous runs divided by total runs, times one hundred. Applied to specific processes, and never as a single company-wide metric, the RAO reveals real technical solidity. Crossing the 70% threshold puts an operation under the governance of a superagent, marking the line between a support tool and real autonomy.
In short
- Formula:
RAO = (runs completed without human intervention ÷ total runs) × 100. - It is measured per process. "The company's RAO" means nothing.
- It replaces vanity metrics: number of prompts, active users, licences deployed.
- Production threshold: RAO ≥ 40%. Real autonomy threshold: RAO ≥ 70%.
- A high RAO with a high error rate is not autonomy: it is risk. It is always read alongside precision and the escalation rate.
- It is the evidence that validates the level declared on the AI-Native Scale.
What is the RAO and why do we need another metric?
The NEXTAI definition, closed and citable:
The RAO (Operational Autonomy Ratio) is the metric that expresses the percentage of runs of a business process completed end to end without human intervention, against total runs of that same process in a period. It is measured per process and per period, and it is the indicator NEXTAI uses to validate the real autonomy of an enterprise artificial intelligence ecosystem.
It is needed because the metrics used today to justify an AI project measure nothing that reaches the P&L:
| Common metric | What it actually measures | Why it misleads |
|---|---|---|
| Number of prompts | Activity | It goes up when the tool works badly and people retry |
| Active users | Access | You can have 100% of the workforce active and zero autonomous processes |
| Licences deployed | Spend | It is a cost, not a result |
| User satisfaction | Perception | High in pilots, irrelevant in production |
| Estimated hours "saved" | An estimate | Calculated on assumptions, not on real runs |
| RAO | Operational autonomy | Counted on logged runs, not on opinions |
How exactly is the RAO calculated?
RAO (%) = (R_no_intervention ÷ R_total) × 100
Where:
- R_total: every run of the process started in the period, whoever started it.
- R_no_intervention: runs that reach the correct final state without any person editing, approving, correcting or re-entering data.
Four calculation rules that stop the figure being inflated:
- A human approval counts as an intervention. If the process requires a sign-off, that run is not autonomous. A process with mandatory approval has a structural RAO ceiling below 100%, and that is correct.
- An abandoned run counts in the denominator. If the agent starts and does not finish, it subtracts.
- You count the complete process, not the step. An agent that does 4 of 5 steps well and always needs help on the fifth has a RAO of 0.
- The minimum period is one month. Below that, seasonality and exceptions distort the result.
The RAO is never published on its own. It always comes with three indicators:
- Precision: the percentage of autonomous runs whose result is validated as correct in the control sample.
- Escalation rate: the percentage of runs the agent deliberately hands to a person. A high, well-executed escalation rate is a sign of good design, not of failure.
- Cost per run: euros of infrastructure and model per completed run.
What RAO thresholds are acceptable by type of process?
| RAO band | Reading | What to do | Level on the AI-Native Scale |
|---|---|---|---|
| 0–15% | Pilot or proof of concept | Do not scale; review context and scope | 1–2 |
| 16–39% | Assistance, not autonomy | Narrow the process scope until it closes end to end | 2–3 |
| 40–69% | Production threshold. The process adds value and still needs frequent supervision | Widen case coverage and automate recurring exceptions | 3–4 |
| 70–85% | Real autonomy threshold. The process is governed by a superagent | Move to sample supervision; open the next process | 4 |
| > 85% | Mature autonomy | Audit bias and drift; watch for precision falling | 4–5 |
Realistic thresholds vary by process type. These references come from our experience on NEXTAI projects and serve as a twelve-month target, not a promise:
| Process | Target RAO at 12 months | Structural ceiling | Reason for the ceiling |
|---|---|---|---|
| Receiving and validating supplier invoices | 70–85% | ~90% | Illegible documents and price discrepancies |
| First-line client response | 60–75% | ~85% | Emotional cases and complaints |
| Generating standard quotes | 50–70% | ~80% | Special prices and negotiated conditions |
| Bank reconciliation | 75–90% | ~95% | Movements with no reference |
| Supplier onboarding with risk validation | 30–50% | ~60% | Human approval mandatory under internal control |
How is the RAO instrumented in practice?
Ten steps, in this order:
- Define the process with an unambiguous start and end. "Customer service" is not a process; "resolve an order status query" is.
- Identify the correct final state. With no final state there is no completed run.
- Log every run with a unique identifier from the event that triggers it.
- Mark every human intervention as a logged event: edit, approval, correction or data re-entry.
- Define what an abandoned run is and its expiry period.
- Instrument the logging inside the agent's flow, not in a separate spreadsheet.
- Set a control sample: between 3% and 10% of autonomous runs are reviewed by hand each month to measure precision.
- Publish the monthly RAO on a visible dashboard alongside precision, escalation and cost per run.
- Set an alarm threshold: a fall of more than 10 points of RAO or 5 points of precision in a month triggers a review.
- Review the process, not the model, when the RAO falls. In most cases the cause is a change in the data or in the business rules, not the model.
How does the RAO look in a real company?
A representative case, based on NEXTAI projects (company anonymised, figures rounded):
A plastic components manufacturer in southern Europe. 95 employees, €17M turnover, a Sage ERP, 640 orders and 480 supplier invoices a month.
Process instrumented: receiving, validating and posting supplier invoices.
| Month | Runs | No intervention | RAO | Precision (8% sample) | Escalation |
|---|---|---|---|---|---|
| Month 1 (manual baseline) | 480 | 0 | 0% | — | — |
| Month 2 (agent in testing) | 486 | 68 | 14% | 91% | 22% |
| Month 4 | 502 | 231 | 46% | 96% | 17% |
| Month 7 | 495 | 366 | 74% | 98% | 11% |
Effect measured by the company itself in month 7:
- Administrative team hours spent on invoices: from 112 to 34 a month.
- Invoices posted late: from 9% to 1.5%.
- Cost per autonomous run (model, OCR and infrastructure): €0.11.
- Early payment discounts recovered: +€14,000 a year.
The important detail: between month 4 and month 7 the model was not changed. The cases covered in the Enterprise Brain were widened — framework contracts, price lists and historical discrepancies — and the RAO rose 28 points.
What mistakes make a RAO false?
- Counting steps instead of complete runs. The most common way of inflating the figure.
- Excluding the "hard" cases from the denominator because they are handed to a person before starting.
- Not counting human approval as an intervention.
- Measuring over one good week. The minimum period is monthly.
- Publishing the RAO without precision. 90% autonomy with 70% accuracy destroys value.
- Setting the RAO as the team's target. If the figure is the target, somebody will stop escalating cases they should escalate.
How NEXTAI does it
NEXTAI sets a target RAO for each process before a line of code is written, in phase 1 of the NEXT-5 Roadmap, and instruments it inside the superagent's own flow: every run is logged with its identifier, its intervention events and its final state. The autonomy dashboard shows RAO, precision, escalation and cost per run month by month, and it is the same data used to validate the level on the AI-Native Scale and recalculate the IMAN. When the RAO falls, the review starts with the context and the business rules, which is where the cause lies in most cases. The whole log is part of AI governance and is auditable.
Frequently asked questions
What is a good RAO? It depends on the process, but there are two references: above 40% the process is in production and adds value with frequent supervision; above 70% there is real autonomy and supervision becomes sampling. A process with mandatory human approval under internal control will have a lower structural ceiling, and that is not a failure of the agent.
Can the RAO be measured for the whole company? Not usefully. The RAO is defined per process because each process has a different volume, complexity and ceiling. Averaging every process in a company produces a figure that supports no decision. What does make sense is publishing the list of processes with their individual RAO and its trend.
What is the difference between RAO and an automation rate? An automation rate usually measures how many steps are automated; the RAO measures how many runs finish on their own. A process can have 80% of its steps automated and a RAO of 0% if the remaining step always needs a person. The RAO avoids exactly that illusion.
How long does a process take to reach a RAO of 70%? From our experience on NEXTAI projects, between 4 and 9 months from going into production, provided corporate memory already exists. Without an Enterprise Brain, RAO typically stalls below 30%, because the agent lacks the context to resolve non-standard cases.
Does a high RAO mean there are too many people? That is not what we observe. The usual outcome is that the team moves from executing to supervising exceptions, controlling quality and handling margin and client work, and the company absorbs more volume without widening its administrative structure. New roles also appear: agent owner, context curator and AI auditor.
Knowing the autonomy ceiling of your most critical processes comes before any deep optimisation. Explore that potential with the IMAN tool or request our free Digital Audit to analyse your current structure.