AI Agent Reliability 2026: Structure Beats Instructions

Three July 2026 preprints measured where AI agent reliability comes from. In one production system, the verification loop was worth +1.5 of an +11.0-point gain on SpreadsheetBench. In a 580-scenario benchmark, guardrails recovered 19.9% of failures; system-prompt rules moved frontier models under half a point.

TL;DR

• The Leni team's cross-benchmark decomposition (19 July 2026) takes a production enterprise agent apart and asks which layer earns the accuracy. On SpreadsheetBench, prompting and scaffolding account for +9.5 of the +11.0-point gain; the verification loop adds the last +1.5.¹
• On that run the verifier caught only 8 of the 40 errors that existed, but produced zero false alarms in 357 confirmations. Conservative, precise, and nowhere near a safety net.¹
• Move the observe/compare step off the small trained verifier and back onto the frontier model that generated the artifact, and rescues fall from 6 tasks to 2. The paper labels this ablation preliminary and single-run.¹
• GuardianAgentBench (23 July 2026) runs 580 scenarios on LangChain, LlamaIndex and Vectara. Best configuration: 74.8 overall — agents still fail roughly one scenario in four.²
• Adding safety instructions to the system prompt moved Claude Opus 4.5 by +0.4 and made GPT-5.2 Pro slightly worse (−0.3). Execution-time guardrails moved every model, +2.8 to +7.7.²
• Both headline papers come from teams with a commercial stake in the result — the Leni paper's corresponding author is the company's CEO,¹ and seven of GABench's eight authors work for one of the three frameworks it benchmarks.³ The numbers are worth having anyway; the caveats section sets out which stakes touch which claims.

What You'll Learn

• What "agent reliability" means when someone actually measures it
• Why a verification loop that works is still only worth 1.5 points
• Why the identity of the verifier may matter more than the verification itself
• Where agents fail on a 580-scenario, six-domain benchmark
• Why agents split into two opposite failure regimes — skipping tools or spamming them
• Why guardrails beat system-prompt rules for every model tested
• Why turn depth punishes agents twice as hard as tool count
• When a repair loop makes an agent worse rather than better
• Which caveats these three papers carry
• What all of this changes if you are shipping agents

What actually got measured

Most writing about AI agent reliability is architecture opinion with a failure-rate statistic bolted on the front. July 2026 produced something less common: three preprints that instrument the loop and publish the internals.

The first, from the Leni team, is a decomposition. It takes one production enterprise agent, freezes the configuration serving real traffic, and runs it against three public benchmarks chosen to stress different failure modes: SpreadsheetBench Verified for silent computation errors, BullshitBench v2 for premise confabulation, and the GAIA validation split for cascade errors over long tool chains.¹ Then it asks which architectural component earned which fraction of the gain.

The second, GuardianAgentBench (GABench), is a benchmark. 580 scenarios across six domains — Customer Service (118), Email (117), Calendar (105), Financial (99), Business Intelligence (77) and Internal Knowledge (64) — covering 81 unique tools and 1,177 sequential turns. Roughly a third of the scenarios (182, or 31.4%) carry adversarial perturbations. Six models run each scenario on three frameworks.²

The third, from Wu and colleagues, is a decision-theoretic result about when a verify-repair loop should stop.⁴ It matters here because it isolates a failure mode the other two imply but do not measure.

None of the three is about which model to buy. All three are about the machinery wrapped around whichever model you already have — the tool-calling loop, the checks, the retries — and whether that machinery measurably works.

The verification loop was worth 1.5 points

The Leni system beats its bare frontier base model by a wide margin. On SpreadsheetBench Verified it scores 91.25% against the base model's 80.25% — an 11.0-point gain over 400 tasks, significant at p<0.001.¹ On BullshitBench v2 it posts 98% against 91% on one executor and 97% against 87% on another. On GAIA validation it reports 75.2% pass@1 over 165 items.

Source: Leni team, Table 3. Confidence intervals are Wilson 95%. The SpreadsheetBench baseline is the public leaderboard's bare Claude Opus 4.6 entry from March 2026 running a minimal three-line prompt, not a rerun inside Leni's harness, so the comparison is unpaired. The GAIA base figure is the authors' own internal single-run estimate and is not significance-tested.¹

