NOVRA Intelligence

Most teams building agentic systems tune the wrong thing. They spend weeks on prompts and model selection, get a single step from 94% to 99% correct, and then watch the finished system fail more than a third of the time on real tasks. The work was real. The arithmetic was never on their side.

The arithmetic nobody budgets for

An agent completing a task is not doing one thing well. It is doing many things in sequence, where a failure at any step can poison everything downstream. If the steps are roughly independent and each succeeds with probability p, a task of n steps succeeds at pⁿ.

At 99% per step:

Steps	Task success
10	90.4%
50	60.5%
100	36.6%
200	13.4%

A 99% step is an excellent step. Fifty of them is a coin flip. Two hundred is a system that essentially never finishes.

The lever that matters is not the one most teams pull. Going from 99% to 99.9% per step takes a fifty-step task from 60.5% to 95.1%. Going from 99% to 99.5% only reaches 77.8%. Reliability at the step level compounds, so the last fraction of a percent is worth far more than the first several — exactly the opposite of how effort usually gets allocated.

The other lever is n. Halving the number of steps does as much as an order of magnitude of per-step improvement, and it is usually cheaper. Most agent traces contain steps that exist because the architecture asked a general-purpose model to do something a function call would have done deterministically.

Independence is a convenient lie

The table above assumes independent steps, which real systems violate in both directions.

Failures cluster. An agent that has misread a schema at step 4 will keep misreading it at steps 9, 14, and 20. One root cause manifests as many step failures, which makes raw step-accuracy metrics look worse than the underlying system is — and makes them mislead you about where to spend.

Failures also compound in ways multiplication understates. A step that returns plausible-but-wrong output does not merely fail; it feeds a confident error into every subsequent step. The task does not end at 60% success and 40% failure. It ends at 60% success, some percentage of clean failure, and a residue of confidently wrong completions — which are the expensive ones, because nobody catches them.

That residue is the real reason to care about this. A system that fails loudly is an availability problem. A system that fails quietly is a correctness problem, and correctness problems in autonomous systems reach production before anyone notices.

Budgeting reliability like latency

The useful reframing is one that performance engineering worked out long ago. Nobody optimizes latency by making every function faster. They set a budget for the end-to-end path and allocate it across components, spending where the profile says it matters.

Reliability admits the same treatment.

Set the task-level target first. Not the step-level one. “This workflow must complete correctly 95% of the time without intervention” is a specification. “The model should be accurate” is not.

Count the steps and derive the per-step requirement. A 95% target over 50 steps requires 99.9% per step. If that number is implausible for the model you have — and it usually is — you have learned something important before writing code: the architecture is wrong, not the prompt.

Then reduce n. Every step that can be a deterministic function call, a database query, or a schema validation should be. The model’s job is the part that genuinely requires judgment. Teams routinely discover that a forty-step agent trace contains six steps of actual reasoning and thirty-four steps of glue that never needed a language model.

Spend the remaining budget on the steps that carry irreversible consequences. A misread field in a draft summary costs nothing. A misread field in a payment instruction costs money. Uniform reliability across steps of wildly different consequence is a misallocation, and the standard framings encourage it by reporting a single accuracy number.

Verification is cheaper than generation

The asymmetry worth exploiting: checking an answer is usually far cheaper than producing it. Confirming that an extracted invoice total matches the line items is arithmetic. Producing the extraction is not.

This means per-step reliability is not fixed by your model choice. A step with a cheap deterministic verifier and one retry has a materially different failure profile than the same step bare — you are no longer multiplying p, you are multiplying something closer to p + (1−p)·p for the retryable portion.

Which is why the highest-leverage question in agentic architecture is rarely “which model?” It is: for this step, what is the cheapest check that would catch the failure? Steps where that question has a good answer can be made reliable. Steps where it does not are the ones that need a human, and identifying them early is most of the design work.

The corollary is uncomfortable. Steps whose output cannot be verified more cheaply than it can be produced are steps you cannot make reliable through engineering alone. You can only bound their consequences — which is a design problem about blast radius and reversibility, not a modelling problem.

What this changes in practice

Three things follow, and they are architectural rather than incremental.

Long autonomous chains are a liability, not a capability. The instinct to let an agent run further without interruption runs directly against the exponent. A system that checkpoints every few steps, verifies, and proceeds is not less autonomous in any way that matters to the user; it is autonomous in units small enough to survive the arithmetic.

Confident wrong output deserves separate accounting from clean failure. Track them as different metrics. A change that reduces total failures while shifting the mix toward silent errors has made the system worse, and a single accuracy number will report it as an improvement.

Reversibility is a first-class design property. When a step cannot be made reliable enough, the remaining move is to ensure its failure is cheap to undo. That is a decision about system boundaries — what the agent is permitted to touch — and it is much harder to retrofit than to design in.

None of this is exotic. It is the same discipline that distributed systems adopted once people accepted that networks fail: assume the components are unreliable, measure what that implies end to end, and design around the number rather than hoping the components improve. Agentic systems are at the stage where that acceptance has not fully landed yet. The arithmetic is not optional, and it is not kind to architectures that ignore it.