Agentic nines

Most developers have had some version of this experience: you give an AI a task, it makes a change you never asked for, and you revert it. You've paid for the tokens, spent time reviewing the result and ended up back where you started. You might as well have piped the output to /dev/null.

For an individual developer, that can feel like a sunk cost. For a business repeating the workflow thousands of times, every unwanted change creates more work for someone else.

That is what interests me about evals (evaluations, or small test cases for AI). We use them to check whether an AI system can do a task. The business question underneath is how much confidence we have that it will do the work we actually need.

I wonder whether that confidence could eventually become something we buy. We expect reliability commitments from cloud services. Could we one day expect an AI service to complete a defined task successfully 99.9% of the time, or three "nines" of reliability? Call it agentic nines.

What evals give us

An eval gives a system a task and checks what happened against a definition of success. For a coding assistant, producing code is easy to recognise. Completing the requested change, preserving existing behaviour and avoiding unrelated edits is a higher bar. A change can pass the tests and still be work you didn't want.

Writing an eval forces us to describe what acceptable work looks like. Anthropic's guide to agent evaluations makes this point and explains why repeated trials matter when results can vary between runs. The evidence helps us make a decision, but it doesn't guarantee the next result.

Benchmarks let us compare models on shared tasks. Their results can inform model selection and form part of our evaluation criteria. Trusting a model with our work also needs evidence from our tasks, contexts and constraints, including how it handles unfamiliar situations and failures. A high benchmark score can't establish that on its own.

Production monitoring checks whether our evaluation results hold up in use. Guardrails constrain what the system can do when it gets something wrong. Better prompts (instructions to the AI) and context can improve performance, and we need to check what those changes actually improve.

There is a trap here: we can get better at passing familiar tests without getting equally better at unfamiliar work. Google's guidance on evaluation datasets explains why repeatedly using test results to guide changes can fit a model to those tests. I would apply the same discipline when choosing prompts, tools or agent designs: reserve representative cases that didn't guide those choices. Passing the development suite leaves those cases to be checked.

What the nines would measure

An AI service can be available and return an answer quickly while producing an unusable result. A commitment about useful work has to say more than whether the endpoint responded.

Site reliability engineering (SRE) is the practice of keeping software services dependable. IBM's guide to service level objectives describes agreed performance targets that reflect what users need from a service. For AI workflows, I would want those targets to include the quality of the completed work.

I would measure the proportion of assigned tasks completed to an agreed standard, within an agreed time and cost allowance. The standard might include factual accuracy, staying within scope and respecting permissions. Rejected tasks and abandoned attempts need to remain visible. Reporting only accepted outputs would hide the work that failed.

First-attempt success and eventual success after retries or human intervention deserve separate measures because they carry different operating costs. The sample size and uncertainty belong beside any reported rate, too. A neat percentage can imply more confidence than the evidence supports.

AI agents, systems that can take several steps and use tools to complete a task, add another complication. Each task may involve several decisions and tools. In a simplified example, ten necessary steps that each succeed independently 99% of the time give about a 90.4% chance of all ten succeeding. Real failures can be correlated, and agents can recover, so this is an illustration rather than a forecast. It shows why we need to measure the completed task as well as its individual steps.

A slippage budget

Perhaps businesses will become comfortable with an explicit AI slippage budget: an allowance for unsuccessful work and the effort needed to recover from it.

This builds on the SRE idea of an error budget, where a reliability target leaves an allowance for failures and a policy determines what happens when it is consumed. I would extend that accounting to include retries, review, correction and delay.

At 99.9% success across one million tasks, 1,000 tasks still need recovery. If each takes ten minutes of human attention, that is about 167 hours of rework. These are illustrative assumptions, but that workload is easy to miss when the headline is three nines.

The same failure rate could be manageable for draft summaries and unacceptable for actions affecting customers directly. An awkward sentence and an unauthorised action shouldn't disappear into the same average. Some failures can be corrected routinely. Others need separate limits and controls.

The budget also needs an owner and a response. If rework exceeds the allowance, a team might narrow the agent's responsibilities, require more review or pause a rollout while it fixes the cause. The budget should change what the team does.

Who is doing the reliable work?

If a person catches an incorrect answer and fixes it before it reaches a customer, the service can still deliver a successful outcome. That human effort is part of how its reliability was achieved. Hiding it risks making a well-supervised system look autonomous.

I would report three measures together:

Measure	What it tells us
Tasks accepted without human correction	How much work we can actually hand off
Tasks accepted after human correction	How much supervision supports the result
Tasks declined or handed back	How much of the workload the system covers

Declining a task can be the right behaviour. An agent that recognises its limits may be more useful than one that guesses. But a provider could improve a success rate calculated only on attempted tasks by declining the hardest work. We need to know how much work it takes on as well as how often it succeeds. Otherwise, the customer inherits the difficult cases while the provider reports the easy wins.

Could providers guarantee useful work?

I can imagine providers eventually offering commitments for narrowly defined outcomes, such as extracting specified fields from a supported document or completing a bounded support workflow under an agreed policy.

Those tasks have observable results and a definition of failure. A broad promise to "do what you mean" is harder to measure. Customers disagree about what good means, instructions can be ambiguous, and success can depend on systems outside the provider's control.

A credible commitment would specify the supported tasks, operating conditions, measurement period and how failures are handled. It would also identify which parts of the workflow the provider is responsible for. Changing the instructions, data or tools can change the result. My procurement question would be: which failures are you accepting responsibility for, and which are you handing back to us?

This is a possibility I want to explore. If it happens, buyers could compare services on accepted outcomes and recovery effort alongside token prices. A cheaper model that needs more supervision may cost more to operate.

The nature of evals may change

I don't think evals disappear when models become more capable. I think the question we ask them to answer becomes broader.

We can treat an AI system like a deterministic program, one that gives the same result for the same inputs: give it a task, check a list of criteria and mark the test as passed. Those checks remain useful when a task has a precise answer or a firm boundary. They tell us less about the judgment we're trusting the system to exercise across a variety of work.

As we delegate more, I would want evaluations to build evidence that a model can understand intent, adapt to different contexts and make sensible decisions when a task doesn't follow a familiar script. That includes recognising uncertainty, asking for clarification and knowing when the work should come back to a person. Dependable behaviour sometimes means recognising that proceeding would be a mistake.

I want confidence that holds across a range of work, with a clear understanding of where it stops. How a system responds to an unfamiliar situation matters alongside how well it handles routine requests. That confidence needs to be earned through repeated observation, including failures.

For a CTO, I would want to know what kinds of work the evidence supports handing over, how the system behaves outside familiar conditions and how much human judgment its apparent reliability depends on. Those answers need revisiting as the model and its responsibilities change.

The number I would want beside the token bill is the cost per accepted outcome, including the work needed to get there. Behind that number is the larger question of whether we have enough evidence to delegate with confidence.

I would welcome agentic nines. The promise I would want behind them is dependable judgment across the work we agree to hand over, with honest limits on that promise.

Written 13 October 2026 at 7:59 pm AEDT (Sydney).

These are my own views and do not represent those of my employer.