The interesting part is what happens when you decompose that 11.0. The paper's central contribution is a layer-by-layer breakdown, and it is unflattering to the mechanism in the title.

Source: Leni team, Table 5. The GAIA structure tiers are internal estimates whose selection rules were not recorded, so the paper flags the GAIA loop-isolated figure as indicative only.¹

Structure — prompting, planning, routing, typed interfaces — carries +9.5 of the 11.0 points on SpreadsheetBench.¹ The verification loop, the thing the paper is named after, adds the remaining +1.5.

The instrumentation shows why. On SpreadsheetBench the loop triggered on 397 of 400 tasks. The verifier confirmed 389 artifacts and flagged 8. All 8 flags were true errors, 6 of which were repaired. But of the 389 confirmations, 32 were false confirmations — real errors it waved through.

Source: Leni team, Table 4, over the 397 loop-triggering tasks.¹

Read the margins: the verifier caught 8 of the 40 errors that were actually there. That is a catch rate of 0.20. Its fix rate, once it catches something, is 0.75. Its false-alarm rate is 0 out of 357, which the paper bounds above at roughly 1% at 95% confidence.¹

The paper's reliability model guarantees that a loop with a false-alarm rate at or near zero cannot make things worse, which is why it treats +1.5 points as a real gain rather than noise. But it is also the honest ceiling of a conservative checker: 80% of the errors present in the run walked straight past it. The paper's own telemetry says raising the catch rate is worth up to +8 more points, while raising the fix rate is worth at most +0.5 — a rare case of a system publishing exactly where its next engineering pound should go.

Who does the checking may matter more than the checking

The paper calls this its most consequential claim, and it rests on the specialist-swap ablation. The Leni loop is verified by small post-trained models — roughly 4B parameters for spreadsheet cell-diff verification and premise triage, 1.5B for typed-artifact extraction, 0.5B for step routing — while a frontier model (Claude Opus 4.6) does the generating.¹

Hold the loop structure fixed and move the observe/compare stage back onto the frontier model that generated the artifact, and SpreadsheetBench rescues fall from 6 tasks to 2. On BullshitBench, correct rejection falls by 4–5 points.¹ The paper's reading: the generator, asked to verify cells it just wrote, tends to rationalise them rather than flag them.

Three qualifications, all of which the paper states itself and none of which survive into the secondary coverage:

• It calls these ablations preliminary four times over — in the abstract, the introduction, the limitations section and the conclusion.
• They are single runs from an internal engineering evaluation, and they cover two of the four specialists — the routing and parsing swaps were never run.
• The design lacks a third condition: an independent frontier model, from a different provider, that did not generate the artifact. Without that cell, the experiment cannot separate independence from specialization. The paper says so explicitly, and calls that missing condition the one that would settle it.

So the honest version is narrower than the headline: something about not using the generating model as its own verifier is worth roughly four tasks in 400, in a single unreplicated run. The direction is well-motivated. The magnitude is not established.

There is one further wrinkle the paper discloses but does not dwell on. The specialists are post-trained from open-weight Qwen3 bases via distillation from a Claude Opus 4.6 teacher — and Claude Opus 4.6 is also the frontier executor generating the artifacts they check.¹ The observer is architecturally independent and separately trained, but it is not drawn from an unrelated lineage.

This is the operational form of a limitation the literature identified two years ago, and the paper is explicit about the debt. It builds on Huang et al.'s ICLR 2024 result that LLMs largely cannot correct their own reasoning without external signals, and on documented self-preference effects in LLM evaluators.⁵⁶ A 2024 critical survey reached the same place from another direction: self-correction works when the loop has reliable external feedback, and not on prompted self-assessment alone.⁷ The Leni loop supplies exactly that external signal — a recomputation engine — and the swap ablation probes what happens when the signal stays but the observer changes.

The direction all of this points is away from a better prompt or a longer chain of thought, and towards a structurally different observer — one trained to emit a hard accept/reject verdict rather than continue a fluent answer, and one that did not write the thing it is judging. The Leni paper's own limitations section puts the strength of that evidence precisely: its ablations "motivate, but do not yet establish" the independent-observer hypothesis.¹

