Agent Reliability

Did the agent finish the job?

Agent task completion grading checks whether your AI agent's output matches the end state a user actually wanted, not just whether each step ran without error. And when the completion rate drops, Tessary tells you which change caused it.

The shift

The agent ran clean and still failed

ReliabilityBench, a 2026 benchmark from independent researcher Aayush Gupta, found that agents scoring 96.9% pass@1 under clean conditions dropped to 88.1% once the same tasks were paraphrased the way real users actually phrase requests. In travel booking, agents searched for flights and placed a hold, then stalled before submitting the payment information needed to actually confirm the reservation. Every step ran except the one that closed the loop.

ReliabilityBench, 2026
The problem

Reliability is the top blocker

Measuring Agents in Production (MAP), the first large-scale study of AI agents in production, covered 86 deployed systems in 2025.

38%

of practitioners rank reliability as their top agent development challenge, ahead of governance and compliance combined

Measuring Agents in Production, 2025

75%

of production agent teams interviewed (15 of 20) evaluate without benchmark sets, leaning on A/B tests and direct user feedback instead

Measuring Agents in Production, 2025

Two different questions

Did it run, or did it finish?

A step-completion check confirms the agent ran. None of that confirms the request actually got resolved, and the person who owns the agent usually learns the difference from a customer, not a dashboard.

Step completion

What most evals check

  • Confirms the agent didn't error out or time out mid-session
  • Tool calls returned syntactically valid responses
  • A final message was generated and sent
Tessary

Task completion grading

What actually matters

  • Confirms the end state matches what the user actually asked for
  • Verifies a multi-step booking, ticket, or order was carried through, not abandoned partway
  • Checks the agent's own success claim against what actually changed in the system
How it works

How task completion grading works

Correct a drafted definition of done, grade the full trace against it, and when the rate slips, trace the drop to its cause.

  1. Correct a drafted definition of done

    Tessary drafts what "done" looks like from the traces your agent already produced: a ticket closed with a resolution attached, a booking confirmed with a payment reference, a return processed with a refund issued. You correct the draft rather than write it from scratch. The definition lives outside the agent's code and sharpens as bugs are fixed and edge cases land.

  2. Grade the real trace, not the last message

    Each production session lands as a typed trace: Session, Turn, Trace, Observation. The completion grader reads the full path the agent took, so a task that stalled three steps before the end gets flagged even when the final reply reads cleanly.

  3. Catch the gap before it ships

    A diff classifier reads the next pull request and reports which completion graders are most likely to regress, so a change to checkout logic or escalation rules gets flagged before it reaches production traffic. A check like this only sees changes that arrive through a PR, though. A model provider update or a tool that starts returning different data reintroduces the failure with no deploy at all, which is why the same graders keep watching production.

  4. When the rate slips, find the change that caused it

    Tessary watches the completion-rate trend, and when it drops, traces the failing grader back through the session to the change that caused it: a prompt edit, a tool update, an upstream agent's shift, or a model update that never touched your repo. The finding routes as a digest, threshold alert, or PR comment to Slack, Linear, PagerDuty, or wherever the team already triages incidents.

What it catches

What a completion grader catches

A final-reply check reads one message. A completion grader reads what actually happened.

End-state verification

Checks what actually changed, such as ticket status, order status, or a calendar entry, rather than what the agent's last message claims happened.

Partial-completion detection

An agent that finishes 3 of 4 required steps and still returns a message that reads like success gets flagged at the step where it stopped.

False-success claims

When the agent's final response says a task is done but the trace shows the action never executed, Tessary records the mismatch and ties it to the change that introduced it, whether that was a commit or something that never touched your repo.

From the research
A paradox emerges: if reliability is the primary development bottleneck, how do agent systems reach production?
Pan et al.Measuring Agents in ProductionRead the study
Questions

Answered, plainly.

Agent task completion grading is a check that runs against the real end state an agent produced, not just its final message. It confirms whether a booking was actually confirmed, a ticket actually closed, or an order actually placed, by comparing the system state before and after the agent ran against what the user asked for.
Step completion confirms the agent didn't error out: each tool call returned a valid response and the agent produced a final reply. Task completion confirms the underlying request was actually resolved. An agent can complete every step cleanly and still stop short of the outcome the user wanted, for example holding a flight but never submitting payment to confirm it.
A final-response eval reads only the last message an agent produced. If that message is well-formed and plausible, it can pass even when an earlier step in the trace was skipped or failed silently. The gap only surfaces later, when a user reports that the booking, ticket, or order never actually went through.
Task completion rate is measured by running a grader against the full trace of a session, not a sample of final replies, and checking the resulting state against a defined goal: a ticket status, a payment confirmation, a calendar entry. The grader records a verdict per session, and the rate is the share of sessions where the end state matches the goal. No single verdict is treated as ground truth: Tessary reads the trend in the rate over time, so a grader that captures intent imperfectly, misfiring at a roughly stable rate, still signals a real change when the trend moves.
Yes. A diff classifier can read an incoming pull request, identify which part of the agent's logic it touches, and flag which task-completion graders are at risk of regressing before the change ships. A CI gate can then block the merge if the predicted risk crosses a threshold. The gate only covers regressions that live in your diff, though. An upstream tool or the model itself can change with no PR anywhere, so the graders keep scoring production sessions after the merge too.
Get started

Know when tasks stop completing, and why

Connect a Langfuse or Braintrust trace source, or send OTLP from your own pipeline, and correct a drafted definition of done for one task. Your existing tracing tells you the completion rate moved; Tessary tells you which change moved it. The first grader runs free against your live traffic, no credit card required.