The paper's own discussion is blunt about the division of labour — one of its discussion headings reads "the oracle sets the ceiling; the observer sets the floor."¹ A deterministic oracle — recalculating a spreadsheet in headless LibreOffice and reading values back through a separate deserialization path — is what makes the error visible at all. The paper's guidance follows from that: where re-execution is possible, prefer it; where it is not, use an independent specialized observer rather than self-assessment by the generator.

Agents still fail one scenario in four

GABench's headline is a ceiling, not a leaderboard. The best configuration across six state-of-the-art models and three frameworks — Claude Opus 4.5 running on Vectara — averages 74.8 overall.² Overall correctness in this benchmark requires both a correct response and a tool-invocation sequence matching the ground-truth execution graph in selection, arguments and ordering, so it is a stricter bar than answer accuracy alone.

Two secondary results are more useful than the headline.

Calendar is the hardest domain, and by a distance: no model exceeds 62.0 on it.² The paper does not diagnose why, but calendar work is the benchmark's clearest case of tasks where a required precondition check — is this slot free, does this conflict — sits between the request and the write.

Framework choice mostly does not matter — with a caveat the paper does not flag. Its claim is that within any given model, scores vary by at most 2–3 points across LlamaIndex, LangChain and Vectara, which it reads as evidence that gaps are model-driven rather than framework-driven.² Taking the spread across its own Table 5, that holds for five of the six models but not for DeepSeek-V3.2, whose averaged Overall runs 63.0 to 66.7 — a 3.7-point spread. At the per-domain level it breaks much further: DeepSeek's Customer Service score runs from 61.4 on Vectara to 75.2 on LangChain, a 13.8-point swing on framework alone.

The directional conclusion still stands on average: model choice dominates, and most teams will not buy much by switching orchestrators. But "at most 2–3 points" is the paper's summary of its data rather than a property of the data — if your workload looks like one domain rather than like the benchmark's average, the framework can be worth considerably more than that. It is also, as the caveats section explains, a conclusion published by authors who build one of the three frameworks being compared.

Two failure regimes: skipping tools, or spamming them

GABench classifies every failed execution into five types, and the distribution splits the six models into two groups that fail in opposite directions.

One group fails overwhelmingly by not calling a tool it should have called. Reading Table 6 directly, Missing Required Tool Call accounts for 54.8–57.2% of GPT-5.2 Pro and GPT-OSS-120B failures, 52.1–54.7% of Gemini-3-Pro's, and 45.8–48.0% of Claude Opus 4.5's.² These models understand the request and then answer from their own weights instead of reaching for the tool.

The split is by failure character, not by leaderboard position — GPT-OSS-120B shows the skip-the-tool pattern while scoring in the benchmark's bottom tier on overall accuracy.²

The other group inverts it. DeepSeek-V3.2 and Qwen3-Max show missing-tool-call rates of 35.5–39.7%, but compensate with repeated tool calls at 28.7–32.2% — against 20.2–22.4% for the other four models.² They reach constantly. Whether they also grab the wrong thing separates them: DeepSeek's incorrect-selection rate runs 23.6–25.3%, the highest in the benchmark, while Qwen3-Max sits at 13.9–15.1%, indistinguishable from the models that skip tools. The paper's own phrasing is the careful one — these models choose or repeat incorrectly.

One number cuts across every model: incorrect tool ordering is the rarest failure type at 0.6–4.4%, and it is the smallest of the five failure types in all eighteen configurations.² At this scale — one to seven tools, one to eight turns — sequencing is close to solved, and coverage and selection are not. If your agent evals still weight "did it call the tools in the right order" heavily, you are weighting the thing these models get right.

The figures above are read off Table 6 rather than quoted from the surrounding prose, because on this benchmark the two do not quite agree. Several of the paper's stated ranges do not bracket its own table: it gives missing-tool-call rates as "55–57%" where the table holds 54.8–57.2, "36–40%" where the table holds 35.5–39.7, and repeated calls as "29–33%" where the table holds 28.7–32.2. The same pattern appears in its model tiers, where GPT-5.2 Pro and Qwen3-Max are grouped at "68–72" though two of Qwen3-Max's three scores fall below 68.

The largest instance is worth spelling out, since it is the kind of number that gets repeated. The introduction describes weaker models as mis-selecting and over-calling in "up to 58% of failures combined." Summing selection errors and repeated calls per row of Table 6, the highest total in any single configuration is 56.4% — DeepSeek-V3.2 on LangChain. The 58 looks like the result of adding two maxima that occur in different rows — peak selection errors of 25.3% on Vectara plus peak repeats of 32.2% on LangChain, which comes to 57.5. No single configuration reaches either figure. The paper's own conclusion section, which gives selection "up to 25%" and repeats "29–33%," is closer to the table than its introduction is.²

Guardrails beat safety instructions for every model tested

GABench's defense experiment compares two mitigations against a no-defense baseline: safety instructions added to the system prompt, and execution-time guardrails that intercept each proposed tool call before it runs.

Both gains are over the no-defense baseline; the gap column is the difference, computed here. Source: GABench Figure 8 data labels.²

Two findings fall out of that table cleanly. A third, which the paper states, does not.

Capable models get almost nothing from being told to be careful — GPT-5.2 Pro actually regresses, which the authors read as added instructions introducing noise into behaviour the model had already internalized. And DeepSeek-V3.2, the model with the highest rate of picking the wrong tool, gains the most from prompting, because explicit tool-use guidance addresses exactly that weakness — the authors make the connection themselves.

The claim that does not survive its own figure is the framing. The paper states that the gap between the two strategies "is widest for the strongest models — 5.3 points for Claude Opus 4.5 and 2.6 points for Gemini-3-Pro."² Claude's 5.3 is indeed the widest of the six. But Gemini's 2.6 is the second narrowest of the six, behind Qwen3-Max at 4.5 and GPT-OSS-120B at 4.4 — models the paper ranks in its middle and trailing tiers respectively. The pattern holds for the top model and breaks immediately below it. What the data actually supports is the simpler claim: guardrails beat prompt instructions for every model tested, by between 2.2 and 5.3 points.

The precision numbers are what make the guardrail result more than a slogan. Measured on Claude Opus 4.5 in LlamaIndex: of 151 originally-failing scenarios, 30 were converted to successes — a 19.9% recovery rate. Of 429 originally-passing scenarios, 2 were incorrectly blocked, a 0.5% false-positive rate.²

One detail worth knowing before you copy the design: the paper describes these guardrails as "lightweight, rule-based" in its design section, but its experimental setup states that all three are powered by Claude Sonnet 4.5 with default settings.² They are LLM-backed checks, not deterministic validators, and all three fire concurrently before each tool call — in LlamaIndex only, as a custom extension of llama-index-core. That is a materially different cost and latency profile — three extra model calls per tool step, plus up to two retry iterations — and it means the "structural intervention" being measured is structural in where it sits, not in what it is made of. The three checks themselves are simple enough to reimplement deterministically for schema validation, which is where most of the argument-validation value probably lives.

Turn depth punishes agents twice as hard as tool count

GABench varies complexity along two axes. Averaged across the three frameworks, Claude Opus 4.5 drops from 78.2 at one available tool to 62.3 at seven — a 15.9-point decline. Over turn depth it drops from 82.3 at one turn to 51.2 at seven — 31.1 points.²

Turn depth costs roughly twice what tool-set size costs. The paper reads this as a planning result rather than a context result — managing multi-step dependencies strains agents more than disambiguating among many tools.²

One correction to the paper's framing, since it appears in the abstract and will be repeated: both the abstract and §5.2.2 describe performance as degrading monotonically on both axes. Reading the data labels off the paper's own Figure 6, the tool-count curve runs 78.2, 72.5, 73.8, 71.4, 68.9, 65.3, 62.3 — it rises between two and three tools. The turn-depth curve (82.3, 72.2, 70.1, 63.4, 58.7, 53.2, 51.2) is monotonic; the tool curve is not. The endpoints, and therefore the headline comparison between the two axes, are unaffected.

It is worth keeping the scale straight. GABench's tool sets run from 1 to 7, so this is degradation in the small-catalogue regime, not the hundreds-of-tools regime studied elsewhere — we covered that separately in how many tools an AI agent can handle, where routing accuracy collapses at a very different order of magnitude. Both findings point the same way; they just measure different ends of the curve. The long-horizon result also lines up with what OSWorld 2 showed about computer-use agents on extended task sequences.

When a repair loop makes things worse

The Leni verifier is safe to run because its false-alarm rate is effectively zero. Wu and colleagues address what happens when it is not.

Their framing is precise: when both the verifier and the repairer are noisy, repair can damage plans that were already correct, and "reported acceptance keeps rising while true validity falls."⁴ The loop reports increasing confidence while getting worse — the exact pathology that makes naive retry loops feel productive in a trace viewer while degrading output.

Their proposal, VRR-Stop, models verifier false acceptance and false rejection separately from the repairer's fix-versus-damage behaviour, then commits or repairs based on the sign of the true marginal gain rather than a fixed round count. On a GSM8K stress setting it improves final true validity by 60.6 percentage points over a fixed five-round repair schedule, at an average cost of 0.72 repair rounds.⁴

That 60.6 figure comes from a constructed stress test on grade-school math problems, not a production agent workload, and should not be read as a general agent result. The transferable lesson is smaller and more useful: a fixed number of retries is a design smell. If you cannot state your verifier's false-rejection rate, you cannot say whether your third retry is helping.

The caveats these numbers carry

Both of the headline papers come from teams with an interest in the answer, and neither has been through main-track peer review.

GABench evaluates its own authors' platform, and does not say so in its body text. Seven of the paper's eight authors are employees of Vectara, Inc., including the corresponding author, whose contact address is a vectara.com one; the eighth is at Iowa State University.³ Vectara is one of the three frameworks tested, and the single headline result — the best-performing configuration at 74.8 — is Vectara's own platform. The paper carries no conflict-of-interest statement, no funding statement and no acknowledgements section.

Two things cut the other way, and both are worth stating. The guardrail work — the paper's most useful contribution — was implemented in LlamaIndex, not Vectara. And Vectara is the top framework for three of the six models; LangChain takes the other three. This is not a benchmark rigged to a conclusion, but it is a vendor benchmarking itself without saying so.

Worth noting for anyone verifying this: the affiliations appear in a footnote on page 1 of the PDF and are absent from arXiv's HTML rendering of the same paper, which is what most readers and most automated summarisers will see.

The guardrail results are a proof of concept on one framework. The paper uses the phrase "proof of concept" about the guardrails four times, and they exist only as a custom extension of LlamaIndex.² So "+2.8 to +7.7 across all six models" means all six models on one framework, and the 19.9% recovery figure is one model on one framework. The direction is well-supported; the generality is not yet.

No repeated runs, and no error bars. GABench runs every model through its official API at default parameters, including default temperature, and reports no confidence intervals, no variance and no repeated trials.² That is fine for the large effects — the 11.8-point spread between the best and worst configurations, the 31-point turn-depth collapse. It is not enough to support the fine-grained comparisons, including the 2–3-point framework claim and the ordering of configurations within a couple of points of each other. Treat small gaps here as unresolved. (The Leni paper, by contrast, reports Wilson confidence intervals throughout and bounds its own run-to-run sensitivity at about ±3 points.¹)

Same-family judging. Scenario generation, the automatic half of scenario validation, the automated judge and all three guardrails run on Claude Sonnet 4.5, while Claude Opus 4.5 is one of the six evaluated models.² Two mitigations are worth crediting: every retained scenario was also reviewed independently by at least two human annotators, and the judge itself was validated against human annotations on 60 sampled cases at 93.3% alignment. That is a real check, on a small sample, and the paper reports no inter-annotator agreement statistic.

The Leni paper is a vendor evaluating itself, and says so in its own abstract. The corresponding author is Leni Inc.'s chief executive and founder; the same team built the system, ran the campaigns and trained the specialists.¹ The components were also built for production task families that overlap with what the benchmarks measure — the authors' phrasing is that the defensible claim is not "untuned" but "not tuned to these benchmarks." They publish a contamination scan of 30,104 production messages against 365 evaluation items (four flagged, all traced to internal test sessions in March 2026), note that the workbook-trace and tool-trajectory corpora have not yet been swept, and release the run records — including unfavourable and superseded runs — publicly. This is about as much disclosure as a self-evaluation can carry, which is not the same as independent replication, and the paper's limitations section says that too.

The GAIA number has a contamination range, not a point value. Validation answers are public. The authors scanned all 803 stored trajectories for GAIA-derived source URLs and found 25 across 12 tasks; seven flagged runs sit inside the reported selection and all seven scored correct. Treating every one as a failure gives a conservative floor of 70.9%, against the reported 75.2%.¹ They also note the hidden test set has not been submitted to.

These numbers are older than they look. Leni's evaluations were conducted across March and April 2026 and published on 19 July.¹

One reported figure was corrected in the paper itself. An earlier company report gave 77.6% on the GAIA split. Preparing this paper, the team re-exported all 803 stored trajectories and re-graded them with the official scorer — which reproduced all 218 grades already on record — and found the 77.6% had mixed best-of-k selection at Level 1 with single-attempt scoring at Level 2. They retire the figure and report 75.2% pass@1 instead.¹ That is a credibility marker rather than a red flag, but it is also a reminder that vendor-published agent numbers get restated.

What this changes if you build agents

• Instrument the verifier, not just the agent. Catch rate, fix rate and false-alarm rate are three separate numbers with three different remedies. Leni's telemetry says its next 8 points live in catch rate and at most 0.5 in fix rate; you cannot know your equivalent without the confusion matrix. Tracing infrastructure makes this tractable — see our walkthrough on OpenTelemetry tracing for Claude agents.
• Do not let the generating model be the checker. The evidence for this is one preliminary single-run ablation, so treat it as a cheap hedge rather than a settled result — but it is cheap: use a different model for the observe/compare step. Smaller is fine, and cheaper.
• Find the deterministic oracle first. Recalculating a workbook is what made silent formula errors visible. Ask what external check can tell your agent it is wrong, and build the loop around that rather than around a prompt asking for care.
• Stop paying for safety in system-prompt tokens. For the three strongest models the measured return on safety instructions was +0.4, +0.3 and −0.3; only the weakest model gained meaningfully, at +5.5. Move the check to execution time, where it intercepts the actual tool call.
• Audit for missing tool calls specifically. For four of the six models benchmarked, missing tool calls were roughly half of all failures. GABench scores response correctness and action correctness separately, and this is why that separation earns its keep: an agent can produce a plausible-looking answer while skipping the call that would have grounded it, so an eval grading only the final text will not see it.
• Budget for the checker, then make it small. GABench's guardrails are three concurrent Claude Sonnet 4.5 calls per tool step — real latency, real cost. Leni's answer is the opposite: 0.5–4B specialists quantized to 4 bits, serving at an estimated 0.02–0.1× the cost of the same operation on a frontier model, which is what makes running the compare stage on every task affordable at all.¹ Schema and argument validation can be deterministic; only necessity and relevance genuinely need a model.
• Replace fixed retry counts with a stopping rule. max_retries = 3 chosen by vibes is a number nobody has measured; a rule keyed to your verifier's actual error profile is one you can defend.
• Keep a human in the loop at the block. GABench's guardrail permanently blocks the call after two failed retries and raises a human alert carrying the full interaction history, rather than failing silently — the same pattern as human-in-the-loop approval in the Claude Agent SDK.

The bottom line

The three papers were written independently, on different problems, with different methods, and they point at the same place: the accuracy is in the structure around the model, not in what you ask the model to do.

The most quotable number is +1.5 — the isolated contribution of a verification loop that works, inside a system that gained 11.0 on the same benchmark. Read alone it looks like a debunking. It is not. That loop had a zero false-alarm rate, it rescued tasks whose defects were invisible at write time, and its own telemetry says a better comparator is worth up to 8 more points.

The finding that sits next to it is the one to argue about, and the paper is careful in a way its summaries are not: in a preliminary, single-run ablation, moving the check onto the model that wrote the answer drops rescues from six tasks to two. If that holds up, reliability did not come from checking. It came from checking with an observer that is both specialized and separate from the generator — and the experiment that would tell you which of those two properties is doing the work has not been run.

That is an architecture decision, and it is cheap. Which makes it a strange thing for so much of the field to still be solving with a longer system prompt.